Process Orthodoxy — When Best Practice Became Worst Practice
The organisation that can produce a perfect audit trail for a failed programme has not solved a governance problem — it has perfected a documentation habit.
The Cathedral of Process
Walk into any large IT organisation today and you will find process everywhere. Change management processes. Incident management processes. Release management processes. Problem management processes. Configuration management processes. Each documented, each with a process owner, each audited, each generating metrics that are reported upward to committees that meet monthly to review them.
ITIL, COBIT, CMMI — the great frameworks of the last decade have given organisations a vocabulary for operational discipline and a structure for governance. This was necessary. The chaotic, undocumented, personality-dependent IT departments of the 1990s needed professionalising. Standards brought consistency. Maturity models brought measurement. Governance frameworks brought accountability.
But something has happened along the way. The frameworks that were supposed to improve outcomes have become ends in themselves. Organisations now invest more energy in maintaining process compliance than in delivering results. The change advisory board has become a bottleneck, not a safeguard. The release process takes longer than the development. The incident management workflow generates more paperwork than insight. We have built a cathedral of process and forgotten what we came to pray for.
The Three Failures of Process Orthodoxy
Compliance Without Capability
The most corrosive effect of process orthodoxy is the substitution of compliance for competence. An organisation that has achieved CMMI Level 3 has demonstrated that its processes are defined, documented, and followed. It has not demonstrated that those processes produce good software, or that its people are skilled, or that its programmes deliver value.
I have worked with organisations that passed every audit, held every review, completed every template — and consistently delivered late, over budget, and below expectation. The process documentation was immaculate. The outcomes were poor. Nobody connected the two observations, because the governance model measured process adherence, not delivery effectiveness.
Process maturity and delivery capability are not the same thing. An organisation can be highly mature in its processes and deeply immature in its ability to deliver outcomes — and the process framework will never tell it so.
This is not a failure of the frameworks themselves. ITIL does not claim that following its guidance guarantees good outcomes. CMMI explicitly states that maturity levels describe process capability, not organisational performance. But in practice, the distinction has collapsed. Boards and regulators ask for maturity assessments as proxies for competence. Organisations pursue certifications as proxies for capability. The map has replaced the territory.
The Overhead That Nobody Measures
Every process step has a cost. Every approval gate adds time. Every handoff introduces delay and information loss. Every template that must be completed diverts effort from the work it documents. These costs are real, measurable, and almost universally ignored.
Consider a typical enterprise change request. A developer identifies a fix, estimates it at two hours of work, and submits a change request. The request is reviewed by the team lead, then by the change coordinator, then placed on the agenda for the weekly change advisory board. The CAB meets on Thursday. If the request is approved, it enters the release queue for the following Tuesday’s deployment window. Elapsed time from identification to deployment: ten days. Actual work: two hours. Process overhead: the remaining nine days and twenty-two hours.
Multiply this by hundreds of changes per month across a portfolio of programmes, and the aggregate cost is staggering. Yet it appears nowhere in any governance report. The change management process reports the number of changes processed, the approval rate, and the number of failed changes. It does not report the cost of the process itself — the weeks of elapsed time, the hours of meeting attendance, the opportunity cost of delayed delivery.
“The organisation that can produce a perfect audit trail for a failed programme has not solved a governance problem — it has perfected a documentation habit.”
The Innovation Tax
Process orthodoxy does not merely slow delivery. It actively discourages the behaviours that organisations most need: experimentation, rapid learning, and adaptation. When every change requires a business case, every deployment requires a release plan, and every deviation requires an exception report, the rational response is to avoid change altogether.
This is precisely what happens. Teams learn to batch changes into large, infrequent releases — not because this is technically optimal, but because the process overhead of each release is so high that minimising the number of releases minimises the total overhead. The result is exactly what the process was designed to prevent: large, risky deployments with long feedback cycles and high failure rates.
The irony is complete. The process framework designed to reduce risk has created an incentive structure that maximises it. The change management process designed to protect production stability has made deployments larger, less frequent, and more dangerous. We have optimised for control at the expense of the outcomes that control was supposed to protect.
What Genuine Operational Discipline Looks Like
Govern Outcomes, Not Activities
The fundamental error of process orthodoxy is governing activities rather than outcomes. A governance model that asks “did you follow the process?” will always produce compliance. A governance model that asks “did you deliver what you promised?” will produce accountability.
| Governance Question | Process Orthodox Answer | Outcome-Focused Answer |
|---|---|---|
| Is this programme on track? | All stage gates passed, all documents approved | Working capability delivered to users on schedule |
| Is our change process effective? | 98% of changes follow the approved workflow | Mean time from identification to deployment is 48 hours |
| Are we managing risk? | Risk register updated, all risks have owners | Number of production incidents trending downward |
| Is our IT function mature? | CMMI Level 3 certified | Customer satisfaction scores improving quarter on quarter |
This shift is harder than it sounds. It requires governance bodies to accept that they cannot see and approve every activity — that their role is to set direction, define acceptable outcomes, and hold leaders accountable for results. It requires replacing the comfort of procedural certainty with the discomfort of outcome-based accountability.
Right-Size the Process to the Risk
Not every change carries the same risk. Not every project requires the same governance. Not every release needs the same approval chain. Yet most organisations apply the same process to a two-hour bug fix and a six-month platform migration.
Effective operational discipline differentiates. Low-risk, well-understood changes should move through lightweight, automated approval paths. High-risk, complex changes should receive proportionate scrutiny. The criteria for differentiation should be explicit, objective, and regularly reviewed — not left to the judgment of a change coordinator who defaults to caution because caution is never punished.
Measure the Cost of the Process Itself
Every process should be subject to the same scrutiny it imposes on the work it governs. How much time does this process add? How much does that time cost? What would happen if we simplified or eliminated this step? These questions are almost never asked, because the process is assumed to be necessary — a fixed cost of doing business rather than a variable that can be optimised.
The organisations I have seen handle this well conduct a quarterly process audit — not of compliance, but of value. For each major process, they measure elapsed time, touch points, and rework. They ask teams what they would change. They pilot simplifications and measure the impact. They treat process as a product that must earn its place, not a monument that must be preserved.
The Deeper Problem
Process orthodoxy persists because it serves a psychological need that has nothing to do with operational effectiveness. In a world of complex, uncertain, interdependent technology programmes, process offers the illusion of control. If we follow the steps, if we complete the templates, if we attend the reviews, then surely the outcome will be predictable. Surely we have done everything we could.
This is a comforting belief. It is also false. The evidence of the last decade — the programme failures, the cost overruns, the benefits that never materialised — is not evidence that we need more process. It is evidence that process, beyond a certain point, is not the answer.
The organisations that will deliver effectively in the coming years are not the ones with the most comprehensive process libraries or the highest maturity ratings. They are the ones with the judgment to know when process helps and when it hinders — and the courage to strip away the layers of procedural overhead that have accumulated not because they add value, but because nobody has dared to ask whether they do.
Best practice is a useful starting point. It becomes worst practice the moment it stops being questioned.