What is delivery governance?

Delivery governance vs project governance

Project governance oversees work in flight: steering committees, stage gates, status reviews, escalation paths. It assumes the commitment was sound and concentrates on keeping it on course. Delivery governance sits one step earlier and questions the assumption — it governs whether a specific demand is understood, owned, sized by the delivering team and unblocked enough to be promised at all.

The distinction is where the leverage is. A weak commitment can be steered diligently and still miss, because the miss was decided when it was promised; a sound commitment needs far less steering. Most organisations are heavy on project governance and have no delivery governance at all — the decision to commit happens in a meeting, leaves no record, and is unexaminable by the time it fails.

What delivery governance looks like in practice

Three mechanisms, all records rather than meetings. A readiness bar before commitment: problem, outcome, owner, a capacity figure from the delivering team, dependencies, and the open questions written down as unknowns. A recorded exception when committing early anyway — why now, what is missing, who accepts the risk, what would change the decision — so real deadlines are served without the gamble disappearing. And an honest close: what shipped versus what was promised, with the difference in words when the result was not clean.

None of it requires a committee. It requires that the three moments where delivery is actually decided — the yes, the early yes, and the close — each leave a record someone can later read and disagree with.

A minimal delivery governance framework

The framework is three records, written in a fixed order, each by a named person and none of them after the fact. It needs no charter and no new tool. The readiness record comes first: the demand's answers against the bar. The owner of the demand writes it before any commitment is made, and one line on it is not the owner's to write: the capacity figure comes from the lead of the team that will do the work.

The recorded exception comes second, and only when the bar has not been cleared. It is written at the moment of commitment by whoever is making the promise, and it names one person as accepting the risk. The honest close comes last. The owner writes it when delivery ends, as a comparison with what was promised, and adds one written lesson before the demand counts as complete.

The order is what makes it a framework. A close can only be compared with a commitment that was written down, and an exception can only be counted against a bar that existed. Start with the next commitment, not the whole portfolio, and add nothing to the bar until a quarter's closes show what it is missing.

Who does what

Four roles are involved, and one person can hold more than one of them. The requester states the need: what needs to change, and who is affected or why it matters now. The requester does not size the work or set its priority, and is owed an answer they can read, including a no. The owner is one named person, never a team, who is accountable for the decision about the demand: whether it is understood, whether it is ready, and what happens to it next. The owner writes the readiness record and the close.

The delivering team's lead gives the capacity figure and stands behind it. A number estimated by the requester, or by the owner on the team's behalf, is a guess about someone else's time. The lead is also the person who can say not yet, and a commitment made over that answer is an early commitment that needs the exception.

The person who accepts an exception is named in it as an individual. They are agreeing that the organisation will commit before the evidence exists, and they are the one to ask when the condition written in the exception comes true. None of the four is a governance board, and none needs a new job title.

Delivery governance in a software team vs service-delivery governance

The words are shared with two other things that have little in common with this one. In outsourcing and IT service management, service-delivery governance is the oversight of a supplier or a managed service: service levels, performance reviews, escalation routes and contract change control, agreed between a client and a vendor. It governs a relationship and a contract. In logistics, delivery means goods arriving, and the paperwork around it — a delivery note, a proof of delivery — confirms what was received, by whom and in what condition.

Delivery governance in a software or product team is neither of those. What is delivered is committed work: a migration, a feature, a platform change. What is governed is the promise: whether it was ready to be made, whether an early one was recorded as early, and how the result compared with what was promised. The parties sit inside one organisation, there is no contract to enforce and nothing to sign for.

If the problem is a supplier missing its service levels, this is the wrong sense of the term. If the problem is that dates promised by your own teams keep slipping, it is the right one.

How to tell it is working

Ask three questions at the end of a quarter, and answer them from the records, not from memory. First: how many of the quarter's commitments reached a recorded close — delivered as committed, delivered with named differences, or not delivered? A commitment that simply stopped, with nothing written down, has not been closed, and counts against the answer. Second: where the result was not clean, what differed, and do the differences cluster? Three slips that trace to an unconfirmed dependency point at planning; scope that grew mid-quarter points at a commitment made without a written out-of-scope list.

Third: how many commitments crossed the readiness bar by exception, and how many of the misses were among them? If most misses were early commitments, delivery is fine and decision discipline is not. If the commitments that cleared the bar miss just as often, the bar is checking the wrong things. Governance is working when someone who was not in the room can answer all three in a few minutes. If any of them takes a meeting to reconstruct, the record that would have answered it was never written.

Related terms

• Decision-ready demand

  A decision-ready demand is one that can responsibly be committed to: the problem stated apart from the proposed solution, an intended outcome, a named owner, a first capacity figure, the dependencies, and the open questions written down as unknowns.

• Delivery path

  A delivery path is the level of rigor a demand takes to commitment — fast-track, standard plan, strategic initiative, or urgent exception — chosen at the decision step, so a small contained demand is not forced through the ceremony a strategic one needs.

• Definition of ready

  A definition of ready is the bar a piece of work must clear before it is accepted — applied at ticket level in Scrum, and far more consequentially at commitment level, before people and a date are promised.