When Process Maturity Became Process Paralysis — The PRINCE2/ITIL Orthodoxy and Its Unintended Consequences
Much of the process apparatus that organisations have built over the past five years exists not to improve delivery but to manage accountability.
The Orthodoxy Trap
There is a moment in the life of any process framework when its adoption ceases to be a means and becomes an end. In my experience, that moment arrived for PRINCE2 and ITIL sometime around 2005, and by now — late 2007 — the consequences are visible in almost every large organisation I encounter.
The pattern is remarkably consistent. An organisation adopts PRINCE2 as its project management standard. It invests in training. It certifies its project managers. It builds templates, stage-gate processes, and reporting hierarchies. And then, almost imperceptibly, the framework begins to calcify. What was intended as a flexible, tailorable method becomes a rigid compliance exercise. The question shifts from what does this project need? to have we completed the required documentation?
This is not a failure of the frameworks themselves. Both PRINCE2 and ITIL, properly understood and properly applied, offer genuine value. The failure lies in what happens when organisations confuse the adoption of a framework with the development of a capability.
Certification as Currency
The certification industry that has grown up around PRINCE2 and ITIL deserves particular scrutiny. The market for practitioner and foundation certificates has expanded dramatically over the past three years, driven partly by procurement requirements — many public sector contracts now mandate PRINCE2 certification — and partly by the entirely rational desire of individual professionals to demonstrate competence.
The difficulty is that certification demonstrates knowledge of a method, not the ability to apply it. A PRINCE2 Practitioner certificate confirms that someone can answer examination questions about tolerances, exception reports, and product-based planning. It tells us nothing about whether they can navigate the political complexity of a cross-departmental programme, manage a supplier who is underperforming, or make the difficult decision to stop a project that has lost its business justification.
The pattern I have observed repeatedly is this: organisations recruit or promote on the basis of certification, then discover that their newly certified project managers cannot deliver. The response, almost invariably, is to add more process — more templates, more checkpoints, more governance layers — on the assumption that if people are failing, they need more structure. This creates precisely the wrong dynamic. It buries capable practitioners under administrative burden while doing nothing to address the capability gap in those who lack it.
The ITIL Parallel
The same dynamic plays out in IT service management. ITIL has become, for many organisations, not a set of practices to be adapted to context but a compliance requirement to be satisfied. Service desks are built around ITIL process flows rather than around the needs of the people they serve. Incident management, problem management, and change management become bureaucratic procedures rather than practical disciplines.
The most telling symptom is the change advisory board that meets weekly to review a backlog of change requests, most of which could be approved — or rejected — in minutes by someone with the right authority and the right information. Instead, they queue for days, waiting for a committee that exists primarily because the process says it should. In the name of risk management, organisations have created mechanisms that are themselves a source of risk: delay, frustration, and the quiet workaround culture that grows wherever formal process becomes disconnected from operational reality.
The Structural Forces
Why does this pattern persist? The answer lies not in the frameworks but in the organisational incentives that surround their adoption.
- Procurement and contract requirements drive certification as a gatekeeping mechanism. Public sector organisations, in particular, use PRINCE2 certification as a proxy for competence when selecting suppliers and contractors. This creates a market incentive for certification that is largely independent of any interest in genuine capability development.
- Risk aversion in governance structures favours process compliance over outcome delivery. A programme board that can demonstrate adherence to a recognised framework has a defensible position if things go wrong. A programme board that stripped back process in favour of faster delivery has no such defence, even if the outcome is better.
- The consulting and training industry has a commercial interest in complexity. Every additional process element, every new template, every governance layer represents a potential engagement. The simplification of a framework is, from this perspective, a threat to revenue. This is not a conspiracy; it is simply the way market incentives operate.
- Career structures within organisations reward process ownership. The PMO that manages a comprehensive set of templates, reports, and stage-gate reviews has a clear institutional role. The PMO that focuses narrowly on removing obstacles to delivery has a less visible one.
The Gap Between Framework and Practice
The deeper issue is one of translation. Both PRINCE2 and ITIL are, at their core, sensible collections of practices. PRINCE2’s emphasis on business justification, defined roles, and management by exception is sound. ITIL’s service lifecycle model reflects a genuine understanding of how IT services should be designed, delivered, and improved.
The gap opens when these frameworks are treated as prescriptions rather than as starting points. In my experience, the organisations that derive genuine value from PRINCE2 are those that invest as much effort in tailoring it as they did in adopting it — stripping away what is unnecessary, adapting what remains to their specific context, and continually questioning whether the process is serving the work or the work is serving the process.
This kind of intelligent tailoring requires something that no certification can provide: judgement. It requires programme and project managers who understand not just what the framework says but why it says it, and who can therefore make informed decisions about when to follow the standard approach and when to deviate from it. It requires governance structures that reward outcomes rather than compliance. And it requires organisational leaders who understand that the adoption of a framework is the beginning of a capability journey, not the end of one.
The Maturity Model Illusion
The proliferation of maturity models — CMMI, P3M3, and their derivatives — compounds the problem. These models offer a seductive promise: that organisational capability can be measured on a simple scale, and that progress consists of moving from one level to the next.
The difficulty is that the attributes measured by most maturity assessments — documented processes, defined roles, consistent reporting — are precisely the attributes of process compliance rather than delivery capability. An organisation can score highly on a maturity assessment while consistently failing to deliver its programmes. The assessment measures whether the right processes exist, not whether they produce the right results.
The most process-mature organisations are not always the most capable. In some cases, they are the least — because the energy that should flow into delivery has been redirected into the maintenance of the process apparatus itself.
This is not an argument against measurement. It is an argument against measuring the wrong things. What matters is not whether an organisation has a defined benefits realisation process, but whether its programmes actually realise their benefits. What matters is not whether change requests are logged and categorised according to ITIL taxonomy, but whether changes are made safely, quickly, and in response to genuine need.
Towards a Different Relationship with Process
The question for organisations entering 2008 is not whether to use PRINCE2, ITIL, or any other framework. The question is how to use them well.
This means, first, recognising that framework adoption is not capability development. Certification is a starting point, not an endpoint. An organisation that has trained all its project managers in PRINCE2 has not thereby become capable of delivering complex programmes; it has simply given its people a common language and a common reference point. The harder work — developing judgement, building experience, creating cultures that value delivery over compliance — lies ahead.
It means, second, investing in tailoring rather than in standardisation. The frameworks themselves acknowledge this: PRINCE2 explicitly describes itself as a method to be tailored to context. Yet the dominant pattern in most organisations is standardisation — the creation of a single, comprehensive set of templates and processes that all projects must follow regardless of their size, complexity, or risk profile. This is the opposite of what the framework intends.
And it means, third, changing the way governance works. A governance structure that asks have you completed the business case template? is measuring compliance. A governance structure that asks is this programme still worth doing, and are we confident it can be delivered? is measuring something far more valuable.
“The organisations that will navigate the next wave of transformation successfully are not those with the most process, but those with the most relevant process — and the judgement to know the difference.”
The Uncomfortable Truth
There is an uncomfortable truth at the heart of the current orthodoxy: much of the process apparatus that organisations have built over the past five years exists not to improve delivery but to manage accountability. The documentation, the stage gates, the governance layers — these are, in many cases, mechanisms for distributing blame rather than mechanisms for enabling success.
This is not a cynical observation. It is a structural one. In organisations where failure carries severe personal consequences, process becomes a form of institutional insurance. If the project fails, the project manager can point to the completed risk register, the approved business case, the signed-off stage-gate review. The process has been followed. The failure, therefore, is not their fault.
The cost of this dynamic is enormous, but it is largely invisible. It manifests not as a single dramatic failure but as a steady drain on pace, on energy, on the willingness of capable people to work within the system rather than around it. The best practitioners — those with the judgement and experience to deliver complex work — are precisely those most frustrated by process that adds burden without adding value. The risk is that they disengage, work around the system, or leave altogether, while the organisations they leave behind conclude that what is needed is yet more process.