Al Karakas
← All essays

Governance · Delivery

How Much Governance Does This Actually Need?

10 min read

Most failing programmes do not fail because they had no governance, or because they had too much. They fail because they had the wrong size of it: a five-person job buried under a steering committee, or a multi-million-pound programme running on a shared inbox and good intentions. The skill that matters is not having governance. It is right-sizing it.

I want to be honest about where this sits. Proportionate governance is not my idea, and I am not the person who is going to define it for the field. It is settled doctrine, written into the major methods for years. What I think is genuinely underdone is a usable, opinionated way to actually dial it: a model a delivery lead can hold in their head and defend to a client. That is what I am attempting here, standing on work that is much older and better-credentialed than mine.

The principle is already established

PRINCE2 makes proportionality one of its core principles, in plain words: "tailor to suit the project." The stated aim is to apply a level of management that does not overburden the team while still providing an appropriate level of governance and control at an acceptable level of risk. It pairs this with managing by stages and with continued business justification, the rule that a project must stay justified or be stopped (AXELOS, Managing Successful Projects with PRINCE2, 2023).

The APM's Directing Change, the UK profession's reference on governance, builds the same idea in. Its principles call for "appropriate" methods and controls, make independent scrutiny something the board decides is needed rather than a fixed requirement, and tie stakeholder engagement to a level commensurate with importance (Association for Project Management, Directing Change, 2nd ed., 2011). PMI frames governance as a small set of recurring functions, alignment, risk, performance and communications, applied at whatever level fits the organisation (PMI, Governance of Portfolios, Programs, and Projects, 2016).

So the question is never "process or no process." The recurring functions are constant. What changes is how much of each you bring, and when.

Governance is not paperwork you add to look serious. It is the instrumentation that lets a programme know its own state. Too little and you fly blind. Too much and you spend the budget watching dials instead of flying.

“Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.”

Antoine de Saint-Exupéry

The irreducible baseline

There is a floor below which I would not go on anything, including a five-thousand-pound task or a portfolio of fifteen tiny engagements. Not because the method demands it, but because without it you genuinely cannot tell whether the work is succeeding. The baseline is small:

A single named owner accountable for the outcome. A one-line reason the thing exists and who benefits, abandoned the moment that stops being true. The top two or three risks, written down where someone will see them. One honest go/no-go before money is committed. Status visible to the owner, even if "status" is a single sentence. And one lesson captured at the end. That is it. It maps cleanly onto the APM's core components and PRINCE2's continued business justification, and it costs almost nothing.

For a portfolio of small engagements, the move is to govern at the portfolio level, not fifteen times over. Each piece keeps only the baseline; the aggregate gets one risk view, one reporting cadence, and a limit on how much is in flight at once. The failure mode to avoid is wrapping fifteen small jobs in fifteen sets of heavyweight controls and calling it rigour. That is not rigour. It is friction wearing rigour's clothes.

Dialling it up

As value, complexity and risk grow, you add control. You never remove the baseline; you layer on top of it. The thresholds below are illustrative, and I will say plainly why in a moment, but the shape holds.

Element Baseline (every project) ~£100k adds ~£0.5m adds Multi-£m / multi-year adds
Justification One line, named beneficiary; killed if no longer true A light business case: cost, benefit, risk Business case re-confirmed at each stage Reference-class estimate; benefits realisation plan
Ownership One accountable owner Engaged sponsor with sign-off Sponsor plus a small decision group Programme board / SRO; delegated tolerances
Decisions One go/no-go before spend Start and close gates Stage gates with escalation on tolerance Staged gates plus independent assurance reviews
Scope & change Scope in a sentence or two A simple change log Change control with impact assessment Baseline control; a formal change board
Risk Top three risks, owner aware A RAID log, reviewed regularly Risk register with owners and mitigations Quantified risk, contingency, independent challenge
Reporting Visible to the owner Lightweight status to the sponsor Structured reporting with escalation criteria Board dashboard, defined KPIs, audit trail
Closure Confirm done; one lesson A short closure note Closure report; lessons logged Post-implementation and benefits review

Illustrative. Each tier adds to the baseline; nothing below is ever removed.

What this is really showing is that the function never changes. There is always justification, ownership, a decision, change handling, risk, reporting and closure. A five-thousand-pound task and a fifty-million-pound programme both have all seven. They just carry different weights of each.

Why value is the wrong axis on its own

Here is the caveat the table cannot hold. Money is a convenient proxy for risk, and a poor one. A cheap change to a core trading system can be far more dangerous than an expensive office move. What actually drives how much governance you need is the nature of the problem, not its price tag.

This is where the sense-making frameworks earn their place. Cynefin (Snowden & Boone, Harvard Business Review, 2007) separates the ordered world, where cause and effect are knowable and plan-driven control works, from the complex world, where they are not and you need to probe, sense and adapt. The Stacey view plots work by how much agreement there is on the requirement and how much certainty about the solution. Both say the same thing in different language: match the approach, and therefore the governance, to the kind of problem you are actually facing. Use value to set a starting tier, then let complexity and risk override it.

Method changes the cadence, not the functions

Whether you are running waterfall, agile or a hybrid shifts how governance looks, but not what it is for. In plan-driven work, governance shows up as stage gates, baselines and variance against plan. In agile work, it shows up as cadence: working increments, reviews, flow metrics and lean funding rather than detailed sign-off up front. The functions survive the translation. A waterfall gate and an agile funding review are the same governance act, doing the same job, wearing different clothes. Most enterprise and MSP delivery is hybrid in practice: a gate-and-funding skeleton at the top, agile delivery running inside it.

Context raises the floor

Two things move the baseline itself. The first is regulation. In financial services the floor is higher: proportionality still applies, but a three-lines-of-defence structure and an audit trail are expected even on small change. A fifty-thousand-pound change in a bank can carry more mandatory governance than a half-million-pound delivery in a less regulated setting. Right-sizing there means proportionate within a non-negotiable floor, not "skip the controls."

The second is who you are answerable to. Client-facing and vendor delivery adds commercial governance that internal IT can run lighter on: scope tied to a contract, milestone acceptance, billing, liability. In MSP delivery you carry that commercial layer on top of the delivery layer as a matter of course.

And then there is the part the frameworks underplay and the field teaches you quickly: governance has to be sized to the customer's appetite, not only to objective risk. Some clients want a heavy steering committee for a small job, for reassurance or for reasons that are entirely political. Others will hand you a multi-million-pound programme and ask you to run it lean. Right-sizing is, in practice, a negotiation between what the risk demands and what the stakeholders will accept. Pretending otherwise is how you end up with governance that is technically correct and completely ignored.

The recovery heuristic

When I am dropped into a programme that is already failing, I do not start by building the full tier. I restore the baseline first, then add only the controls that address the specific way this programme is failing. If the problem is that nobody can see the work, you install reporting and a backlog before anything else. If the problem is that bad news never reaches the sponsor, you fix the reporting line and the safety to use it. Governance added to look thorough, rather than to fix the actual failure, is just more weight on a programme that is already sinking.

What I would not claim

Three honest limits. The thresholds here are a starting heuristic, not a law; calibrate them to your organisation, and let complexity and risk overrule raw value every time. The frameworks I have leaned on are aids to judgement, not checklists, and treating them as checklists defeats the entire point. And I am synthesising other people's work, not replacing it; if you want the authoritative version, read PRINCE2, the APM guide, and Snowden directly. The contribution I will stand behind is narrower and more practical: governance is a dial, not a switch, and knowing where to set it is most of the job.

The research behind it

AXELOS, Managing Successful Projects with PRINCE2 (7th ed., 2023). · Association for Project Management, Directing Change: A Guide to Governance of Project Management (2nd ed., 2011). · Project Management Institute, Governance of Portfolios, Programs, and Projects: A Practice Guide (2016). · Snowden, D. & Boone, M., "A Leader's Framework for Decision Making," Harvard Business Review (2007). · Stacey, R.D., Strategic Management and Organisational Dynamics (1993). · Flyvbjerg, B., "The Iron Law of Megaproject Management," The Oxford Handbook of Megaproject Management (2017).