The #1 problem still killing process improvement culture.
When processes are complex, no one uses them. Stop killing your process improvement culture: a healthy dose of simplicity will engage your teams.
Founder of Nintex Promapp, Ivan Seselj, tells the story of how, many years ago when he started his career in process improvement, he found process maps and procedures anything but simple. In fact, he admits he found them really confusing.
The different shapes, the maze of connector lines, call outs and notes on the page, the acronyms. Even processes he thought would be relatively straight forward often spanned three or four pages, eventually taped together.
Through his experience Ivan could spot others that struggled with process information, now produced by projects he was working on. Even worse, he soon realized it was open knowledge that this information was never looked at again.
He questioned how organizations could keep investing 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 missing?
It really touched a raw nerve with Ivan when he read one of his favorite 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, he realized 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.
Simplicity is key.
- 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 it that we’re still missing something as obvious as this?
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 organizations - 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 recognizing 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 process improvement conversation.