- Once upon a time, a company’s youthful founder lucked upon a successful method of performing a task.
- The task was profitable, and therefore it was good.
- The founder wrote down that method and bestowed it unto his/her minions.
- S/he said unto them, “This is The Process, and it is good.”
- The minions performed The Process until the end of days.
- And they all lived happily ever after.
Not quite.
The adage, “If it ain’t broke, don’t fix it” has a corollary best expressed by Tess Ferrandez: If broken it is, fix it you should. Or at least, “If broken it is, don’t inflict it on everyone just because it’s all too hard to bother changing it.”
I’m referring to internal corporate processes that serve no purpose other than demonstrating to some ISO 9000 certification minion that a documented process exists.
It seems as if every organisation, once it reaches a certain size, goes into the “create process and perish” stage. If it’s a private enterprise it’ll die a long, slow, horrible death of three-thousand triplicate signatures, but if it’s a government enterprise then it’s never going to die and we’re all going to hate it.
Is hate too strong a word? I don’t think so. Show me a single person who’s dealt with a government department and left happy, and I’ll show you someone who’s on far too many psychedelics to be on the same planet as the rest of us. We hate government agencies because they’re slow, bloated and inefficient.
So, given the choice, why do organisations choose to have processes that make them slow, bloated and despised? Your guess is as good as mine, but I think it’s to do with some misguided idea that they should be able to have any human follow the process and get the same result. Guess what, ladies and gentlemen: if you have a muppet-followable process then you’ll end up hiring muppets to implement it - which is at best embarrassing while the process makes sense, but an utter disaster once the process becomes obsolete and everyone refuses to recognise it. Per the Agile Manifesto, we value individuals and interactions over processes and tools.
The Book of Process above should read something like this:
- Once upon a time, a company’s youthful founder lucked upon a successful method of performing a task.
- The task was profitable, and therefore it was good.
- The founder wrote down that method and bestowed it unto his/her minions.
- S/he said unto them, “This is The Process, and it is good.”
- The minions performed The Process until the end of days.
- The end of days arrived with a pitchfork-waving, torch-brandishing mob of angry citizens who burned the company’s offices down around the minions.
- The minions could not find
their backsides with both handsthe “In Case of Fire” process document quickly enough to escape. - And the citizens all rejoiced, and lived happily ever after.
Is process hurting your company? If so, it might be worth considering whether you actually need all your documented processes, or whether you can just set desired outcomes and performance metrics, and leave your smart people to figure things out for themselv…
… oh. I get it. Smart people. They’ve already left. Never mind.