CIOZone.com - Professional Network for CIOs and IT Professionals

Process improvement part 1:

How to make a process improvement initiative fail

Note:  I started writing this blog intending to call it “Successfully introducing process improvement” but thought the opposite approach much more fun :)

I have been involved in quite a few process improvement initiatives, from small companies of eight employees to the IT department of a large bank with many thousands of staff.  Most projects have been successful but I have had a few hiccups along the way.  Interestingly I think I have learnt more from the failures than the successes and list the main reason for process improvement failures below.  Steering clear of the failures are probably more important than highlighting key success criteria as success criteria can often be different across organisations, but this list will certainly cause project failure.

So what differentiates a successful PI initiative from a dud?  The rule of thumb is if people are willing to use the resulting processes.  Note the emphasis on willing.  There is a huge difference between using something because you will lose your job if you don’t and using it because you see a benefit. 

Key measures to guarantee failure, in no particular order:

1. Reinforce people’s beliefs that processes are convoluted, cumbersome and make things harder.
2. Make the processes difficult to find or search.  Printed folders are best for this.  Spreading processes all over a network drive is a close second.
3. Bigger is better.  A process description must surely be at least 30 pages and document every possible outcome, needing at least four pages for the title page, authorisations and sign off pages.  Tables of Contents are also good to help bloat.  Making the front page indistinguishable across different processes gains extra points here.  If a picture is worth a thousand words, a few thousand words must be better still.
4. Make the processes difficult to change or improve.
5. Ensure the process steps are ambiguous.
6. Don’t do an induction which covers off the Process Asset Library (oops, don’t even have the Process Asset Library – see step 2).  It is best if staff don’t know which processes are documented and which are not.
7. Limit the input from the people doing the work – make sure it is written by management or a consultant with as little input as possible from practitioners.
8. Tell people they must use the processes without taking the time to introduce them to the “journey” of process improvement.

I will soon be posting a follow up article introducing helpful guides on how to address many of these issues.

What are your experiences?  Please add to this article by posting your favourite process improvement killers.

Comment on this article

Only registered users can write comments.
Please login or register.