“The Project Economy is one in which people have the skills and capabilities they need to turn ideas into reality.” — The Project Management Institute (PMI)

When people fail to turn ideas into reality or when businesses fail to turn strategies into results, a common root cause is that people and organizations lack the right skills and capabilities.

The people include project managers (regardless of their formal titles), team members (or contributors), and project sponsors (management).  Almost everyone is involved in a project in organizations.  The project management (PM) maturity of an organization depends on the skills and capabilities of all people, not just the project managers.

What are the skills and capabilities required for project success?

The PMI Talent Triangle® outlines three skill sets:

• Technical Project Management
• Leadership
• Strategic and Business Management

It is the combination of these skills possessed by people throughout the organization that is required to realize the idea or strategy. In other words, we need adequate skill levels in all nine cells in the role vs. skills matrix (pictured above).

As a project manager, line manager, or consultant in the industry in the past two decades, my observation is that most organizations have low PM maturity, and PM skill development is focused in technical project management for the project managers, i.e. only one of the nine cells.

While the traditional PM skills (such as scope and time management) are critical, they are insufficient because of the increasing complexity, ambiguity, and uncertainty in the problems we try to solve using projects.  Empowering project teams is impossible if project managers and members do not understand the business priority and strategy to make the right decisions.  Unless they demonstrate their business acumen and ability to think strategically, project managers will not be fully empowered.  In my previous blog “Project Managers are Managers,” I offered some suggestions to new project managers to help them think strategically and manage stakeholders effectively.

I was very pleased that the PMI developed the Talent Triangle to help close the skill gap in project managers.  Furthermore, I’d say that we have to assess and develop PM skills for everyone in the organization, for two reasons. 

First, we prepare future project managers for their roles.  People don’t become a competent project manager overnight – it takes years of learning and practice before and after they are given the project manager role.  Even if not in a PM role, each person is leading projects of different sizes and complexity and can benefit from the skills.

Secondly, to ensure project success, project sponsors and members should have the PM skills to perform their roles effectively.  Otherwise, the project managers have to spend much time doing technical project management, unable to focus on the big picture – the business and strategic value.  When project sponsors do not know how to manage projects at the strategical level, their management practices can lead to project problems or failures that even the best project managers cannot prevent.  I touched on some of the practices in my blog “Projects on Schedule.”

How are you assessing and developing PM skills in your organization?

Understandably, many CI projects are chartered because there is a need to improve business performance.  But if the opportunity or path to improvement is not clear, the project has a high risk of failure¹.  Even if the goal was somehow achieved, it likely took far more time and effort than necessary, as evidenced by many 6-12 month long Green Belt (GB) projects. 

While CI professionals are often trained to not assume a solution or even a root cause in Lean Six Sigma projects, the approach to the problem should be well defined for the specific problem.  DMAIC or similar one-size-fits-all frameworks are too generic to be helpful.  Because most project leaders do not have enough experience to identify the right opportunity for a CI project and follow a proven path to improvement, it is essential that the organization implements an effective system to differentiate opportunities into categories suited for distinct approaches.  For example, the categories can include

• Routine improvement by the operators
• Kaizen events
• Lean Six Sigma or DMAIC projects  
• Technical projects that require Subject Matter Experts (SMEs)
• Management

The system will vary by the organization.  In a manufacturing or transactional environment where CI methodologies are applied, I recommend process management as a basic component of the system.  Specifically, process management should include, but is not limited to

• Process mapping to understand how things are being done
• Standardization to implement the best knowledge currently available
• Standard Operating Procedures (SOPs) up to date
• Employees trained and qualified to perform the jobs
• All preventative maintenance followed
• Measurement system analysis to ensure reliable data
• Statistical Process Control (SPC) to monitor and stabilize processes

These foundational activities are prerequisites for any process to perform at its optimal level that is achievable by design.  If these activities are not consistently followed, even an initially high-performing process will deteriorate. 

Any organization striving to improve their processes should start by incorporating these activities into the responsibilities of various roles.  Following these activities will regularly uncover many improvement opportunities, most of which can be accomplished by those who are closest to the process. If needed, Quality and CI professionals can train and coach others proper methods and tools. 

Ideally, process management should be implemented before initiating CI projects in the area.  Routine improvement as a result of process management eliminates countless potential root causes for poor process performance, reducing the need for project-based improvement effort.  Any CI projects, if needed, will have a clearer focus, less encumbered by confounding factors.

When organizations fail to build process management in their operations, CI projects are often initiated as a reaction to emergent problems, which are likely due to years of neglect.  They hope, with the aid of some magic methodology and heroic efforts, that the projects alone will solve the problems.  What they encounter, however, are numerous causes that compound the problem, making a “perfect” situation for inexperienced project leaders in a low CI maturity organization.

Thus projects are a tool of continuous improvement.  They are not a substitute for it.²

1. See my blog Six Sigma Project Management for suggestions to reduce project risks.

2. I borrowed a statement by Peter Drucker when he discussed merger & acquisition — “Thus financial transactions are a tool of business policy.  They are not a substitute for it.” 

Project delays are common.  I heard many executives concerned or frustrated with projects missing critical dates.  Many organizations train project leaders in project management (PM) or even hire professional project managers to ensure that projects will meet the milestones.  Project management certifications, such as Project Management Professional® (PMP), have become a hiring preference or job requirement. 

Yet having trained project managers is seldom enough to eliminate project delays.  What is missing?  

Project managers are supposed to manage risks that can cause delays.  However, they also have to work within the confines of the organization, where senior management operate in ways incompatible with the best PM practices. 

An organization’s management practices often lead to unintended consequences, including project delays and missed deadlines.  These management practices include, for example

• Adding new projects without prioritization or additional resources
• Changing the deliverables or expanding the scope of an existing project
• Optimizing utilization by sharing the same critical resources among multiple projects
• Relying on fixed target dates in decision making without understanding the associated assumptions

The last one is worth elaborating. 

In most organizations, project managers prepare a project plan, which includes a schedule with dates of key milestones.  Some plans require more detailed activities and corresponding dates shown on a network diagram (e.g. a Gantt chart).   The activities and their durations can be uncertain, depending on the project.  For example, in a R&D or process improvement project, where the activity outcome is unpredictable and/or the method is unproven, the estimated time to complete a task can have a high degree of uncertainty. 

However, this uncertainty is not always communicated effectively to the decision makers.  A typical schedule given to the senior management is highly simplified and shows only one fixed duration or target date for each activity or milestone.  If not properly explained, this simplified schedule creates a perception of certainty that does not exist.  Unfortunately, many sponsors are not experienced in PM or are too busy to question the uncertainty in the schedule.  They subsequently use those dates for operational decisions and hold the project managers accountable for delivering on schedule.  The result is predictable.

There is no universal solution to project delays because there are many causes.  In addition to having competent project managers, senior management must recognize the impact of their own action on project success. 

The one practice that I recommend to all sponsors is to ask the project managers to show the uncertainty of milestone dates – how likely will it be completed by this date and why?

There are many ways to communicate the uncertainty.  One simple way is to show three scenarios¹.

• Most likely (or 50%/50% sooner or later than this date)
• Most optimistic (or 10% of chance sooner than this date)
• Most pessimistic (or 10% of chance later than this date)

The exact definitions of the three cases are not as important as the practice of using multiple dates to express the uncertainty.  This dialogue allows us to assess the risk more appropriately and make decisions accordingly.

In project management, the emphasis is on planning, not the plan.

1. Interested readers may want to look up the Program Evaluation and Review Technique (PERT).

What makes a goal achievable?  In my work as a Continuous Improvement (CI) coach and consultant, I have seen some common practices setting a numerical goal using, for example

1. A target set by management, e.g. a productivity standard for the site
2. Customer requirements, e.g. a minimum process capability
3. Some benchmark value from a similar process
4. A number with sufficient business benefit, e.g. 10% improvement

At the first glance, these methods seem reasonable.  In practice, they are problematic for two reasons.

First, the goals are based on what is desirable, not sound understanding of the opportunity using data.  How do we know if a desirable goal is achievable?   In many organizations, a numerical goal is “set in stone” when the project starts; failing to achieve the goal can have potential career repercussions.  While management tends to aim for aggressive targets, the project leaders are more concerned with the risk of failing to achieve them.  They prefer a more “realistic” target that can be met or even exceeded and negotiate with the sponsors to make the desirable target a “stretch” goal.  In the end, no one knows what the real improvement opportunity is.

Secondly, the practices create a mindset and behavior inconducive to the CI culture.  I have seen too many organizations’ Lean, Six Sigma, or other CI initiatives focus only on training and project execution.  They fail to build CI into their daily decisions, operations, and organization’s culture.  Quality improvement cannot be accomplished by projects alone – numerous incremental improvement opportunities exist in routine activities outside any project.  Projects, by their nature, are of a limited duration and are merely one mechanism or component of continuous improvement. Most improvement does not require a project.  Depending on projects to improve a process is a misunderstanding of CI, reinforces reactive (firefighting) behavior, and sends a wrong message to the organization that improvement is achieved through projects, and even worse, by specialists.

Creating a project with only a desired target leads to high uncertainty in project scope, resources, and timelines – a lot of waste. 

To be effective, a CI project should have a specific opportunity identified based on systematic analysis of the process.  Furthermore, the opportunity is realized through a project only if it requires additional and/or specialized resources; otherwise, the improvement should be carried out within routine activities by the responsible people in collaboration. 

What kind of systematic analysis should we perform to identify the opportunities?

One powerful analysis is related to process stability.  It requires our understanding of the nature and sources of variation in a process or system.  In a stable process, there is only common cause variation – its performance is predictable.  If a process is not stable, there exists special cause variation — its performance is not predictable.  Depending on process stability, the opportunity for improvement and the approach are distinct. 

The first question I ask about the goal of any improvement project is “Is the current performance unexpected?”  In other words, is the process performing as predicted?  No project should start without answering this question satisfactorily in terms of process stability.  Most often the answer is something like “We don’t really know but we want something better.”  If you don’t know where you are, how do you get to where you want to be?  This is a typical symptom of a project driven by the desirability rather than a specific opportunity based on analysis.  If the process stability was examined, most likely the first step toward improvement would be to understand and reduce process variation, which does not need a project.

For people familiar with Deming’s 14 Points for Management, I have said nothing new.  I merely touched point 11 “Eliminate management by numbers, numerical goals.”  His original words¹ are illustrative.

“If you have a stable system, then there is no use to specify a goal.  You will get whatever the system will deliver.  A goal beyond the capability of the system will not be reached.”

“If you have not a stable system, then there is again no point in setting a goal.  There is no way to know what the system will produce: it has no capability.”

A goal statement that sounds SMART does not make a project smart.  A project devoid of true improvement opportunity achieves nothing but waste.  But if we follow the path shown by Deming, opportunities abound and improvement continues. 

1. Deming, W. Edwards. Out of the Crisis : Quality, Productivity, and Competitive Position. Cambridge, Mass.: Massachusetts Institute of Technology, Center for Advanced Engineering Study, 1986.

A true Six Sigma project attempts to address a new or long-lasting problem that no one knows the real cause or has a clear solution for.   If the cause or solution is known, it is not a Six Sigma project – Just do it.  This uncertainty obviously makes some people less willing to initiate a Six Sigma project and/or can lead to unsuccessful projects.  In many ways, a Six Sigma project is similar to a high-risk R&D project.

How can we manage Six Sigma projects more effectively?

Assuming that the project is the right one for the organization and receives adequate resources and support, consider the following to reduce project delays and pitfalls.  (If the assumptions are not true, see my earlier post “The First Six Sigma Project” for discussion on some common Six Sigma deployment issues first.)

Train Project Management (PM) Skills

Many newly trained Black Belts (BBs) and Green Belts (GBs) lack sufficient project management skills.  Few received formal PM training, and their previous jobs did not require them to lead cross-functional teams.  A minimum of 2 days of PM fundamentals should be provided as a part of Six Sigma training or a separate program.  If the total training budget or days are limited, some more advanced or less frequently used Six Sigma contents (such as statistical tools) should be removed to accommodate the PM need. 

Having the basic PM knowledge is necessary for project success.  Particularly important, the BB/GB should be clear of their role as a project manager relative to the others in the organization.  The PM skills and experience will benefit the organization beyond the Six Sigma projects.  (See my earlier post “Project Managers are Managers” for suggestions for new project managers.) 

Apply Multi-generational Project Planning

Many project issues are a result of an overly large scope.  A Six Sigma project is already high risk without trying to solve too many problems at the same time.  Both the sponsors and BB/GBs tend to be overambitious and include multiple related metrics in the goal, which leads to diluted efforts and project delays.  If the project lasts more than 5-6 months, it is likely the original business case, assumptions, or metrics will no longer be true before they complete the solution due to external circumstances.  Often projects get cancelled before the benefits are achieved.

Instead, it is better to follow multi-generational project planning and break the goal into a series of smaller ones.  For example, two six-month projects sequentially are better than one 12-month project using the same resources.  Ideally, we follow the Pareto principle to achieve 80% of the goal in the first project and then the remaining in the second one.  In many cases, the second project becomes unnecessary because the business environment has changed by the time we finish the first.  This approach is similar to the Lean and Agile principles used in product development to manage uncertainty.

Use DMAIC Tollgates Properly

Most Six Sigma projects follow the DMAIC methodology, that has a tollgate for each of the Define, Measure, Analyze, Improve, and Control phases.  Many organizations have a list of required and recommended deliverables for each phase and check them at the tollgate review.  Unfortunately, many sponsors and even coaches do not understand why and when a deliverable is required for a particular phase; their insistence on completing the deliverable before the tollgate can cause confusion and project delays. 

Too often organizations make the mistake of using a tollgate to evaluate if the BB/GB has done a good job following the DMAIC methodology.  The primary purpose of a tollgate should be to help the sponsor make the right and timely decisions, such as stopping the project or providing resources.  The tollgates should not be the only times when such decisions are made; many inexperienced project managers make the mistake of delaying decisions until the tollgates.  Organizations can avoid such mistakes by setting the right expectations upfront for the tollgates and decision process for all projects.

In summary, to manage the inherent risks in Six Sigma projects, the sponsor and the BB/GB have to be proactive and methodical in planning and execution.   DMAIC should be rigorous, not rigid.   

As a result, project managers have to navigate in an environment where project sponsors, teams, and other stakeholders have little experience in project management and have wildly different expectations.  The project managers are given little authority and limited resources, and yet they are expected to manage teams and deliver results on time in chaotic environments.  It is a challenging job even for the most seasoned project managers.  For those new to the role, the job can be frustrating and stressful.

Experience will help.  It starts with the most crucial stage – project initiation.  Here are a few suggestions for the new project managers.

1. Be a manager

Whether you are leading a product development or continuous improvement project, you are a leader and manager, even if you don’t have a formal authority.   You are responsible for the success of the project. 

This mindset can be hard for some who haven’t been in a management role.  A project manager is a manager, like any other business manager, even if some people don’t treat them like managers.

To be a manager, you need to show ownership and think strategically.  

In my early career, I made the mistake of jumping on projects without helping define them as if they were non-negotiable tasks to be executed.   I continue to see project managers making similar mistakes.  For many reasons, projects are rarely well defined at the onset.  Some are poorly conceived. 

It is project manager’s job to help the management or sponsor create a clear project charter to achieve the desired outcome.  Discuss with your sponsor to understand the big picture, e.g. what is the true intent, how is it aligned with the overall business objectives, and how does it relate to other projects or initiatives?

2. Understand stakeholders

Some new project managers have only managed their own projects, not ones done by a team.  Cross-functional projects are much more common and present a new set of challenges. 

As a project manager, you depend on others to collaborate and deliver the results, although in many organizations project managers are expected to contribute as a subject matter expert.  It is the project manager’s responsibility to mobilize resources and influence decisions.  In many projects, the project manager also plays the role of a change agent, facilitating a smooth transition to the future state and ensuring sustained results.

It is critical that the project manager knows all the stakeholders involved.  They can include their direct manager, other executives and decision makers, team members, support functions, and external parties. Proactively meet and discuss with them from the very beginning of a project and understand their roles & responsibilities, interest, concerns, and attitude toward the project.   These conversations can uncover potential risks and opportunities and help plan for effective communication and engagement of the stakeholders throughout the project.

3. Set the right expectations

Stakeholders have different expectations of the project and of the project manager.  Many projects get into trouble because of misaligned and ambiguous goals, deliverables, scope, decision rights, roles & responsibilities, etc.  It is the project manager’s job to manage such expectations.

Built on a clear understanding of the stakeholders, the project manager can help clarify and align expectations and communicate in the form of a project charter.  If you think of a project charter as another formality or a template to fill out in the process, it would be a mistake.  It transfers the ownership and project management responsibility from the sponsor to the project manager.   It is true that the sponsor or senior management remains accountable for the decision of initiating the project.  But now you are the manager; you accepted the responsibility to execute it according to the charter. 

The project charter is a powerful tool that allows a project manager to refine and/or re-define a project to achieve the true intent of the sponsor, minimize risks, and maximize return on investment and probability of success.  It facilitates strategic and tactical conversations between the sponsor and the project manager, who is a business manager and trusted advisor.

Don’t miss this crucial opportunity.  Insist on shaping the project charter before accepting the role as a project manager.

Of course, knowing what do to is only the first step.  There are real-world challenges in organizations with low project management maturity.  A manager’s job is never easy, prescriptive, or straightforward.  Project managers are managers after all.

The Challenge

A typical improvement project following an established framework, such as Lean Six Sigma, may look like this:

1. Engage the stakeholders and draft up the project charter, including setting a performance target
2. Map out the current state, possibly using Value Stream Mapping, to establish a cycle time baseline
3. Perform root cause analysis to identify critical factors that influence the cycle time
4. Develop solutions and implementation plans to achieve the improvement goal
5. Implement the solutions and control plan for continual improvement

However, many teams struggle in non-manufacturing environments as soon as they start analyzing the process:

The process is poorly defined and highly variable.  Everyone seems doing things their own ways, and every item seems to require special handling.  Cycle time is not clearly defined or consistently measured.  Data are not always available or comparable among items processed.   It is not uncommon to see data spanning a 10x range in value.  So how do we establish a cycle time baseline given the poorly defined, highly variable process and sparse data?  For a Six Sigma team, how can the performance baseline be measured in terms of defects?  Neither an average cycle time nor process capability (percentage of defects) is a reliable measure of the current state.  But without it, how can we quantify the improvement later?

The struggle continues even after the process has been standardized and solutions have been implemented.   Now the question is “how long does it take to show that the process is better and is delivering the desired business outcome?”  Given a typical business process that spans weeks if not months, it takes months or years to collect enough data to confirm the improvement, if any.  In the meantime, the internal customers or stakeholders of the process are not confident that after all the work they are getting any real benefits.  Each is asking “Sure the overall process may be better on average. But is it helping me achieve my goal?”  No wonder few whole-heartedly support process improvement initiatives.

A Different Approach

Based on my observation, one of the most common mistakes in business process improvement is the implicit assumption that the observed outcome is a result of process variation.   But in most cases, the biggest source of variation is not the process.

Defining a business process baseline using an outcome measure, such as cycle time, is futile.  

Such measures include both process variation and differences in customer or business requirements.  As customer and business requirements change, the process outcomes change wildly.  This variation has little to do with the process itself.  Not recognizing the two sources of variation (process vs. requirements) from the onset of a process improvement project often results in a misguided hope for improvement and a huge waste of time and resources.

In a business process because each outcome is unique, it is best to manage the associated activities as in a project, not in a process.  Formally defined, a project is a temporary endeavor undertaken to create a unique product, service, or result¹.  In contrast, a process is expected to produce the same outcome with minimum variation.   

When there is high variability in a business process, it’s best to first understand how much of the variation comes from customer or business requirements before attempting to establish a process baseline.  In many cases, the answer is obvious.  For example, the time required to register a pharmaceutical product in different countries varies significantly based on the country’s regulatory requirements.  Similarly, the time to negotiate and fully execute a contract varies depending on the specific business requirements and contracting parties.

If the customer or business requirements result in large variation in the outcome measure, e.g. cycle time, it is best to establish something similar to a project baseline, i.e. expected cycle time, for each unique set of requirements.  For example, the expected time to register a product is set at one value for China and a different one for the US.  Our insight will come from the analysis of planned vs. actual values.  Any deviation can then be attributed to 1) our ability to predict the expected value based on existing knowledge and/or 2) our ability to execute according plans.  The best practices in project management (planning and execution, respectively) can naturally be applied to improve the outcome².  

So next time when you are asked to lead a business improvement project, ask this question first:

Did we expect the outcome to be at that level when we started?

1. Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK® Guide)
2. For more discussion on integrating project and process management in non-manufacturing processes, see my publication with Thomas Bertels at Valeocon Management Consulting.