Why Project Teams Fail

I’ve been studying and participating on projects my entire career. I believe there is a really short list of reasons so many of these teams fail. Sometimes it’s a leadership issue on the team, sometimes it’s a resource question and in some situations, the team will fail because of outside factors beyond their control. But there is one reason that towers above all the others…

The absence of clarity is most often the culprit – clarity around issues of deliverables, boundaries, timing and more. Many teams begin with these details missing or misunderstood. The good news for leaders – this is completely avoidable. The answer to this problem is a team charter – a simple document in which you outline several critical elements.

Project teams are different; therefore, I prefer to offer flexibility and customization in the creation of a charter. However, the following elements could be considered standard…

Purpose – Why does this team exist? Is it to solve a problem? To make a recommendation? To create a product? To reinvent a process? There should be no mystery in the purpose of a team.

Deliverables – If a team’s purpose is to make a recommendation on regional offices, the deliverables provide the specifics. The deliverables might include items such as a rollout plan, a staffing plan, a budget, measures of success, and more. Deliverables provide the specifics that are often not included in a purpose statement.

Key Milestones – When is the work to be completed? Are there target dates that need to be met (e.g., first draft, prototype, etc.)? Are there approvals needed along the way? If so, when and by whom?

Design Principles – Are there factors that must be incorporated into the final output? Examples include: All prototypes will be tested in the field for 6 months before full deployment; or, Accelerated learning techniques will be incorporated in all classroom sessions; or, All training sessions will be delivered by senior leaders from our organization. Any decision which has already been made that affects the work of this team should be stated here.

Boundaries – These can be as unique and diverse as you can imagine. What are the lines that cannot be crossed? As an example: If you’re designing a training event, some boundaries might be that participation is voluntary, or attendees will pay for the training, or no training can take place in the 4th quarter of the year.

Budget – How much money has been allocated to this project? Is this the annual budget or the TOTAL budget? (This will matter if the project will be executed over more than one calendar year.) Does the budget cover design and delivery, or just design?

Team Membership – Who is on the team? If the members have assigned roles, this is a good place to note that as well. Specifically, it is helpful to call out the team leader or facilitator.

Sponsor – Which senior leader has sanctioned the work of this team? I have seen examples with multiple names here – I prefer one name. Who has the team’s back and has approved this charter?

If you give a new team this information, you’ll be amazed at how often they’ll hit the mark.