Plain definitions of the terms that matter in major programme delivery. Governance bodies, delivery roles, assurance practices, commercial structures. Each term written for the people who actually use it.
The organisational function that oversees, supports, and governs project and programme delivery. A PMO can range from operational project administration to a strategic capability that influences investment decisions and drives organisational outcomes.
PMOs vary widely in remit. The label is the same. What sits beneath it is not. A PMO that approves budgets and challenges business cases is a different beast from a PMO that produces status decks. Maturity is the bridge between the two.
Related: Strategic PMO · PMO maturity assessment · PMO maturity
The structures, decisions, and accountability mechanisms that hold a programme to its business case. Includes the steering committee, programme board, sponsor accountability, decision rights, and the rules that govern how change is approved.
Governance is the difference between a programme that delivers and a programme that drifts. The framework matters. The discipline of using it matters more.
Related: Governance and Advisory · Steering committee · Programme board
The governance body that makes decisions a programme team cannot make alone, holds the programme accountable to its business case, and removes obstacles that block delivery. Typically chaired by the executive sponsor.
Most steering committees meet monthly to receive updates. That is a briefing, not governance. An effective steering committee makes decisions, scrutinises reporting, manages escalations, and resolves them within a meeting cycle.
Related: What should a steering committee actually do · Programme board · Programme director
A senior governance body that sits above the steering committee in structured frameworks. Accountable for strategic direction, benefits realisation, and major investment decisions. Often combined with the steering committee in smaller programmes.
Whether a programme has both a board and a steering committee depends on scale and risk. The test is not the org chart. The test is whether strategic decisions and delivery decisions get the right level of attention from the right people.
Related: Steering committee · Benefits realisation · Business case
The document and underlying logic that justifies the programme investment. Defines the expected benefits, the cost to achieve them, the assumptions on which the case rests, and the conditions under which the investment should be reconsidered.
The business case is not a one-off justification document. It is the standard the programme must be measured against, every meeting, until the benefits are realised. A business case that is filed and forgotten is a programme governing on autopilot.
Related: Benefits realisation · Phase gate · Why digital transformations take longer
The discipline of tracking whether the outcomes promised in the business case are actually delivered, and adjusting the programme when they are not. Distinct from delivery management, which tracks output rather than outcome.
A programme can deliver every milestone on time and still fail to deliver the benefits the business case promised. Benefits realisation closes the gap between output and outcome. It is the test most programmes do not run until it is too late.
Related: Business case · Project Health Check · Why technology implementations fail
Independent review of programme health, governance, and delivery confidence. Performed by a party not directly accountable for delivery, with the purpose of giving the sponsor or board an unfiltered view of risk and progress.
Assurance is not auditing the programme team. It is giving the sponsor a second pair of eyes. Done well, it surfaces risks early enough to act on them. Done poorly, it adds reporting burden without changing decisions.
Related: Project Health Check · Independent advisor · Do you need an independent advisor
A programme reporting convention using Red, Amber, and Green to indicate health. Useful when applied with discipline. Misleading when status is set by political comfort rather than evidence. A workstream stuck on Amber for three months is rarely Amber.
RAG is a tool, not a verdict. The value is in the conversation it triggers. If the conversation never gets past the colour, the tool is failing.
Related: What a steering committee should do · Programme assurance
The vendor or consultancy contracted to configure, integrate, and deploy the platform. The SI typically leads the technical delivery and brings platform-specific expertise. Their commercial interest is in the platform being implemented, which is why client-side governance matters.
The SI is essential. The SI is also commercially aligned with the platform. Both can be true. Client-side governance is what keeps that alignment from skewing programme decisions.
Related: Client-side delivery leadership · How to hold an SI accountable · How to evaluate an SI
Senior delivery leadership engaged on the client side of a programme, accountable to the client rather than to a vendor or system integrator. Provides the experience and authority to make client-side decisions in real time without political dependency.
Programmes need delivery leadership that can act without permission, challenge without consequence, and decide without escalation. That is rare inside an organisation under transformation. It is rarer still on the SI side. It is the seat Rydel Group occupies.
Related: Pillar: Your implementation partner works for the vendor. Who's working for you? · Client-Side Delivery service · Why organisations hire independent PMO advisors
A focused, time-boxed review of a programme that produces a candid assessment of risk, governance, and delivery confidence. Distinct from continuous assurance. Used when a sponsor needs an independent read on whether the programme is on track.
Health checks are not for failing programmes only. They are most valuable when run before things go wrong, on the assumption that something probably is. Sponsors who wait until red status to commission a review have already lost time.
Related: Project Health Check service · How to recover a failing programme · Programme readiness assessment
The measure of how strategically a Project Management Office operates. A mature PMO governs decisions, holds programmes accountable to their business case, develops talent, and uses data to influence outcomes. A less mature PMO administers status reports.
Maturity is not a vanity metric. It is the difference between a PMO that protects programmes and a PMO that watches them fail in slow motion. The five dimensions are strategic alignment, governance, delivery capability, talent, and tools.
Related: What is PMO maturity? · PMO maturity assessment · Strategic PMO · PMO
A formal decision point at the boundary between programme phases (initiation, design, build, test, deploy). The phase gate is where the programme is reassessed against its business case and either authorised to continue, paused, or stopped.
Phase gates only work if they are real decision points. Most are rubber-stamps. The discipline of a real gate is the difference between a programme that course-corrects and one that compounds its early errors.
Related: Business case · Programme board · ERP programme governance
A senior practitioner engaged to provide unbiased advice on programme strategy, governance, vendor selection, or delivery decisions. Independent of the platform vendor and system integrator. Carries no commission or stake in platform selection.
Independence is the value. Without it, advice tilts toward the adviser's commercial interest, even subconsciously. With it, the sponsor gets a perspective that is structurally aligned with their outcome.
Related: Governance and Advisory · Do you need an independent advisor
The senior accountable for end-to-end delivery of the programme. Operates at the level above project managers and below the sponsor. The programme director frames decisions for the steering committee, manages cross-workstream dependencies, and holds the SI to its commitments.
The programme director is the daily owner of programme outcome. Strong directors hold the programme together. Weak directors let the SI lead the conversation. The selection matters as much as the methodology.
Related: Steering committee · System integrator · Client-side delivery leadership
The intensive support period immediately after go-live, when the new system is live but the organisation has not yet absorbed it. Typically two to eight weeks, with elevated support staffing and daily triage.
Hypercare is where programmes discover what testing missed. It is also the phase most often underfunded, because it sits after the milestone everyone was tracking. The common failure is treating hypercare as a support function rather than a governance one. Defects surfacing in the first fortnight are not just tickets. They are evidence about the quality of what was delivered, and they should be feeding a decision about whether the next phase proceeds. Programmes that exit hypercare on a date rather than on a set of criteria usually carry the unresolved items into business as usual, where they become permanent.
Related: Go-live readiness · Cutover · User acceptance testing
The controlled sequence of activities that moves an organisation from the old system to the new one. Usually executed over a defined window, often a weekend, with a rehearsed plan and a defined rollback point.
Cutover is the most rehearsable part of a programme and the least forgiving. Every task has a predecessor, the window is fixed, and the decision to proceed or roll back has to be made with incomplete information at an uncomfortable hour. Good cutover planning is unglamorous. It counts the hours, names the person accountable for each task, and establishes in advance what evidence would trigger a rollback. The question worth asking before any cutover is not whether the plan exists. It is whether the plan has been walked through end to end with the people who will execute it. And whether anyone has worked out what happens if a task in the middle runs twice as long as estimated.
Related: Go-live readiness · Hypercare · Data migration
The named individual accountable for realising a specific business benefit after the programme ends. Distinct from the programme sponsor, who is accountable for delivering the programme itself.
Most business cases name benefits. Fewer name a person against each one. That gap is why benefits realisation is the most consistently unmet commitment in enterprise transformation. A benefits owner needs authority over the operational change that produces the benefit. That usually means a line executive, not anyone inside the programme. The test of whether a benefits owner is real is simple. Ask whether they were involved in setting the target, whether they agree it is achievable, and whether it appears in their own objectives. If the answer to any of those is no, the benefit is a forecast rather than a commitment.
Related: Benefits realisation · Business case · Steering committee
A formal proposal to alter agreed scope, cost, timeline or approach, raised and assessed against the contract and the business case.
Change requests are where commercial control is either exercised or lost. Every large programme generates them and that is normal, because no scope survives contact with configuration. The risk is not their existence but their handling. A change request assessed only on cost misses the point. Four questions matter. Was the change foreseeable. Who bears the cost of not having foreseen it. What does it do to the critical path. And does accepting it set a precedent for the next twenty. Programmes that approve changes individually and never look at them in aggregate routinely discover that the cumulative effect has quietly rewritten the business case.
Related: Statement of work · System integrator · Business case
The contractual document defining what a vendor or system integrator will deliver, to what standard, by when, and for what price. Sits under a master services agreement.
The statement of work is where programme governance either gets teeth or does not. Vague deliverable definitions and undefined acceptance criteria are the most common and most expensive defect in enterprise contracts. They push the argument about whether something is finished to the point where you have nothing left to trade. A well written statement of work names the deliverable, the acceptance test, the person who signs, and the consequence of failing. It also says what is out of scope, which is often the more useful half. Reading one before signature is a two-hour job that routinely saves six figures.
Related: Change request · System integrator · Independent advisor
A structural change to a programme’s scope, plan, governance and commercial arrangements, made in response to evidence that the current approach cannot deliver. Distinct from a replan, which adjusts the schedule only.
Most programmes described as reset have been relabelled. The distinction matters because the two produce entirely different outcomes. A genuine reset removes scope. It rebuilds the plan from verified facts rather than inherited assumptions. It restructures the governance that failed to detect the original problem. And it changes the commercial terms with the delivery partner. A replan moves dates. Four questions separate them. Has scope actually come out. Has every milestone been re-estimated against real progress. Has the governance membership or cadence changed. Have the commercial terms changed. If the honest answer to any of those is no, the programme has been relabelled and the same failure will recur on a later date at a higher cost.
Related: Stage gate · Business case · Programme governance
The process of moving data from legacy systems into a new platform, including extraction, cleansing, transformation, loading and reconciliation.
Data migration is the most consistently underestimated workstream in enterprise implementation. The reason is that it is treated as technical when it is mostly a business problem. The technical movement of records is well understood. What is not is deciding which records matter, what to do with twenty years of accumulated exceptions, and who is accountable for the quality of what arrives. Those are business decisions and they cannot be delegated to an integrator. The reliable early warning sign is a migration plan with no named business owner for data quality. It means nobody has yet been made responsible for the answer to “is this data good enough to run on”.
Related: Cutover · User acceptance testing · Go-live readiness
The phase in which the business, rather than the delivery team, tests whether the system supports the work it needs to do. The last structured opportunity to find problems before go-live.
User acceptance testing fails in a predictable way. It is scheduled too late. It is staffed by people who already have full-time jobs. It is scripted so tightly that it only proves the system does what it was built to do. Then it is compressed when earlier phases run over. A test that follows a script written by the people who built the configuration will pass. That is not evidence of readiness. Effective acceptance testing gives real users real scenarios drawn from their actual work, including the awkward ones. It treats a high defect count as success rather than embarrassment. The count you should worry about is a low one.
Related: Go-live readiness · Hypercare · Data migration
A structured assessment of whether an organisation, not just a system, is prepared to operate on the new platform. Covers system, data, process, people and support.
Go-live readiness is a governance decision dressed up as a technical checkpoint. The system being functional is necessary and nowhere near sufficient. Four questions decide the outcome. Is the data usable. Have the people who will use it on Monday been trained on what they will actually do. Does the support model exist. And is there a workable answer to what happens if it does not go well. A readiness assessment that produces a green light without evidence against each of those has confirmed a decision rather than tested one. The most useful discipline is agreeing the criteria weeks in advance, while it is still possible to fail them without anyone losing face.
Related: Cutover · Hypercare · Stage gate
A formal decision point between programme phases at which continuation is explicitly approved, with defined entry criteria and the genuine option to stop or change direction.
A stage gate only works if failing it is possible. Most are not. By the time the gate arrives, the commercial commitments and the political capital make stopping unthinkable. The gate becomes a ceremony that confirms a decision already taken. A functioning gate has criteria agreed before the phase begins, evidence presented by someone who does not benefit from passing, and a chair prepared to say no. The value is not in the meeting. It is in the fact that everybody knows the criteria exist and will be tested, which changes behaviour during the phase itself.
Related: Phase gate · Programme governance · Business case
Definitions are useful. Decisions are the work. If you are sitting with a governance question that needs an independent perspective, we are happy to talk.
Get in Touch