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.

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.

Green Belts (GBs) – trained to lead projects on a part-time basis in parallel with their day-to-day jobs – are ever-present with Lean Six Sigma (LSS) deployments, but how many organizations are truly satisfied with the results they deliver? While I can point to many successful LSS deployments, I honestly have not come across an example of a truly successful GB deployment!

Instead, here’s what I see:

• Excessive GB project cycle times, with averages of >100 days to complete the Define phase and projects taking three to four times longer to complete than originally anticipated. In some cases, only a minority portion of GB projects are ever completed.
• Certification rates of less than 20 percent of those trained appears to be the norm rather than the exception.
• In the last year, I have seen multiple organizations with mature LSS deployments (3-5 years down the path) conduct DMAIC projects to improve GB process performance. Unfortunately, none of the projects resulted in much improvement.

These observations have led me to the conclusion that the standard GB model is fundamentally flawed; but interestingly, since it is a relatively ‘standard model,’ organizations are oftentimes reluctant to make radical changes to it. In the meantime, many consultancies, and increasingly colleges and universities, are more than happy to keep training and pumping GBs out of their belt factories.

The next series of blog entries will explore the root causes for poor Green Belt performance and provide recommended alternative approaches to help organizations get the most from their LSS resources.