Observant readers will have noted a pattern emerge from my writing. Specifically, whenever my writing verges into the area of team building, I will usually describe Tuckman’s model of group development in relatively disparaging terms. It got a bit of a swipe in an earlier discussion of models, and another derogatory comment in a discussion of the role and value of team building activities.
Tuckman’s model came up again a couple of weeks ago, as I’ve been exploring the value of simple models. Intriguingly, of all the models I cited over several articles, it was the only one that I spoke of dismissively. Last week, a reader appropriately called me out on it, in that it is a pattern he’s observed in my writing and speaking for a while. If Tuckman’s model comes up with me, it’s not going to be discussed in a positive light.
Those observations happen a lot more over on projectmanagement.com, and there’s a reason for that. Part of that reason is that I’m specifically exploring the dimensions of project management in my writing and speaking there, where on my own blog I cast my net more broadly in terms of topic and focus. The other aspect is that, in the world of the project management community, Tuckman’s model is pretty much the only one that is ever acknowledged, discussed, addressed or taught. That is a pretty deplorable reality.
As I’ve discussed several time in the past, project management owes its origins to a vast array of fields, domains and subject areas. Some of those origins are direct, and obviously relevant. The development of project scheduling methods at Dupont to manage large-scale turnarounds and at the US Department of Defense to manage the Polaris program (which are widely acknowledged as the origins of CPM and PERT, respectively) are examples. Earned value management also emerged out of the Department of Defense, initially becoming mandated on Air Force programs in the 1960s.
While those components represent many of the fundamental moving parts of what we recognize as project management, there are many, many more models and concepts that have been borrowed, hijacked and stolen in evolving the overall definition of project management that forms the basis for certification. That’s why holders of a PMP are required to know about any number of models that arose in the early-to-mid twentieth century, including Theory X, Theory Y, Maslow’s Hierarchy of Needs and—for extra bonus points—the Sapir-Whorf hypothesis. A gold star to anyone who asked with incredulity while studying, “when will I ever practically use these in project management?” The answer is not likely ever.
To a certain extent, much of what gets incorporated directly in definitions of project management—or by inference through inclusion in the certification exams—looks like someone went shopping for models so they could flesh out the framework and give it some substance. A big source of these were the various reference sources published by Goal/QPC (a source that will be familiar to anyone that has dabbled in quality management). This is why the knowledge area of Quality Management relies as heavily as it does on the seven tools of quality control and the seven tools of quality assurance; they are pretty much lifted wholesale directly from Goal/QPC’s Memory Jogger.
This is what gets us back to Tuckman. The Team Handbook was a book that was first published by Joiner Associates in 1988, and distributed through Goal/QPC. Designed as a comprehensive guidebook to developing and leading teams, it was an extraordinarily popular book at the time. Front and centre within the book, and dominating the chapter about learning to work together, is Tuckman’s model of group development. It’s the only model referenced in the book, and it’s the only model that is tested in the PMP certification exam. I don’t particularly view that as a coincidence.
The Tuckman model of group development was first published in 1965 by Bruce Tuckman. Building on a review of fifty articles about group development, Tuckman proposed four stages of group development. Even if you don’t know Tuckman and might not recognize him in a dark alley, you know the stages of his model: Forming, Storming, Norming and Performing. They are innately appealing, both because they rhyme delightfully as they trip off the tongue and they seem sort of intuitive in terms of how we think about teams and how they take shape. So much so that many have adopted the model wholesale, without any deliberation whatsoever.
The challenge is that the model requires critical consideration. If a model is to be useful, then like a map it has to provide an accurate and representative view of the territory that it purports to describe. This is where we run into more than a bit of a problem. The insights that Tuckman drew on were narrow and specific in nature, principally leveraging therapy groups and training groups. Tuckman himself warned that applying the model to generic team settings—which notably includes the types of project teams to which it is frequently applied—might not be applicable or relevant.
More specific problems with the model are several. For starters, as Tuckman himself notes, the stages are derived from snapshots of teams at different points in their lives. In the studies used as a basis of the model, some of the stages appeared in some of the studies, and others appeared in others. Some had more stages than the four Tuckman went with, and others had fewer. None of them actually describe what is actually involved in attaining a stage, and what factors prompt transition from one stage to another. There was not a practical observation of teams in action that led to Tuckman’s model, and there was no subsequent validation of the findings. What praise can be offered is phrased in Tuckman’s own words: “It would seem to withstand the test of common sense…”
Common sense can be how you develop models for your own personal use. I certainly suggested a couple of weeks ago that you might look for meaningful dimensions that help make sense of a problem you are trying to solve, giving some space between different situations or solutions in order to figure out what looks most promising. The bar should be much higher for models that you borrow, acquire or inherit from someone else. There should actually be some science behind them.
Appeals of common sense notwithstanding, there have been other efforts to test Tuckman’s model and validate its relevance. They have not gone well. One of the more interesting ones was published by the Defense Acquisition University (the military really is a surprising source of inspiration and research for models). They attempted to determine whether there was any empirical foundation to the model Tuckman formulated. What they essentially found was that only about 2% of teams studied (six out of a population of 321) adhered to the four stages of forming, storming, norming and performing.
What this study helps to illustrate is one of the fundamental problems of Tuckman’s model; it is presented as linear and sequential. The presumption is that you start at forming, as you come together and figure out what it is you are supposed to do. You move to storming, where you compete, struggle and argue as you attempt to get clarity on role, task and your relationship with each other. You get to norming, where goals are clear, tasks are oriented and roles are structured and agreed upon. From there you can perform, reaching peak performance and delivering optimal team results. It’s a nice fantasy on paper, but it doesn’t hold up to reality.
For starters, teams don’t go through each of those stages in sequence. Despite the implications of the model, team formation and development is not linear, it’s messy. Backsliding occurs regularly, and you can get from performing all the way back to storming again in a day, without really trying hard. Teams also don’t spend equal time at each stage of the model. There is no guidance as to how a team should advance from stage to stage, and little insight into the critical factors that deliver performance for some teams while undermining it for others.
What the Defense Acquisition University study did highlight as useful findings were twofold. First, what they found was that a much larger percentage of teams (77%, or 229 teams) progressed through was an abbreviated version of Tuckman’s model, specifically moving through the stages of forming, norming and performing. Second, with respect to the explanation of “storming” and its proper role in the scheme of team development, they essentially found that storming wasn’t a stage. Instead, storming is a state of being that runs through the entire duration of a team working together.
Where this essentially leaves us is with the inescapable conclusion that the most popular model of team development, frequently cited, often referenced, widely taught and reinforced to subsequent generations, doesn’t actually do what it says it does. While it might appeal to common sense, the stages are not linear, clear, consistently followed, proportional in time or anywhere near as well-defined as the model presumes. While all models are of necessity a simplification, Tuckman’s model represents a level of abstract irrelevance that is less than helpful or useful, and should in no way be relied upon.
That should lead to an inevitable question that the astute reader has been formulating through much of the preceding take-down: “All right, Mr. Smarty Pants, if forming-storming-norming-performing isn’t a great description of how teams develop, what else have you got?” I’m so glad that you asked, for there are several. As I’ve noted before, project management has an annoying habit of borrowing models, forgetting their source and ignoring everything that comes after. In the meantime, the field of organizational behaviour has been busily working away on all manner of useful perspectives and models.
For starters, I’ve talked before about Connie Gersick’s model of punctuated equilibrium. It’s a lovely encapsulation of how teams get to performing (if they are going to ever get there at all). One of the very useful insights from her research is that team performance gets dialled in literally from the first meeting. There is a set-point established that determines what level of urgency and performance can be accepted, and that remains pretty much a status quo happy place for an extended period of time. At the mid-point of any given work (why this theory is sometimes referred to as the “mid-point transition”) there is often a period of emotional reckoning, that half the time is consumed and no where near half the work is produced. Managed well, this is the transitional event that can kick performance into high gear.
Less about group development than decision development, Marshall Scott Poole suggested that different groups use different sequences of activities in making decisions (which gets extra bonus points from me, as another “it depends” theory of management). Specifically, how decisions get made depends upon its nature. Decisions about task will be made differently than about addressing interpersonal relations, and differently again in managing group conflict.
A different perspective on team development and how it is influenced is offered by Richard Hackman. In his research, Hackman takes focus on the fact that most team research emphasizes the individual or the group. His take is that you need to consider and address individual factors, group factors and what is going on in the organization if you are going to make sense of team performance, and determine what effectively influences it.
A related, if somewhat more complex model comes from Joseph McGrath, who makes yet another nuanced argument for the processes that affect group performance. His theory of Time, Interaction and Performance starts with the contention (not dissimilarly to Poole) that teams focus on different modes. These modes include goal setting and clarifying the purpose of the team, figuring out technical problems and ways of proceeding forward, managing conflict and politics, and doing the work of getting stuff done. Overlaying this is a focus on different ways that teams work: paying attention to the work itself, looking after the well-being of the group and providing support for individual members. Different actions and activities take place in different ways depending on the mode and the function. For those following along at home, yes this makes his theory a three-by-four model (a pleasant change from a world of two-by-two matrices).
There are a number of different perspectives and views to help understand how to effectively build teams. They represent useful, simple models that are relevant, applicable and—better yet—proven. While you might not get tested on them in your certification exam (and you will inevitably still be required to regurgitate Tuckman’s model at will, likely for some time into the future) the models I’ve outlined here will stand you in good stead when you’ve actually got to get a chaotic group of people to work together in close quarters and deliver something awesome.