That is not to say that things cannot be improved.
Undoubtedly there are places where it can be made better, where the people making the process do not have all the answers - how could they? - or where the process is out of date.
The first challenge is understanding: before we can improve we must understand.
Business processes are rarely well documented.
Sometimes the steps are documented -- often there is documentation for the public, the internal steps less so but sometimes. However the rational behind the process, the reasons that drove the process to be the way it is -- that crucial information is almost never documented.
It is all too easy for a process to become cumbersome, where every step was done for a good reason at the time. The road to over-complexity is paved with good intentions.
I am reminded of a story told by Primo Levi in The Periodic Table, the story of the redundant onion in the oil.
Levi was an industrial chemist by trade, and worked at one stage in varnish production. In a textbook on the topic he had found the strange advice, when making varnish, to introduce two slices of onion into the principal ingredient of linseed oil. No comment was given on the purpose of this curious additive. Levi spoke about it with Signor Giacomasso Olindo, his predecessor and teacher:
Smiling benevolently behind his thick white moustache, he explained to me that in actual fact, when he was young and boiled the oil personally, thermometers had not yet come into use: one judged the temperature of the batch by observing the smoke, or spitting into it, or, more efficiently, immersing a slice of onion in the oil on the point of a skewer; when the onion began to fry, the boiling was finished. Evidently, with the passing of the years, what had been a crude measuring operation had lost its significance and was transformed into a mysterious and magical practice. [2]Processes accumulate, like sediment into stone.
But the counterpoint to the Redundant Onion, is the Vital Old Pipe.
This story is my own from a few years ago, when I was living on the top floor of a block of tenement flats in Edinburgh. At some unknown time earlier, the flat below had redone their kitchen. Whilst clearing out the old kitchen, the builders found an antiquated old pipe for which they could see no purpose. It was in the way of what they wanted to do. The block of flats was 200 years old, and they summized that this pipe had no purpose, that it was some obsolete piece of junk, and so they simply cut it out. Nothing went wrong, validating their decision.
Or rather, nothing went wrong until later, when our boiler broke. We arranged for a plumber to install a new boiler. First, the plumber flushed out the water from the radiators - an easy task as there is a drainage pipe in old Edinburgh tenement flat buildings to do exactly this. This specialised drain pipe is rarely used. This was the drainage pipe which had been cut sometime before in the flat below.
We and the other residents in the block learned all about these drainage pipes when water started coming through the walls of the flat below us. And through the ceiling of the flat below them. Finally it took out the ceiling of the shop on the ground floor.
What had seemed to be a useless old pipe, was in fact an important part of the system, that was just poorly known and not properly understood.
Therein lies the conundrum. In reforming government process, we start out being unable to tell which bits are Redundant Onions, and can be safely be reformed, and which bits are Vital Old Pipes that still serve a purpose, even though it is not instantly obvious. What's lacking is a manual, or more precisely, the equivalent of good code documentation.[3] If our block of flats had come with a manual, the builders could have checked that, and would have known what the pipe was, and why it was there. Business processes need to come with such a manual, something that says this is how we do it, and this is why we do it -- because that understanding is the key to being able to change it. So that understanding is empowering.
That manual lets you reorganize and evolve your processes. It's also really useful for normal operations, e.g. when a new staff member comes in. They need to know how to do things. They usually learn that from their colleagues - but this is a slow and patchy way to manage knowledge. The learning is gradual and piecemeal, and they must hold it all in their head.
But if there's a manual, they can look it up as and when they need it.
And if the process changes, they know where to look for up-to-date answers.
More than that, the manual is key to improving process.
Here at Good-Loop we use an internal wiki which anyone in the company can edit, and it documents our processes: how to book a holiday, how to onboard a new colleague (and also, since we are an adtech company, technical material like how to spin up a new server). This has been invaluable in both avoiding mistakes and efficient working.
We're a small company. Does a wiki approach (by which I mean, having a shared central knowledge-base, maintained by the team) extend to large organisations? I believe it can. Wikipedia is a truly inspiring example here - a high-quality knowledge-base built by the many, for the many. Let's do something similar for government processes.
[1] Wittin - https://www.wittin.co.uk
[3] Documentation for the Educated Stranger
[2] Primo Levi - Opening extract of Chromium from The Periodic Table
