Isn’t it obvious? You can’t do new stuff if you have a veritable plate of spaghetti procedures lined with trip wire and grenades. You just don’t know what button you might accidentally push or wallpaper over that could cause a problem.
And more obviously if your procedrual documentation is so interlinked (like really well intermeshed chain mail) then one procedural failure will find itself radiating out through the other procedures until something fails – generally the poor sucker inside the chain mail – who (you guessed it) gets landed with a corrective action – which in a highly regulated, risk adverse organisation with low exposure to process design methodology ends up with the most common action – (you guessed it!) add another reviewing step into the procedure or even add another procedure. And so another link in the chain mail s created.
Finally my last rant on this one – do you know the other side effect I find soul destroying with this type of procedural documentation? The reading. Do you know that I read more words than a PhD student does in his lit review every month? And most of the time it is a procedure I have read in the last few weeks and I have no idea what has changed in it since the last time I read it. Crazy!
So what would I do to fix this one?
Strategy: return time to the organisation from reading procedural updates by moving to rapidly updateble machine based procedures and reducing release frequency of procedural updates.
- Necessity assumption: in a manufacturing organisation where people are the mixers, makers and testers of products (I.e. More touch time directly equals more productivity) time spent returning to office based PCs and time spent re-reading entire documents for unknown changes is waste.
- Tactic: Count the words read in the organisation every day and aim to reduce by half. Do this by introducing video footage and machine side training screens (or go low cost and grab the retired iPhones) for machine based procedures and move to controlled releases of procedural updates with full version history.
- Parallel assumption:
- Sufficiency assumption: Without a financial cost model applied to reading speed this objective will suffer from inertia by finance. The cost model needs to factor time saved by management with a far greater value (decision making time) than paid. Based on the knowledge that any systems greatest constraint is always management attention.
- If the organisation confesses to not fully reading procedural updates then that is another problem entirely.
And
- Strategy: prevent new processes from suffering from defects by building all new processes with defect free thinking.
- Necessity: in an organisation where failure to follow procedure can have significant and long term negative effects the ability to identify record and prevent defects before the failure occurs is required.
- Tactic: Move the organisation from procedural thinking to process thinking. Do this by ensuring each new process uses DMADV or other such design based Six Sigma tools and build a world where defects in processes can be defined and measured without fear of consequence.
