Your Programmes Are All Individually Approved. That's Exactly Why They're Competing for the Same People.

A governance layer that prioritises initiatives on value and real capacity, with clear decision rights, needed once more than one significant change programme runs at once and none of them has a way to see the others. Below that threshold, informal coordination usually works fine; above it, the same people and the same budget start getting claimed by multiple programmes simultaneously, and something has to arbitrate.

A PMO typically tracks project delivery; a TMO governs the whole portfolio on value, capacity, and cross-programme dependencies, with decision authority attached rather than just reporting visibility. A PMO can tell you a project is three weeks behind schedule; a TMO is positioned to decide whether that project should still be a priority at all, given everything else competing for the same capacity across the organisation.

Start with a health check on what's actually running, then design portfolio prioritisation, decision forums, a management cadence, and benefit tracking in that order. Skipping the health check and jumping straight to designing governance structures is a common mistake, the governance only works if it's built around what's genuinely happening in the organisation, not around an idealised picture of what leadership assumes is happening.

One prioritised list weighted by contribution and effort, tested against real capacity, not separate approvals per programme that never get compared against each other. Separate approval processes are how five individually reasonable programmes end up competing for the same twelve people in the same quarter, a collision nobody sees coming because no single approval process was ever designed to check against the others.

Make capacity and cross-programme dependencies visible in one place, so conflicts surface before they hit the calendar, not after commitments have already been made to multiple sponsors. Most capacity conflicts aren't the result of bad planning; they're the result of good planning done in isolation, where each programme owner reasonably assumed their required people would be available because nobody showed them otherwise.

Design decision forums with an actual mandate and a defined turnaround time, vague ownership is the usual cause of drift, far more often than the decision itself being genuinely difficult. A forum that meets monthly but has no real authority to decide anything just adds a month of delay to every decision that passes through it, while giving the appearance that governance is happening.

Tie every initiative to a measurable outcome and report on that outcome, not on hours spent or milestones hit, which measure effort rather than whether the effort actually produced anything. A programme can hit every milestone on schedule and still fail to deliver the benefit it was funded to produce, activity tracking simply can't tell the difference, which is exactly why it isn't sufficient governance on its own.

Benefit realisation against target, capacity conflicts, and cross-programme dependencies, not percent-complete bars that measure how much work has happened rather than how much value it has produced. A dashboard full of green progress bars can sit alongside a portfolio that's quietly failing to deliver any of the benefits it promised, because progress and value are simply different things to measure.

Define weekly, monthly, and quarterly cycles, each with its own purpose and agenda, down to item level, so meetings don't drift into whatever feels urgent that particular week. A cadence without clearly separated purposes tends to collapse into one long recurring status update, where weekly, monthly, and quarterly meetings all end up covering roughly the same ground because nobody defined what belongs at which level.

Map them explicitly in the governance design so conflicts are visible in advance, not discovered mid-execution when the cost of resolving them is already much higher. Dependency mapping done once at the start of a transformation and never revisited tends to go stale within a quarter, the exercise needs to be a living part of the cadence, not a one-time diagram filed away after kickoff.

Either works, we set it up and hand it over, or staff it directly with a transformation lead, typically the realistic choice when internal capacity is already stretched thin by the transformation itself. Building internally makes sense when the organisation has spare senior capacity to dedicate; bringing someone in makes sense when the people who'd need to run the TMO are the same people already fully committed to the programmes it would govern.

Not because an outsider knows better, but because they can ask the questions that are politically hard to ask internally, without the career risk an internal person would face asking the same question. An internal transformation lead reports to someone, has peers whose programmes might get deprioritised, and has a career trajectory that can be affected by whose feathers get ruffled, an external party has none of those constraints.

Build continuous improvement into the cadence without disrupting daily operations, a transformation that shuts down the shop gets reversed, usually quickly and at real cost to trust in future change efforts. The cadence needs to be designed around the operational rhythm the business already runs on, not layered on top of it as an additional burden competing for the same people's attention.

Combine short cycles that show visible results with a clear line back to the long-term ambition, speed without direction is just activity, and direction without visible short-term progress just looks like talk. Momentum dies specifically in the gap between the kickoff energy and the first visible result; a cadence built around short, demonstrable wins is what keeps that gap from ever opening too wide.

Report benefit realisation against plan, not milestone completion, that's what a management cadence and benefit tracking are built to produce, and it's a fundamentally different conversation than a status update. A board asking whether a transformation is working wants to know if the promised value is materialising, not whether the Gantt chart is on schedule, those two questions can have very different answers at the same point in time.