When Governance Collapses in Plain Sight
A few years ago, I was brought in to assess a digital transformation programme that had been running for eighteen months, consumed a significant budget, and delivered almost nothing deployable. The client — a mid-sized logistics company — had done everything they were told was correct. They had hired a programme manager, created a steering committee, written a project charter, and configured a project management tool that nobody used after the third week.
When I sat with the steering committee in the first session, I asked a simple question: who had the authority to stop or reshape this programme if something was clearly going wrong? The room went quiet. Three people looked at each other. Eventually, the CTO said, “Well, that would probably come from me, after a conversation with the CEO.” The programme manager, sitting at the same table, had no such authority. The delivery leads had even less. Eighteen months in, and no one had a clear answer to one of the most fundamental governance questions imaginable.
That is not an unusual situation. It is, in my experience, close to the norm.
Project governance is one of the most discussed and least understood disciplines in digital project management. It generates a lot of documentation — RACI matrices, governance charters, escalation paths — and very little actual control. Organisations treat it as a compliance exercise: a box to tick before work begins, rather than a living system that shapes how decisions are made and enforced throughout the life of a project.
Designing a governance framework from scratch forces you to confront questions that most organisations avoid: Who actually decides? What happens when they disagree? Who enforces quality? What happens when scope drifts? What is the cost of inaction compared to the cost of intervention? These are uncomfortable questions precisely because the answers require political clarity, not just process design.
This article is about how to design governance that functions — not governance that looks good in a slide deck.
Understanding What Governance Is Actually For
Before designing any framework, it is worth being precise about what governance is meant to achieve, because most organisations get this wrong from the outset.
Governance is not primarily a reporting mechanism. It is not a set of status meetings or traffic-light dashboards. It is not the escalation chain you invoke when everything has already gone wrong. Governance is the architecture that determines how authority flows, how decisions are made, how risks are owned, and how accountability is enforced across the life of a project or programme.
When governance works, it is nearly invisible. Decisions happen at the right level, with the right information, by the right people. Problems surface early, when they are still manageable. Risks are tracked and mitigated before they become incidents. Scope changes go through a rational process rather than being absorbed informally. Quality is maintained not because someone is checking constantly, but because the incentive structures and review mechanisms make poor quality visible and costly.
When governance fails, it fails in predictable ways. Decisions get escalated to leaders who lack context. Risk logs become ceremonial documents nobody reads. Scope expands without formal approval because informal approval is faster and easier. Accountability becomes diffuse — everyone agreed in principle, so no one is responsible in practice. And by the time the failure becomes undeniable, the project has accumulated so much momentum and political investment that changing course feels impossible.
The purpose of a governance framework, then, is to prevent this failure mode by building the conditions under which good project behaviour is the default, not the exception. It is an architecture of authority, information, and accountability — and like any architecture, it must be designed deliberately, not assembled from generic templates.
The Five Pillars of a Functional Governance Framework
A governance framework that actually works is built on five interconnected pillars. Each pillar addresses a specific failure mode. Together, they create a system where the people responsible for delivery have the authority and information they need, and where the people responsible for oversight have the visibility and control they require.
Pillar One: Authority Architecture
The single most important question in governance design is: who has the authority to make which decisions, and under what conditions can that authority be overridden?
This sounds simple. It is not. Most organisations have authority that is formally assigned but informally negotiated — which means it is effectively undefined when it matters most. The steering committee nominally approves scope changes, but the client relationship manager approved a scope change in a coffee conversation, and now the project team is halfway through delivering it. The CTO nominally owns technical architecture decisions, but the delivery partner has been making those decisions for six weeks because the CTO was unavailable and no one wanted to wait.
Authority architecture requires three things. First, explicit decision categories: a taxonomy of the types of decisions that arise in a project — scope, budget, technical direction, resource allocation, risk acceptance, vendor selection — with clear designation of who has authority over each. Second, decision thresholds: criteria that determine whether a decision can be made at the delivery level, requires escalation to programme level, or requires steering committee intervention. These thresholds are typically defined by financial value, strategic impact, and risk severity. Third, authority substitutes: when the designated decision-maker is unavailable, who holds their authority, for how long, and with what constraints?
Without this level of explicitness, authority becomes a social negotiation rather than a structural mechanism — and social negotiations consistently favour the loudest voice, the most senior title, or the most immediate deadline, none of which are reliable guides to good decisions.
Pillar Two: Information Architecture
Authority without information is worthless. The second pillar of governance design is ensuring that the people who need to make decisions have access to the information required to make them well, in a format they can actually use, at the time they need it.
This is where most governance frameworks collapse in practice. The organisation builds elaborate reporting structures — weekly status reports, monthly programme dashboards, quarterly steering committee packs — without asking whether these artefacts actually surface the information that drives good decisions. Status reports written by delivery teams are almost always optimistic. Dashboards aggregate data in ways that obscure critical signals. Steering committee packs are prepared by people whose career interests are served by presenting progress positively.
Effective information architecture requires a different approach. It starts by asking what questions the governance layer needs to be able to answer at any given point: Is this project on track to deliver its intended outcomes? Are the risks being managed effectively? Is the team operating with sufficient clarity and resource? Are there signals of systemic problems that are not yet visible in the headline metrics? Then it works backwards from those questions to determine what data needs to be collected, how it needs to be structured, and who needs to see it.
The critical design principle here is independence of reporting from delivery. When the people delivering a project are also the primary source of information about its health, the information will be systematically biased. Effective governance creates mechanisms for independent visibility: objective metrics that the delivery team cannot manipulate, direct access by the governance layer to technical environments and logs, structured challenge sessions where the delivery team must defend their assessments against external scrutiny. This is not distrust. It is architecture.
Pillar Three: Risk Ownership
Risk management is the governance pillar that most organisations approach with the least seriousness, which is remarkable given that it is the primary mechanism for preventing failure.
The typical risk log — a spreadsheet somewhere that lists risks with probability and impact scores and names a risk owner who updates it reluctantly before monthly meetings — is not risk management. It is risk documentation. These are not the same thing. Risk documentation creates a record. Risk management creates change in the probability or impact of adverse outcomes.
Effective risk ownership in a governance framework requires three things that most organisations skip. It requires clarity about what risk ownership actually means: the person named as owner of a risk is responsible for actively managing its probability and impact, not merely for reporting its status. It requires resource allocation: risk mitigation requires action, and action requires time, budget, and capacity — if governance doesn’t explicitly allocate resources to risk management, it will always lose out to delivery pressure. And it requires escalation triggers: defined thresholds at which a risk is automatically escalated to the next governance level, regardless of whether the risk owner believes escalation is necessary.
That last point is politically difficult but structurally essential. Risk owners, like delivery teams, have career incentives that discourage escalating problems. A governance framework that relies solely on voluntary escalation will consistently receive escalations too late. Automatic triggers — based on probability thresholds, impact thresholds, or elapsed time without resolution — remove the human delay from the escalation decision.
Pillar Four: Quality Gates
A governance framework without quality gates is a framework that has surrendered control of outcomes. Quality gates are the structural mechanism through which the governance layer maintains visibility and authority over delivery quality at defined points in the project lifecycle.
The purpose of a quality gate is not bureaucratic. It is to create a moment of explicit assessment — is this project ready to proceed to the next phase? — before decisions become irreversible and costs become sunk. The most expensive point at which to discover a quality problem is after deployment. The least expensive point is before development begins. Quality gates create a series of intervention points that distribute this discovery across the project lifecycle.
Effective quality gates have three characteristics. They are defined before the project begins, not added retrospectively when problems emerge. They have objective exit criteria — specific conditions that must be met before the gate is passed — rather than subjective assessments made by people with competing interests. And they have teeth: the governance layer must be prepared to hold a gate, delay a phase, or require remediation, even under commercial pressure.
This last point is where most quality gate systems fail. The gate exists formally, but when the delivery team arrives at it two weeks late with 70% of the exit criteria met, the steering committee approves the pass because the commercial deadline is immovable. Once this happens twice, the quality gate becomes ceremonial. Teams learn that gates are negotiations, not standards. The governance system has been taught that it does not actually control quality.
Designing quality gates that hold requires two things beyond the gates themselves: a governance layer with genuine authority to hold them, and a commercial structure that does not systematically override quality decisions. This is an organisational design question as much as a governance design question.
Pillar Five: Enforcement and Consequence Architecture
The fifth pillar is the one nobody wants to discuss: what actually happens when the governance framework is violated?
This is not a pleasant question. It implies conflict, consequences, and the exercise of authority in ways that disrupt relationships. But it is the question that determines whether a governance framework is real or theatrical. A framework without enforcement mechanisms is a collection of documents that will be ignored whenever adherence becomes inconvenient.
Enforcement architecture has three components. First, visibility: violations must be detectable. If scope changes can be approved informally without passing through the governance mechanism, the governance mechanism cannot detect the violation. Enforcement requires that the governance framework is structurally embedded in the workflows of delivery, not sitting alongside them. Second, escalation: when a violation is detected, there must be a defined process for raising it and a defined expectation of response. Third, consequence: there must be actual consequences for persistent non-compliance. These consequences need not be punitive. They may take the form of increased oversight, mandatory reporting requirements, or formal risk escalation. But they must exist, and they must be applied consistently.
The absence of consequence architecture is the most common reason governance frameworks fail. Organisations design elegant structures, define clear authorities, build information systems, establish quality gates — and then do nothing when the framework is circumvented. Within a project cycle or two, everyone has learned that the governance framework is optional. Rebuilding it from that point is far harder than building the enforcement architecture in the first place.
Designing for Your Context, Not a Template
One of the most persistent mistakes in governance design is adopting a framework from a textbook, a consulting firm’s methodology, or a previous organisation and assuming it will transfer intact. It will not.
Governance is context-sensitive in ways that go beyond the standard project variables of size, complexity, and duration. The culture of decision-making in the organisation — how people relate to authority, how comfortable they are with conflict, how well they tolerate uncertainty — shapes what governance structures will actually function in practice. The power dynamics between client and delivery partner, or between business and technology, shape which governance mechanisms will be respected and which will be gamed. The maturity of the team’s technical and delivery practices shapes what quality gates are credible and what information is reliably available.
This means that governance design requires diagnosis before design. Before drawing any framework, you need to understand the specific failure modes of this organisation in this context. What decisions routinely get made at the wrong level? Where does information consistently fail to surface? Which risks are systematically underestimated or ignored? Where have quality standards been compromised under commercial pressure? The answers to these questions should directly shape the governance structures you build.
This diagnostic approach also means that governance frameworks should be iterated, not set once. The framework appropriate for a project in its initiation phase — when uncertainty is high, authority needs to be centralised, and information flows are being established — is different from the framework appropriate for the same project in its execution phase, when delivery rhythms are established and the governance layer can shift from close oversight to exception-based management. Building this adaptability into the framework from the outset requires explicit review points at which the governance model itself is assessed and adjusted.
The Risks You Will Face in Implementation
Designing a governance framework is intellectually manageable. Implementing one in a real organisation is a different challenge entirely, and it is worth being direct about the forces that will resist it.
The first and most significant resistance comes from senior leaders who have operated comfortably in environments where their informal authority was uncontested. A governance framework that explicitly defines decision rights and limits informal approval creates constraints that some leaders will experience as threatening. They will not say this directly. They will raise concerns about bureaucracy, about slowing things down, about trust and relationships. What they mean is that the framework limits their ability to operate outside the rules they are nominally endorsing. Managing this requires political skill, not just framework design.
The second resistance comes from delivery teams who have learned to work around governance rather than through it. If the existing informal channels are faster and more reliable than the formal ones — which they usually are, because informal governance has years of established practice — rational actors will use the informal channels. The governance framework only becomes the preferred route when the formal mechanisms are demonstrably more efficient or when informal circumvention carries real consequences. Early in implementation, this means the governance layer must actively make itself useful: fast to respond, clear in its decisions, genuinely supportive of delivery rather than a source of friction.
The third and most structural risk is governance capture. This occurs when the governance layer — the steering committee, the programme board, the governance function — becomes a stakeholder in the project’s perceived success rather than an independent assessor of its actual health. Governance capture happens when the people responsible for oversight have reputational or financial skin in the project’s narrative. Once captured, the governance layer will suppress difficult information, approve gate passes that should be held, and manage communications to protect the project’s image rather than its outcomes. Preventing governance capture requires deliberate independence: people in the governance layer must not have personal stakes in the project’s perceived success, and there must be channels through which accurate information can surface even when it is politically inconvenient.
A Governance Framework Built to Last
There is a version of project governance that exists only to satisfy external scrutiny — auditors, regulators, clients who want to see a governance slide in the kick-off deck. And there is a version that actually shapes how projects are run, how decisions are made, and how failures are caught before they become catastrophes.
The difference between these versions is not sophistication. I have seen extraordinarily complex governance frameworks that were entirely theatrical, and simple ones that provided genuine structural control. The difference is intentionality — whether the framework was designed to answer the hard questions about authority, information, risk, quality, and enforcement, or whether it was designed to give the appearance of having answered them.
Building governance from scratch is an opportunity that most organisations do not get. Usually, frameworks are inherited, adapted, or retrofitted onto programmes that are already in trouble. If you have the chance to design from a blank page, the imperative is to resist the pull of templates and instead work backwards from the specific failure modes you are trying to prevent, the authority structures that will actually be respected, and the enforcement mechanisms you are genuinely prepared to apply.
Governance that holds is governance that was built with an honest assessment of the organisation’s actual behaviour, not its aspirational behaviour. It is governance that assumes people will act in their rational self-interest, not their civic best interest. And it is governance designed not to eliminate the need for judgment, but to ensure that judgment is exercised at the right level, with the right information, by the right people.
That is the job. It is harder than it looks, but it is entirely doable — if you are willing to be honest about what you are actually building.