“We have governance, so we’re secure. But we can’t work.”
I heard this from a client a while ago, and it stayed with me. They had a business need that required prompt action, but the request was stuck, and the internal approval was the part they could see. Naturally, it got the blame.
My honest first reaction was that they were right. They needed something from one of the services I manage, and we couldn’t deliver it. That mattered to me more than defending the process. But to improve the service and make sure it didn’t happen again, I first had to understand what was really slowing it down.
So I traced the request. A user needed an additional capability on a platform I manage. From the outside, it looked like something I could simply switch on. In reality, it depended on two separate things: an internal validation process, and a change to our contract with the external provider.
Both required time. But only one was visible to the business asking. Even if we’d waived the internal validation that afternoon, nothing would have changed until the contract did.
That was the moment the problem changed shape for me.
The obstacle you see first
“An hour saved at a non-bottleneck is a mirage,” wrote Eliyahu Goldratt in The Goal (1984), a book about improving a factory.
An office is not a production line, and I don’t want to stretch the comparison too far. But the question works well in almost any setting: would removing that step enable the outcome to happen sooner? If yes, then that step is contributing to the delay, and we should look at it further. If no, then we are about to invest a lot of energy in fixing something that is not actually stopping us.
As for me, my answer was somewhere in between. The internal validation was slow, and I knew it, as I’ll come back to. However, removing it alone would have changed nothing.
What governance is supposed to do
It’s easy to reduce governance to approvals. COBIT, ISACA’s governance framework for enterprise IT, describes it differently: creating value by balancing benefits, risk, and resources. Not all governance is about control.
Reading that, I started to think that one of the most useful things governance can do is help us locate the real constraint, whether it sits in an approval, a contract, a supplier, or someone’s capacity. A request can stall on several at once.
A second point here: while an internal exception could have been approved quickly, the external dependency in question would not have been influenced by such approval. Having the authority to say “yes” is not the same as having the ability to make something happen. Thus, before escalating, I try to establish whether what we are dealing with is something we can control, something we can only influence, or something we can only make visible.
When an improvement waits
This was not the first time I had been asked to go around the same process, but the third. So I proposed a faster route for urgent requests, as the recurring requests showed the standard process wasn’t always matching the speed the business needed. The decision was to leave it for now. There were other priorities, and with limited resources, someone has to make that call. It was a reasonable one.
However, deprioritizing an improvement does not make the limitation disappear. Every prioritization decision has a quieter side: the things we have decided not to fix yet. The next time someone needs to bypass the process, all the frustration will once again be blamed on the process, not on the decision that was made to leave it as it is.
Risk management is also worth a mention here. The ISO 31000 standard recognizes retaining a risk by an informed decision as one of the risk treatment options. And retaining a limitation is perfectly reasonable, as long as it is conscious and visible.
When we decide to live with a constraint, then, I’d like to be able to ask and answer: What are we accepting? Why? Who owns the decision? What are the costs and trade-offs? And, importantly, when are we going to review it?
So I don’t think the answer is to argue harder for the improvement itself. What I would ask for is something smaller: that we record the limitation we are choosing to keep, why we accept it, and when we will review it.
What slips out of view
Looking back, two things had slipped out of view. The real constraint sat behind a more visible obstacle, so the frustration landed there. And the earlier decision to continue with the slower process had disappeared from the conversation, so each new request felt like a new problem rather than the consequence of a trade-off already made.
My takeaway is that governance is neither good nor bad. It earns its keep when it helps us identify what really determines an outcome, and when it keeps our trade-offs visible long after we have made them.
I think these are the two questions worth trying to work out:
When something is blocked, have we found the real block or just the most obvious one?
And of the limitations we live with, which ones did we actually choose?
References
Goldratt, E. M., & Cox, J. (1984). The Goal: A Process of Ongoing Improvement. North River Press.
ISACA. (2018). COBIT 2019 Framework: Introduction and Methodology. ISACA. https://www.isaca.org/resources/cobit
International Organization for Standardization. (2018). ISO 31000:2018 Risk management — Guidelines (clause 6.5.2, Selection of risk treatment options). ISO. https://www.iso.org/standard/65694.html
Leave a Reply