Why are 70% of all Process Improvement Projects Failing?

In a recent podcast on PEX, Nigel Clements (advisor with UK-based non-profit Deming Forum) was asked: “The world of business contains a bewildering array of approaches to process improvement and process management. But sometimes it can seem like we’re having hardly any effect on business operations. So how can we improve the business of improvement?”

Nigel provided some interesting points indicating areas where it all goes wrong. He puts ‘Top Management Buy-in’ as the key element. Other points for failure mentioned are:

–   The way Managers think does not change after the project. Deming suggested that we look at the organization as a system and work from there to make improvements.

–   Improvement requires courage to implement. This courage is often lacking for various reasons.

–   Lack of consistency of purpose; i.e. squeezing budgets.

–   Emphasis on short term thinking and profits; i.e. job cuts.

–   Evaluation of performance i.e. bonuses instead of giving employees a decent wage but monitor performance stringently and get rid of serious under performers.

–   Liability of Management; i.e. often a visionary manager is moved to another department before the project is fully completed.

–   Management using only visible figures; i.e. “How much is this project costing?” or “How much are we spending on training?”

–   Pressure to implement solutions before they are ready.

–   Pressure from business as usual to get the business back into line with existing SLA’s.

–   Too much focus on what we don’t want and not enough focus on what we do want.

–   Think about implications for the future. Employees often feel like Turkeys voting for Christmas.

One of the points Nigel makes is ‘Too much focus on what we don’t want and not enough on what we do want’. Strange but isn’t that just what he is doing himself? Having said that, most of Nigel’s answers are very well made points.

Nigel was asked the question in relation to process improvement projects, however, the points relate to all projects since all projects are trying to achieve some form of improvement.

Some six years back I was working as a Senior Lean Six Sigma Black Belt for IBM, I was asked to look into failure rate of projects. When I concluded my findings I was also using a negative point of view; “Why do projects fail?”

My Manager at the time said to me: “You need to focus on what it is we need to do to have successful project completion, instead of what we don’t need to do.” She made me write the whole piece again, this time with focus on what we need to do to have successful project completion.  Here is a summary of what I wrote at the time:

First, I came up with a top 10 list in order of importance:

1.  Make sure you have sufficient Management Support
2.  Link the Project to the Company Finances and vision
3.  Make sure the solution will be implemented
4.  Can you trust the Data?
5.  Do not accept a scope that is too Large (you cannot solve world hunger)
6.  Quick Wins are great but there is a danger to become unstructured
7.  Don’t spend too much time in one particular phase of the project
8.  Make sure your team has received appropriate training
9.  Are the Business ready and can/will it support the Project?
10. Are there enough resources allocated to the project?

Alan Kent, CEO of Meadows Regional Medical Centre wrote in 2007: “You should not ask your employees to do something you are not willing to do yourself. The engagement of senior management is critical to any significant organizational change.”

Form IBM Global Business Services, George Byrne, Dave Lubowe and Amy Blitz wrote: “CEO and Business unit leaders played active, enthusiastic roles. They were clearly committed to making an indelible cultural change, not just launching another initiative.”

Good Management support requires commitment from all levels of management.

Without this support it is better not to start the project for the simple reason that most of the standard project requirements, irrespective of the method used (DMAIC –Define, Measure, Improve, Control or traditional Project management Pmbok or Prince) are allocated or assigned by Management.

Resources such as Team members, equipment, time to complete, SMEs etc. will need Management approval before you can even start. These resources also need to remain in place for the duration of the project.

It is important to remember that the organizational structure often changes during the life of a project. The Project Manager needs sufficient authority to successfully execute the project. Make sure the PM has all the authority he/she needs from the organizational managers as well as from the functional managers.

Does management understand what the project is all about and do they agree with the scope of the project. Is there a dedicated sponsor appointed who has sufficient authority to make decisions?

–  Linkage to strategic goals of the organization

–  Leadership Support to promote the continuous improvement efforts

An Improvement methodology that is fact-based and repeatable

Fig 1. Three Key Support Elements needed for Process Improvement

It is vital that all area’s that affect the finances are investigated. The success rate doubles if you link to the company’s finances.

For Lean Six Sigma (LSS) projects the Process Owner must tell the LSS team who the Financial Analyst (FA) is. This person must report to the financial community within the organization. The Green Belt or Black Belt project Manager needs sign off from the FA before he/she can claim the savings. The meetings with the FA are scheduled in the Define phase when the initial discussion takes place. The FA is presented with the savings plan and the way the savings will be calculated. In the Improvement Phase the FA will book the savings to the ledger if he is in support of it and the soft-savings are investigated, calculated and agreed.

Every project should be in line with the organisation’s vision. It is up to the Project manager to make sure that the company’s strategy is adhered to

It happens often that someone in Management gets irritated because…it takes too long for the improvements to be implemented. This is not what we expected!’ Even the Team might get restless.

–  The time it takes for a project to complete might discourage the Project Team

–  The work involved in the Project might put the team off from committing themselves

–  The time every team member needs to put in to the Project is more than anticipated

–  The team might assume solutions without the analysis of the Black belt.

If a LSS project does not go to the Control Phase, the improvements will not be sustained. If interference of the mentioned Manager is allowed to happen, the whole project becomes a waste of time. Projects can be easily boycotted and therefore it is vital that the Sponsor and Project Manager have enough cloud to overcome such a disaster.

What Nigel in his comments did not mention is ‘Data’. You cannot improve what you don’t measure! We all know what a jungle the data collection can be in an organization.

A lot of the time there is no data. Sometimes it is difficult to get data or there is limited access. Sometimes defects occur in a process and there are no measurements.

Bad or poor data is a lot worse than no data. . If you ask the relevant people in the organization if there is data available, you will get nearly always “We have loads of data”. That might be the case, but more often the data is totally useless because of repairable manipulation by people who do not have sufficient knowledge. We see CEO’s making decisions on data that represent averages of averages or where the statistical result was based on the wrong hypothesis test. In this case decisions will be made on a false basis which surely will lead to project failure.

Understanding the different types of data is another important factor. Is the data normally distributed? Is the data Continuous data (Measured data such as weight, time, and temperature) or is it discrete data (mainly counted data). Before we can use control charts to help us to understand the variation of the process, the analyst needs to be sure what type of data he/she is using since the statistical analysis will vary greatly depending on the type of data. When the data is available and the type of data is understood, it is vital to complete a measurement system analysis.

Controllability of inputs – Although this may not be uncovered until at least some data has been collected, BBs should make an assessment as to whether there are likely to be sufficient inputs (i.e., contributors to the output to be improved) that are both measurable and controllable. If there is little or no control over the inputs to the process, achieving the project objectives becomes daunting.

Is the process relatively stable? If the process is new, has it reached a stable level of performance? Note that “stable” does not necessarily mean that the process is performing as desired (i.e., as per customer specifications).

Is the process likely to undergo major structural or design changes in the near future? Process stability is important in accurately assessing the impact of improvements without the “noise” created by changes within the process.

Finalize the scope in the Define Phase after the SIPOC is created by the Project Team.  Only make changes to the scope if absolutely necessary after this point:

–  Focus

–  Spread

–  Size

Use a CTQT (Critical to Quality Tree) to narrow the scope.  If your scope is constantly changing, then you need to nail it down. Start by identifying the tasks on the “critical path” and sticking to them, regardless of the change requests that arise. Identify your project priorities and get them approved by your sponsor. Make sure each priority is linked to a business objective, so that they are harder to change.

Sometimes a proposed project produces a lot of Quick wins which are dealt with as they are discovered. There is nothing wrong with that. There are however a few points that need to be observed:

–  When the solution is already known.

–  Care should be taken not to ASSUME the ‘known’ solution is the correct one.

–  It is also important not to take Quick Wins for the end point of the project. Refer to the Project charter and complete with what you and the project Sponsor have agreed.

–  When the proposed project is entering the area of creativity we should not use a DMAIC methodology but stay with PMBOK methodology.

–  Making sure the Project is viable is very important and is done with the help of a prioritization matrix – complete it with your team.

After completing a project the Team Members should feel the results were worth the effort. It takes about the same amount of effort to complete a $300K Project as it does to complete a $30K Project (maybe less). Use statistics to help you – don’t let it become a burden. If you are not sure about what tool to use or how to use it, ASK YOUR COLLEAGUES or the MASTER BLACK BELT.

We must remember to keep it simple (KISS)

Process redesign: project viability is low if the process being examined cannot be improved much further without redesigning it.

Too much training is as bad as not enough training. If the training goes too much into detail the participants fail to learn the key concepts. To avoid that Process Owners become overwhelmed with ‘jargon’, make sure that they understand the principles.

Projects are partnerships between the Business and the Project Sponsor. When we agree to partner on a Project we expect the Business to commit resources the same way the project team will commit resources.

Beware! Time, Cost, Scope and Quality influence each other directly. Change one and you affect one of the others or both. As with most relationships it is better to set out and agree the various aspects in the beginning. The project charter becomes ‘the contract’ between the business and the project sponsor/project manager. This document makes it clear what has been agreed at the outset and only changes should be made after careful consideration and with agreement from all parties.

If we keep the final objective in mind, the obstacles, making project management difficult, will be easily overcome. When all stakeholders are aware of the ‘definite objective’ there is a good change the project will succeed. However as you can see from the above there is a lot to it, but nothing too difficult to take into consideration.

Fig 2. Mind map ‘Project Success’

Georges Van Cauwenbergh has worked with several large international companies such as Hewlett Packard, SITEL and IBM and prior to that, was self-employed in the IT industry for more than 15 years. He became Senior Lean Six Sigma Black Belt in the “World Wide Process Innovation Team” in IBM where he also worked for 1 year creating the Green Sigma TM methodology, which is now part of IBM’s ‘Smarter Buildings’. He received certification recently as a ‘Trainer in further education’ from Maynooth University (Ireland) and is starting a Lean Six Sigma Master Black Belt.

Contact him at Georgesvc@eircom.net