The Project Sponsor serves as the key stakeholder representative for the project and provides the necessary business support for the project leader. Ideally, the Sponsor is the “owner” of the process being improved. This individual’s support and participation are crucial because not only will they have to buy into a project that will affect an area for which they’re accountable - not to mention make sure the team has the resources it needs - but they’re also going to be charged with sustaining the gains achieved. Typically the project leader (often times a Black Belt or Lean Belt) will move on to new challenges, so it falls to the Project Sponsor to ensure the improved process works to the new expectations over the long term. Toward that end, the best Sponsors will be those with the financial and organizational clout to act quickly and decisively in the overall governance of the project.

The Sponsor has a number of important responsibilities:

• Working with the project leader to develop a Project Charter (the contract defining the effort).
• Regularly reviewing project progress.
• Reviewing and approving major project deliverables (including the project gate reviews).
• Changing the direction of the project if it gets off-track, or ending it entirely if it no longer is addressing significant objectives.
• Using both direct organizational authority and “softer” influence to assist the project as required.
• Convincing other key stakeholders to buy in for improvements - and contribute participants for the project team.
• Advising the project leader on organizational protocols, political issues, and potential sensitivities.
• Ensuring the successful implementation of the process improvements and sustainment of the gains after the project is completed.

When projects fail to achieve their desired goals on time or the resulting improvements fail to stick over the long-term, poor Sponsorship is usually a root-cause.  For this reason, the critical nature of this role should not be underestimated.

Next week’s blog entry will explore some common Sponsorship problems and provide recommendations on how to avoid them.

Identifying deep, root causes of poor performance is one of the key tasks that project teams encounter as they work to improve process or product performance. In my experience, the most commonly identified root cause - by far - is “lack of training.”  Unfortunately, “lack of training” is not a root cause; instead, it points to a solution.

The problem with listing a potential solution as a root cause is that it can lead to the implementation of something that doesn’t significantly impact the performance of the process - “more training,” for instance, without exploring other solutions that would lead to improvement.  I am willing to bet that as a reader of this blog, you have seen resources (time and money) spent on training, with little or no resulting improvement.

To see the impact that limiting solution options too early can have, let’s first identify the true root cause. When someone says, “The problem is caused by a lack of training,” I ask, “So why would additional training help?”  The answer typically is, “It would help ensure they have the proper skills and understanding to do the job.”  There’s the root cause - insufficient skills and understanding, rather than a lack of training.

Now that the root cause has been identified, are there more solution options beyond just training? How about simplifying the process or product to lower the level of skills required? How about implementing mistake-proofing methods to make it impossible to do something incorrectly? How about implementing clear, easily understandable visual work instructions that can be used as a guide when doing the work?   Etc. Etc.

I’m not saying that training is never an appropriate solution, but look at the additional options that open up when you first start with a root cause, rather than a preconceived solution.

Last week’s blog entry discussed John Kotter’s new book “A Sense of Urgency.”  In the book, Kotter states that a key component in creating a true urgency for change is the relentless purging of non-important activities.  While he may not have realized it, this links directly to a key continuous improvement concept, the Pareto Principle.

The Pareto Principle, sometimes known as the 80/20 rule, is based on the common natural occurrence in which a large proportion of effects result from a critical few causes.  While the concept first gained popularity as a tool to help improve product and process quality - 80 percent of defects result from 20 percent of the causes - In today’s complicated and fast-paced world, it is proving to be an extremely flexible and powerful management tool that can be applied to many situations.

For instance, in his 2007 bestselling book “The 4-Hour Workweek,” Tim Ferriss employs the Pareto Principle when he recommends firing the 80 percent of your customers who take up the majority of your time and focusing on the 20 percent who make up the majority of your profits.

The Pareto Principle can be applied in almost any situation where there are a large number of items vying for attention - part SKUs, software bugs, potential Lean Six Sigma projects, change related activities, etc.  In these cases, treating every item with equal importance can overwhelm the system and make it difficult to make any progress.  Instead, apply the Pareto Principle so the critical few items receive the vast majority of attention.  The time and energy that would have been spent on the trivial many can now be fully focused on the things that really matter, resulting in the most impact with the least amount of effort.

I suggest using the Pareto Principle as an ongoing reminder to spend your time and energy on things that are really important.  Don’t just work hard, work hard on the right things.

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.