When to Launch the Project Team
Can you imagine assembling a team of top athletes before knowing the sport in which they will compete? In essence, that’s what I see when there is a push to launch DMAIC or other types of project teams before the project is properly defined.
Whether it’s because of perceived pressure to make immediate progress or a desire to include anticipated team members in finalizing the project’s definition, the effect of prematurely forming a project team typically is a negative one. It leads to excessive project delays, reduced morale, and ultimately less than desired results.
Here are some commonly observed issues resulting from launching project teams too early:
- Unnecessary debate in Define: The project duration can be extended and team morale can take a hit as members debate what should be included within the project’s boundaries and what should not.
- The wrong thing gets worked on: Teams formed before scope finalization sometimes resist defining the proper project scope instead they may ‘force-fit’ the project to better match the team’s make-up.
- The team contains the wrong people: Defining the project scope after the team launch often leaves the project with a suboptimal team in which some members are not needed and some needed members are missing. Unfortunately, once the team is launched I often see reluctance to making changes; instead, the project progresses on with the original team. It seems a vested time in the effort trumps having the right people involved.
Team members who aren’t critical typically lose interest in the project and begin to view it as just another meeting they have to attend. This can have long-term repercussions on the entire organization, as the whole effort (Process Excellence, Lean Six Sigma, etc.) can begin to get the reputation of just being about meetings. That’s not a good thing.
On the flipside, having gaps in the team can also lengthen the project’s duration. For example, I spoke with a Black Belt from France last week who found that the interface with a specific IT-owned database represents one-third of the process she’s trying to improve. However, no one from IT was on her team. This issue already caused some delay and was about to cause much more unless she could add an IT resource quickly.
The solution
Resist launching the team until the project is properly defined. The Project Leader (Belt) should work with the Project Sponsor and other key stakeholders to validate the Project Charter - the contract for what the team is to deliver - prior to the team’s formation. (See the Tools & Templates page for in-depth information on Project Charters.)
- I encourage one-on-one meetings with potential team members during the definition process to gain their input, but only on an informal basis at this point.
- Once the Charter has been properly validated by the Project Sponsor and key stakeholders, team members can be notified and the team officially launched.
- The launch should consist of a short kickoff speech by the Project Sponsor, followed by a detailed review of the Project Charter, led by the Project Leader. After that, the team can get down to business, without debate, and more quickly complete its project.
Key takeaway:
Properly defining a project and its scope prior to launching the project team ensures the right things are being worked on by the right resources, reducing project cycle time and increasing the benefits realized.