Many years ago, when I started my career in process improvement, I admit that I found process maps and procedures anything but simple. In fact, I found them really confusing.
The different shapes, the maze of connector lines, call outs and notes on the page, the acronyms. Even processes I thought would be relatively straight forward often spanned three or four pages, eventually taped together.
Through my own experience I could spot others that struggled with process information, now produced by projects I was working on. Even worse, I soon realised it was open knowledge that this information was never looked at again.
How could we keep investing this time, effort, and considerable cost to create this valuable information, and just let it go to waste? And everyone knows it’s happening. And no one seems to care.
What was I missing?
This really touched a raw nerve for me when I read one of my favourite process improvement books The Checklist Manifesto: How to Get Things Right by Atul Gawande.
On examining why process and procedure just aren’t connecting with teams, I realised it isn’t due to “laziness or unwillingness”. As Dan Boorman explains in the book: “The reason is more often that the necessary knowledge has not been translated into a simple, usable, and systematic form.”
So how do we achieve this simplified version of the truth? Boorman and his team were faced with a similar challenge, so they “buckled down to the work of distilling the information into its practical essence… They sharpened, trimmed, and puzzled over pause points…”
It sounds really intense – and it is – but within about a month, “pilots had the new checklist in their hands – or in their cockpit computers. And they used it.”
Wow - look at the last four words. ‘And they used it.’
We may not all have the time and effort to invest in simplifying process as in Atul’s aviation checklist example, but we can still learn from it.
If we continue to produce processes as an expert’s brain dump of knowledge, we should expect the same results. There’ll be a continuation of no one using, or even looking for this information, and a dead process improvement culture.
What impact does process knowledge complexity and confusion have on process improvement culture?
Simplicity of process knowledge has a direct and critical impact on process improvement culture:
- Teams that understand processes more easily can apply them correctly, and can ‘get it right’ more often.
- Teams that clearly understand a process can spot problems and improvements more easily.
- They can change and innovate faster.
- They can work with other teams in the context of processes flowing across different teams.
So how is that in 2017 we’re still missing something as obvious as this?
I think one of the underlying causes is the diverse range of process authors. There are some common drivers for capturing process know-how:
- ISO manual authors and technical writers, for compliance purposes
- Project teams supporting change initiatives
- External consultants deploying new technology
- Software specialists automating process workflows.
These teams of experts aren’t getting process wrong. In fact, they are getting process very right - they are achieving their desired outcomes.
Is simplicity of process a primary outcome for these stakeholder groups? No. In fact, it isn’t a measurement of their success at all.
Success looks different for different people
If we look at what success looks like for the groups above, they’re actually quite diverse, and quite different to the teams involved in owning and actually applying this knowledge:
- An audit pass - evidence of completion and update
- A project go-live - technical milestones complete
- Process requirements and technical specifications - approved
- Processes accepted by process owners - sign-off.
Unfortunately for the process culture of many organisations - the desired outcomes are very different for teams involved in dealing with customers, actually working within these processes every day.
These are the teams we expect to execute new processes, that suffer under process breakdowns, that field direct customer feedback every day, that fix process breakdowns every day… they don’t have two hours to sit down and try to absorb a process. They expect to be able to use something as quickly and as useful as the pilots do.
As Atul rightly concludes - it’s not their laziness or unwillingness to accept help. This is a direct result of trying to use information that just hasn’t been translated into a useable format.
A living, breathing, world-beating improvement culture does not happen without everyone in every team being able to contribute. And this means recognising that dumping techno-speak onto teams after projects is not process improvement.
We need to shift the language of change, our business processes, into useful information so that everyone can join the conversation.