The wrong Sponsor won’t have the proper clout to assist the project or sustain the results. A Sponsor who’s not fully literate in Process Excellence may not know enough about what needs to be done – it’s not uncommon for project leaders to be trained first; sometimes, Sponsor training lags or never quite happens. That can result in everything from poorly defined projects, with huge scopes or unachievable goals, to a general lack of project support and involvement. If training isn’t immediately available, mentoring from a Master Black Belt can help bridge the gap.

Unengaged Sponsors may not give the project the attention and support it requires – sometimes because they don’t have the training to understand what’s required, but oftentimes because they don’t see the project as important enough to support. If it isn’t important, it should be killed. If it is important, then other influential stakeholders may need to show some leadership by putting it in perspective for them.

From the opposite perspective, a Sponsor also can be too involved. Sometimes, Sponsors try to dictate solutions based on their own pre-conceived ideas. It may take some involvement by another influential stakeholder or Master Black Belt, but they need to agree to back off and let the process work, allowing the project team to develop solutions, even if those recommended solutions contradict their own beliefs. Only very rarely should a Sponsor be an actual team member. The Sponsor’s active support is vital, but if they’re actively at the table, they’re likely to be an overbearing presence, disenfranchising team members.

In businesses that are organized functionally, if a project targets something that lies within that function, it’s relatively easy to identify the Sponsor. Oftentimes, however, a process may operate cross-functionally, either blurring lines of accountability or crossing them. Project leaders necessarily will focus their attention on the process elements; they’re less equipped to negotiate with different functional managers for the resources the project will require.

In those cases, a high-level stakeholder will need to take a hand by identifying an “executive-level” Sponsor with influence across the entire process, or working with that individual to designate a local-level Sponsor to support the team. Because they will have to free up the organizational resources – people and time – to build the project team, however, the Sponsor’s identity needs to be resolved prior to assigning the project to a Lean Belt.

Otherwise, the project leader will get bogged down in the Sponsor selection issue, losing valuable time. This can sometimes double project cycle time. The Sponsor has another important responsibility: actively participating in project gate reviews, since it’s their objectives the project is meant to achieve.

It’s the Sponsor’s responsibility during reviews to make sure the effort is proceeding as defined. They are the ones who make the go/no-go decision for moving on to the next phase. Not just what they decide, but the way they behave in a gate review can have significant impact on the enthusiasm of the team for the work it has done, and what remains to be done.

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.

Oftentimes after the act of demonstrating their commitment, except for the occasional progress review, organization leaders revert back to their old familiar behaviors and work routines. They delegate the pursuit of Process Excellence to those beneath them in the organizational hierarchy. For Process Excellence to weave deep and permanent roots in an organization, leaders need to do more than “walk the walk,” they need to “live the life.”

“Living the life” entails making Process Excellence (including Lean and Six Sigma) a part of everything you do.  It includes:

• Personally striving to continually improve the efficiency and effectiveness of all your daily activities.
• Employing Process Excellence as the primary vehicle for achieving the organization’s strategic objectives.
• Utilizing Process Excellence concepts to improve decision making, such as applying the Pareto principle to focus on the critical few items; responding appropriately to special-cause and common-cause variation; asking to see the statistical significance when someone says “something has happened;” and drilling down to identify deep root causes rather than fixing symptoms of poor performance.
• Continuing to investment in Process Excellence, even when times are tough.
• Rigorously monitoring Process Excellence progress and results, and taking appropriate action to improve performance when necessary.
• Linking a large component of company leaders’ compensation to the internalization and effective application of Process Excellence within their organizations.

To gain a better understanding of how much, as a leader, you “live” the values needed to sustain Process Excellence - or Lean Six Sigma - success, download and complete the assessment contained in the following link:

http://proficiencysystems.com/media/Leadership_Self_Assessment_Form%20v1.0%20(090608)_.pdf

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.

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.

In his most recent book, A Sense of Urgency, Harvard professor and respected change expert John Kotter argues that “urgency” - as the title suggests - is the single most important factor leading to true, positive change. Interestingly, Kotter splits urgency into two categories:

1. A False Sense of Urgency:  Depicted by lots of energetic activity, with people running from meeting to meeting, creating endless PowerPoint presentations, and managing long action item lists. These people appear to want to abandon the status quo and seem to have a high sense of urgency; however, more often than not this behavior is driven more out of past failures or some form of intense pressure put on them. People in this environment tend to feel angry, frustrated, anxious and tired. While there is lots of activity, it is often focused on protecting themselves or pointing the blame at others, rather than a disciplined, productive focus on real issues and opportunities.  … Hmm, this sounds a lot like the behavior of the U.S. Congress during the recent Wall Street bailout issue.

2. A True Sense of Urgency:  Depicted by an alert, fast-moving approach, highly focused on the most important external (marketplace) issues. It is also accompanied by a relentless and ongoing purging of non-important activities to free up people and other resources to focus on what matters, without burning them out. People in this environment feel highly energized and have a deep desire to move and win, now.

Based on Kotter’s research, he views a false sense of urgency to be just as insidious as complacency in preventing true change from taking hold.

So how do you increase true urgency? Kotter suggests that while it can start with giving everyone the necessary important facts, it needs to go further. By connecting to people’s emotions, it’s possible to win over their hearts as well as their minds. He lays out four key tactics to build emotional buy-in, leading to a true sense of urgency:

1. Bring the Outside in:  Ensure that external opportunities and hazards are consistently made visible to all, using emotionally compelling video, people and data.
2. Behave with Urgency Every Day: Don’t act content, angry or anxious. Instead, demonstrate - as visibly as possible — an ongoing consistent sense of urgency in all of your actions and communications.
3. Find Opportunity in Crises:  Look at the “glass is half-full” side of crises to find opportunity rather than pending disaster.
4. Deal with the NoNos: Remove or neutralize all the urgency-killers - not the people who are healthy skeptics, but those who are determined to maintain the status quo and potentially create false urgency.

While Kotter doesn’t explicitly state it, his focus on relentless prioritization of activities, as part of true urgency, links directly to the use of the key quality tool, the Pareto Principle..  I’ll talk more about that in next week’s blog entry.

For now, you can click on the following link to learn more about Kotter’s new book:

Kotter, John P., A Sense of Urgency, Boston, MA, Harvard Business Press, 2008

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.

The Black Belt class I’m teaching this week follows the traditional model in which each participant has a pre-assigned DMAIC project to work on in parallel to the four-month training period (four training weeks over four months). The assigned projects have two purposes:

1. Increase comprehension by enabling BB candidates to apply what they’ve recently learned to a real-world issue
2. Deliver results to the organization by fixing a key issue

While the vast majority of projects are related to important business issues, there are many that aren’t good fits as initial training projects. This is not an uncommon occurrence. These projects generally fall into four categories:

• Some are better fits to Design for Lean Six Sigma (DFLSS) than improvement (DMAIC)
• Some are very qualitative in nature, providing little opportunity for the participant to apply the suite of learned data analysis tools
• Some are scoped too large
• Some are simply “just do it” projects that require good project management skills to implement previously identified solutions, but don’t require the specialized skills of a Black Belt

While the DMAIC methodology is very robust and experienced Black Belts usually can navigate the above issues easily, they often are very problematic for inexperienced BBs. This results in longer project cycle times (as Belts struggle to apply the new concept); lower results (if tools are misapplied or details missed); high levels of BB frustration, and less learning (which can have huge consequences later – extending future cycle times and lowering results per project because tools are poorly applied).

Strong mentoring support – which also is often a gap – can help new Belts better navigate poor training projects, but why not start with the right projects?

While proper project selection is a critical success factor for any deployment, it is even more important for a Belt’s first project. Instead of just focusing on the short-term business need, the long-term benefits of picking projects that support and align with classroom learning also need to be part of the equation.

Key takeaway:

Balancing the need for short-term results with the long-term benefits of learning through application leads to better performing Belts, reduced project cycle times, and more results (in the short- and long-term).

Reversing the trend of underperforming Green Belt deployments is one that demands comprehensive change rather than a few tweaks. There’s no reason GB-like approaches can’t be successful as long as organizations are willing to accept the premise that the status quo isn’t working and fundamental change is required. To start, a fundamentally different project structure called a Lean Event is in order.

The traditional GB approach calls for team members to work part-time on their DMAIC project, oftentimes with more than a week between project activities. When it’s time to reconvene, valuable time is wasted getting back up to speed, and project meetings often are poorly attended or get rescheduled because of issues with members’ regular duties. Paralysis by analysis is another common pitfall of traditional project approaches, as statistical studies often take precedence over actionable elimination of waste.

Lean Events emphasize action over analysis, stripping away the busy work and focusing on the key DMAIC tasks. After thorough preparation, the team members immerse themselves in the project for a week. The full-time nature of the Event week enables teams to focus in an uninterrupted manner on making real, lasting improvements. Interestingly, once scheduled, the looming Event date is a major motivating factor in reducing project cycle time. With it being scheduled so visibly on the organization’s calendar, team members and supporting stakeholders tend to do whatever it takes to hit the targeted date.

A key benefit to the Lean Event model is it does a much better job at weeding out low-priority projects early. Affected leadership must fully support the importance of the project, since they’ll need to give up resources for the 100-percent dedication required during the Event.

The Lean Event approach obviously compresses project timelines significantly. But this isn’t just about saving time – Lean Events produce sustainable results faster, make companies more agile in reacting to changing priorities, and create more cycles of learning for team members.

One pharmaceutical industry client recently converted to this approach and successfully completed 80 percent of its projects within 4.5 months at a very conservative bottom-line impact average of $150,000 per project. I challenge anyone to find a traditional GB deployment that successful!

While the Lean Event project approach is the most visible element of this new model to get the most from Green Belts – or their Lean Belt equivalents – true deployment success requires more. The additional factors impacting success will be discussed in future blog entries.

What are the primary causes of poor Green Belt (GB) performance?

The fundamental issue making Green Belt success so challenging is the part-time nature of the role. GBs are typically expected to lead Lean Six Sigma (LSS) process improvement projects on top of their normal job duties. This arrangement can quickly relegate the LSS project to the back burner whenever anything more pressing comes up – especially if the project isn’t aligned directly to a critical issue within the GB’s work area. While proper project selection and scoping is a critical success factor for all LSS efforts – including those with full-time Black Belts (BBs) – it is even more critical in the world of the part-time GB.

Even when the project is critical and properly linked to the GB’s area of responsibility, success can still be elusive. The first few cycles of applying what was learned in the classroom to a real-world project can be a daunting task. Unfortunately, GBs are often expected to successfully navigate the technical and political challenges of projects in a vacuum – without the needed support infrastructure around them. Master Black Belt-led project coaching support is typically targeted at helping Black Belts, with GB coaching relegated to inexperienced BBs and applied with minimal rigor. Similarly, Sponsor and Deployment Champion support of GBs is also commonly lacking.

These issues often lead to excessive project cycle times and delayed results, which can turn into a vicious cycle. As project activities get delayed – and time moves on – it becomes increasingly difficult to achieve meaningful results. Team members often lose focus, and more importantly, business priorities often change. What was most important six months ago is oftentimes less important today.

With all of these issues, it’s no wonder only a small percentage of projects ever find their way to completion – and an equally small portion of expected benefits are realized.

The next blog entry will discuss a proven solution to help organizations combat these issues and get the most from their LSS resources.