Project management is as much about team building as it is about project management tools and techniques.

One model I often use which was developed by Bruce Tuckman suggests that a team goes through the following stages during an effort:

1. Forming
2. Storming
3. Norming
4. Performing

The key insight from this view of a team is the recognition that a team moves through stages of growth and that each stage has issues that the project manager may have to manage.

Forming

1. Forming: This is where the project manager is the most active getting people identified for the team and together to start to form a shared view and understanding of what they need to do. This is where people will meet each other for the first time or where they will renew old acquaintanceships.

Storming

2. Storming: Here is where the team starts to make its initial moves in the direction of the project. It might happen at the planning phase of a project but can also happen often during the execution stage. Here is where personalities and styles come into conflict. One person may be “waterfall” centric and want to make sure everything is planned up front and all requirements, costs, and resources needed are nailed down and committed. Another person is more interested in getting started based upon what we already know and hence wants to initiate activities and get things done even while not everything is yet known. These kind of differences in people are in fact a bit predictable and when building a team, a project manager will often try and influence who is on their team to hopefully balance out the personalities on the team (we want a bit of everything, rather than everyone being like the PM for example).

See also team building by Mixing It Up

Norming

3. Norming: Here is where we’ve sorted out our differences, at least for awhile, and start to agree on how we will be doing things. This also includes doing things, where we try out our agreements, and tweaking them as necessary as they work well or need adjusting. We start to make real progress, but often hit big bumps that require us to slow down and reconcile differences before we can get going again.

Performing

4. Performing. This is where the team generally know each other, how each likes to work, and we’ve come to accept and work with just about everyone. The team works extremely well together often without much more than a few words by the PM in a meeting, a quick conference call, a short phone call, a concise e-mail.

Getting to a performing team is a joy. It doesn’t mean the work is easier, but the interpersonal conflicts are often very low and we have a shared and agreed approach to how we are going to get things done.

Often times I’ve observed that a lot of “rules” on how to do projects and other methodologies have a tendency to work against a team reaching the “performing” stage. Many rules (e.g., have to have a meeting, have to create documentation, have to update a checklist, etc.) are really at their root attempting to combat the problems that occur when teams are not working well together (e.g., risk management, countermeasures based upon problems occurring in the past).

These kind of rules and standards also tend to slow down the performing team or try to put another team (QA, test, process, reviews etc.) in the loop that then inserts conflict that can reduce their performance or even break down the team’s cohesion. No, I am not saying that we do away with all rules and structure, only that when we see our team performing, we need to lean to the flexible and agile side and allow them to run full speed when it makes sense and the risks are reasonable.

Also see Being Slightly Out Of Control Can Be A Good Thing

As with any group of people acting in a real environment, a group will often bounce between these various stages. A performing team will do great things, for a short while, until they face a major hurdle. In figuring out what to do with the hurdle (e.g., staffing is pulled off for another effort – see Crisis) they will often go through the stages again. When new people join the team, the team as a whole will often again — hopefully quickly — cycle through the various stages. Note I don’t suggest that new members are just assimilated into the team, rather that the new member often results in what is a new team, with an adjusted set of norms.

Compare with If We Plan Appropriately A Crisis Is Not An Issue

Project management team building is often what project management is all about. Recognizing that a team will go through some fairly predictable stages of growth is key for the project manager to recognize so we can manage these stages appropriately and not be frustrated or sidetracked by them.

How are you managing the growth and development of your team?