Programme Management.

The delivery infrastructure that holds transformation together. Governance that enables decisions. RAID that surfaces real risks. Benefits tracking from day one.

2.4x more likely to achieve full ROI with a pre-programme baseline and formal month 12 review

Prosci (2023)

CN writes month 12 into every SoW. This is not aspirational — it is contractual. Full evidence →

Full practitioner methodology in the CN Portal Log in →

The key principles

How CN approaches this work.

Programme governance must enable decisions, not report on them

The primary purpose of programme governance is to enable the decisions the programme needs to make — resourcing, prioritisation, scope, go/no-go. Governance that exists primarily to receive reports and provide assurance is governance that slows the programme without adding value.

RAID is a live delivery tool, not a compliance document

A RAID log that is maintained for governance theatre and never acted upon is evidence of programme management that has confused process with output. Every risk must have an owner, a mitigation action, and a review date. Every issue must have a resolution path. Every dependency must have a named owner on both sides.

Benefits tracking begins at baseline, not at go-live

A programme that begins tracking benefits at go-live has no baseline against which to measure. Benefits tracking requires establishing the current-state measurement before the programme starts, defining precisely what will be measured and how, and tracking throughout the programme — not just at the end.

Dependencies are the most under-managed programme risk

Most programme failures involve a dependency that was known but not actively managed. Dependency tracking requires knowing not just what the programme depends on, but who owns that dependency, what the consequence of failure is, and what the early warning signs of a problem look like.

The programme plan is a living document

A programme plan that is baselined in month one and not updated until the programme is in trouble has failed in its primary purpose. The plan is the mechanism through which the programme team understands where it is, what it needs to do next, and what the consequences of delay are.

What good looks like

✓Programme governance designed to make decisions, not receive reports
✓RAID actively managed — every risk with an owner, action and review date
✓Benefits baseline established before programme starts
✓Dependencies tracked with named owners on both sides
✓Programme plan updated regularly and used to drive decisions
✓Escalation path clear — programme team knows what requires sponsor decision

Warning signs

✗Governance meetings that brief but never decide
✗RAID log maintained but never acted upon
✗Benefits tracking started at go-live with no baseline
✗Dependencies listed but not actively managed
✗Programme plan last updated at the start of the programme
✗No clear escalation path — issues accumulate rather than being resolved

Diagnostic questions

Use these in client conversations or team reviews to quickly surface where the real issues are.

QFor the last three issues raised in the RAID log: what was the resolution, who made the decision, and how long did it take?

QCan you demonstrate the benefits baseline that will be used to measure success at month 12?

QFor each cross-programme dependency: who owns it on both sides, and when was it last actively reviewed?

Full Practitioner Guide

The complete methodology is in the CN Portal.

The full guide covers: programme governance design, RAID management methodology, benefits baseline and tracking framework, dependency management approach, programme reporting design, change control process, and the month 12 close-out methodology.

Access Portal Join the network