Team Building Phases

Teams are not as easy as throw our collection of individuals into a room together and bang, thus is a team created.  We are fond of the description of the steps a team will go through by Bruce Tuckman we list below.  Our experience suggests this list to be a reasonable list of the phases a group goes through to become a team.

• forming -the collection of individuals are put together
• storming  the clash of personalities as well as social mores
• norming – the group establishes the group’s norms and mores
• performing – the collection of individuals are now performing (the sum is greater than the individuals)

Collection of Individuals

It takes more than placing people together in a room and pointing them at an objective, will not necessarily turn this collection of individuals and turn them into a team.  This story is about the start of a project, actually the first time this collection of people worked together.   The work objective and scope are explored and understood.  The available staff for the project is limited, and as is often the case, the schedule is close.  A review of the prospective individuals and available talents, help us determine the areas of responsibility per those individuals.  Who can, and is going to do, what? The work was distributed based upon things believed about the individuals, for example, generating the specifications for the product features were distributed to the senior engineers with experience on the product line.

The project commences, and after some period of time, a review the progress of the work is scheduled.  The technical lead reviews the specification work being performed by one of the senior engineers, and finds that the documentation is largely without merit, describes the technical aspects of the feature errant, with large parts elements missing.  The technical lead decides, it is the lack of a well defined format and structure that clearly identifies what is important, and this makes generating the specifications difficult.  So the lead engineer creates a template to lead the senior engineer into what was important with the subsystem specifications, including information required by the developers.

Some time passes again, and the developers come to the lead engineer, complaining that they could not build anything based upon the quality of the specifications delivered by the senior engineer. The lead reviews the documents produced and agrees with the conclusion of the developers.  A meeting is scheduled with the senior engineer and their manager.  In the course of the meeting it was discovered that the senior engineer never wanted to be part of the project. Upon receiving this information the team member is dismissed from the team for other activities.  The manager and the lead engineer are left to find a solution.  The team is now short handed and behind schedule.

Oops, Team Stress

Now the project is behind schedule, with the majority of the specification missing after burning a few weeks of time.  The senior engineer is removed from the team, and a new strategy is undertaken to deliver the requirements. This new strategy included a just in time approach to the subsystem specifications.

The lessons learned are:

1. Ensure the people proposed to be team players (where this collection does not organically happen) actually want to be on the team.
2. Define metrics and take constant samples of those metrics that help prediction.
3. Just in time specification based upon what are the most important things for the project, product or technical attribute.

Do you want to be on the team?

You have little chance of building a team if the members wish they were doing something else.  If you cannot get past this hurdle, then the depending effort is at risk.  Perhaps you can convince the person(s) that this effort is worthwhile. If you cannot, then depending upon the desired schedule, you may have to quickly find the right talent that is motivated by the work.

Define metrics and measure.

Don’t wait too long to see how things are going. Do not assume that the work is going according to plan, even if you believe the person doing the work is competent and motivated to do the work.  Product development should be evidence based, and that is just as valid for the project management work.

Just in time specifications

I have never worked on a project wherein all of the requirements were required up front. I say this because I frequently hear what is referred to as stage gate, as all of the requirements before moving on to all of the next step. I have said this before, I have never worked in a project that was laid out or executed like this.  However, the ultimate solution for this particular project, was very small increments of everything from the requirements, builds, testing and iteration available for vehicle integration and field testing activities.

A team does not come together just because you need this collection of individuals to perform so.  Finding out late that you have team members that do not want to be there doing that work, only delays the inevitable unless their attitude or mindset can be altered.  It is probably appropriate to mention, that the remaining collection of individuals made the objective even short handed and won recognition from the organization.