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:
Reinforce
people’s beliefs that processes are convoluted, cumbersome and make things
harder.
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.
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.
Make
the processes difficult to change or improve.
Ensure
the process steps are ambiguous.
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.
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.
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.