Work Instructions – The Achilles Heel of Process?

In previous articles I have explained how Universal Process Notation (UPN) challenges a lot of existing process wisdom, and allows us to create user friendly process maps.  So far we have looked at BPMN, Decision Boxes, Levels and Swimlanes.

In this article I am going to look at Work Instructions, and their incompatibility with good process.  Yes, you read that right, their incompatibility with good process.

Process Rigor

One of the key strengths of UPN is that its simple notation enables anyone to construct a rigorous process.  How?  By focusing on activities and outcomes, the sunny day scenario is easy to document, and the process gaps and anomalies, exceptions, fatal errors, loopbacks – all those rainy day scenarios – “pop” from the page.

Apply these principles from Level 1 of your company or from a particular value stream and, by drilling down to lower levels of detail you can be sure that what you document at the lowest level is aligned with the high level needs of your company.

In the Levels article I explained that there is no restriction on the number of levels to which you can go.  You create as many levels as you need to explain a process with clarity for the end user.  Some processes are inherently more complex than others so it’s not a good idea to limit the number of levels (and none of the UPN apps support a fixed limit.)

The simple rule is:

Drill down until you have documented the process completely


“But what about work instructions,” I hear someone say?  “Work Instructions, Standard Operating Procedures (SOPs) are vital to our work and we can’t live without them!”

Process Rigor Mortis

I hear you.  WIs and SOPs are lifeblood to some people and are burned into their process methodology.  So I’ll be bold.

Work Instructions are not the answer, they’re the problem

Let me put it another way

If you’re using Work Instructions, you are not managing your processes, your processes are managing you.

Pretty extreme views?  Well. consider this:

  • You just embarked on a process-driven journey right?
  • You needed to analyse your processes to understand where they were breaking down
  • You’re sick of interdepartmental warfare where each department blames the other for things going wrong. “You need to fix your process; my process is perfect!”
  •  You may even have convinced your exec team that process starts at the top and trickles down.
  • You have taken that to the next logical step and mapped a high-level process for your company.
    • Let’s just think about that for a moment.  You convinced the exec team  – the most process averse breed of people on the planet – that it’s all about process, and you got them to document their processes.  RESPECT!  Hold that thought.
  •  You have built on that success and have developed the next few levels of process, even though the senior managers are not much more enthusiastic about process than the exec team. 
  • You have been diligent about process discovery – in particular you have paid meticulous attention to process hand-offs.  Every set of outputs has been checked with the downstream players to make sure that you are giving them what they need, no more, no less – just like the upstream players did for you.
  • And then, for some reason, just as you get to the people to whom process really matters – the operational staff, the people who actually do the handing off – the place where it can all go horribly wrong, you stop.  You fought the fight with the process-averse exec team, and won; but when faced with a process-centric operations team, you caved and allowed the use of work instructions.

If you’re going to do process you need to do process – all the way down


OK.” I hear you say, “but when we reach the level where all the steps are performed by the same person, surely we can use a Work Instruction there?

Er, no, actually. 

1. How do you know that all the steps in that work instruction are correct, unless you use UPN rigour?

2. No person works in isolation.  They still need to receive inputs from various places and generate outcomes.  How do you know the hand-offs are correct if you don’t map them?

Poor Process Prevents Proper Performance!

A work instruction has:

  • no rigour
  • no structure
  • doesn’t support process analysis
  • can’t handle branching processes very well
  • is hard to absorb
  • and the author can write what they want
  • upstream and downstream processes don’t get the required due diligence

Text is linear – process isn’t

You will struggle to find something that needs fixing, amongst blocks of text.  For analytical work you need a process map, to reveal the broken connections.  And, if you have expended effort graphically analysing the process – and produced a user friendly process map along the way, why wouldn’t you use the map as the operational manual?

A process map isn’t a by-product. it’s the product.

If you’re going to do process, do a proper job – all the way down.

This isn’t just dogma.  In my time at Avaya we mapped “all the way down” for a major process revamp in the services business unit.  In the middle of rollout the external ISO 9000 auditors carried out an unannounced inspection.  We had no choice but to carry on with the rollout, even though we were changing the engines on an aircraft in flight.  Despite that we not only passed our inspection, we received a Best Practice award.  The auditors loved the fact that there was this chain of process integrity from top to bottom.


May we ask a favour? This site has no sponsors as a matter of principle. Please click the ad? It’ll cost just a few seconds of your time, and it’ll help subsidise our running costs. Thank you.


Leave a Reply

Your e-mail address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>


Is this site useful? Please spread the word

Follow by Email

WP to LinkedIn Auto Publish Powered By :