Quality and go-live · Cutover ownership
Cutover ownership: turning a RACI into named accountability
Every large program produces a RACI, and most of them are decoration. Cutover runs outside business hours against a clock, so that's where the bill comes due. Here's how to build an ownership model that still works when a load fails at two in the morning.
Most RACIs get built in a workshop where nobody wants to name a single accountable party, so the compromise is to mark several people responsible and move on. The grid gets published and filed. Nobody opens it again until something fails and somebody asks who owned it.
At two in the morning, with a load failing and a gate coming up, someone has to be woken up. A cell that reads "Client" doesn't have a phone number.
Equal partners means no partners. Every row where both organizations are marked accountable is a row where the work has no owner and the contract has no evidence.
Four numbers tell you whether a RACI is real
Check these before you read a single row. A grid that fails any of them is a picture of governance.
Never zero and never two. It's the only rule with no exceptions.
You draft a grid with roles. Before it's published, every A carries a person's name.
Client side and partner side never share one, because the grid is the evidence for the contract.
Past thirty, nobody reads it. Split it by phase instead of extending it.
The first rule comes straight from UK government project delivery guidance: there can only be one accountable person who can be held to account, and that accountability can't be delegated or shared [R3]. Where a role is formally job-shared, the guidance treats it as a single entity for accountability. The mandatory functional standard goes further and makes defining roles and accountabilities a requirement, including the outcomes each person is responsible for and the person they're accountable to [R4].
A 2026 parliamentary committee reached for the same instrument on a long-running shared services program. Two independent reviews had cited the absence of a single point of ownership, and the committee recommended appointing a single person to be in charge [R1].
What shared ownership costs
The half hour spent working out who to wake up comes straight out of float. You spend it again every time, because the problem is structural.
When client and partner share a row, the record no longer shows who owed the deliverable. In the change order conversation the grid is the evidence, and a shared row is evidence for the other side.
Two responsible parties reliably produce less than one, because each assumes the other has a portion. It's worst on the activities neither side wants: department readiness, data quality remediation and cross-organization decisions.
Escalation works by going one level above the accountable party. With nobody accountable, it goes to the steering committee, which is too slow and too senior for an operational call.
The public record shows the same thing at national scale. A national audit office performance audit of a public-sector pay system counted eleven oversight committees and concluded that what the department considered governance was in fact just a project management structure [R5]. The independent lessons review of the same program found that no individual or governance body held the authority to ensure the necessary steps were taken [R6]. On a statewide ERP where the state had left the change management plan to the implementer, 65% of agency directors and fiscal officers said the system had negatively affected their ability to carry out statutory duties [R9].
National audit work makes the design point directly. Good governance means being clear about who has authority and accountability, and that clarity matters most where decisions and accountabilities stretch across a system or a set of organizations [R2]. A client and its integrator are exactly that case.
Define the four letters tightly, then print them on the grid
Most grids fail because the letters mean different things to different signatories.
Does the work, and it can be several people. R is the only letter that can repeat in a row without weakening it. If nobody is marked responsible, the activity isn't resourced.
Answers for the outcome, has the authority to decide and carries the consequence. Exactly one. If the accountable person can't direct the people marked responsible, the assignment is wrong and the row fails quietly.
Gives input before the work is complete, so they're asked before and never told after. Keep it disciplined. A row consulted with six parties won't move.
Told afterward, one way, with no input expected. Most stakeholders belong here. Being generous with I costs nothing, while every extra C can cost weeks.
Pick the rows, then find the one each group forgets
A row is an activity. It has one owner across the whole cutover and shows up in the plan as many lines, so tasks and deliverables sit below it. Write each row as a noun phrase. Ten groups cover a cutover, and the list matters less than the row inside each group that goes missing.
Approving a change to the plan after baseline. It's usually undefined, so anyone edits.
Granting exceptions during the freeze. This always happens and is almost never assigned.
Accepting the reconciliation, as distinct from performing it.
Coordinating third parties, which sits between the integration team and the vendor manager.
Removing legacy access. Nobody wants it and auditors always ask.
Lifting the change freeze, which decides when normal change resumes.
Department attestation. Every candidate owner tends to decline it.
Rollback authority. Everyone assumes it sits with the sponsor, and it's rarely confirmed with them.
Status during the window to audiences outside the command center.
Tier three definition, and who owns the escalation into it.
Draft the columns from the org chart, then correct it for who's part time, who splits duties and who has a vacancy underneath them. Add the columns nobody asks for: department representatives, the vendor manager, the security function and the service desk that inherits the calls. That's exactly where the unowned rows end up.
Use the sponsor column sparingly, on the go decision, rollback authority and anchor date changes only. A sponsor accountable for ten rows is accountable for none. And never create a column for a group. Groups decide things, but only an individual can answer for a row.
Give the client and the partner their own columns
This single change does most of the work, and it's usually agreed quickly once it's framed correctly.
| One column per function | Two columns per function |
|---|---|
| A functional lead column holds both organizations. | The client functional lead and the partner functional lead each get a column. |
| A row can be marked accountable with two people behind the letter. | Each row has exactly one accountable, a named individual in one column. |
| Handoffs between the organizations are invisible, because they happen inside a cell. | Every handoff shows up as an R in one column and a C or A in the other. |
| Nobody can tell from the grid which deliverables were contracted. | Contracted deliverables show up as rows with the A in a partner column. |
| Disputes get settled by memory of who said what in which meeting. | Disputes get settled by reading the row. |
Frame it as not blurring contractual authority. That wins the argument. Frame it as accountability and it gets heard as blame, and then you spend a week on feelings instead of on the grid.
The audit record has a harder version. A national audit office found a defense ERP program's governance undermined by conflicts of interest embedded in its decision-making arrangements, with contractors involved in decisions about their own contracts. It recommended the department keep contractors out of decisions on their own contract variations [R8]. If the partner column and the client column are one column, you can't see that conflict.
A worked grid: one A in every row, and three for the sponsor
| Activity | Sponsor | Client cutover lead | Partner cutover lead | Client track lead | Partner track lead | PMO | Dept rep | A per row |
|---|---|---|---|---|---|---|---|---|
| Author and maintain the cutover plan | I | A | C | R | R | C | 1 | |
| Confirm task durations and start conditions | C | C | A | R | I | 1 | ||
| Baseline the plan | A | R | C | C | C | R | 1 | |
| Approve a change to the plan after baseline | I | A | C | R | C | I | 1 | |
| Design the freeze by transaction type | I | A | C | R | C | C | 1 | |
| Grant an exception during the freeze | I | A | I | C | I | R | 1 | |
| Execute the data load sequence | C | A | I | R | 1 | |||
| Reconcile converted data to source | C | R | A | R | C | 1 | ||
| Accept the reconciliation result | I | C | I | A | C | I | C | 1 |
| Coordinate third-party integration partners | C | C | A | R | I | 1 | ||
| Remove legacy system access | C | I | A | C | I | I | 1 | |
| Department readiness and attestation | I | C | I | C | R | A | 1 | |
| Make the go and no-go decision | A | R | C | C | C | C | C | 1 |
| Invoke rollback | A | R | C | I | C | I | I | 1 |
| Rows held as A | 3 | 4 | 1 | 5 | 0 | 0 | 1 | 14 |
- Author and maintain the cutover planA Client cutover leadR Client track lead, Partner track leadC Partner cutover lead, PMOI Sponsor
- Confirm task durations and start conditionsA Client track leadR Partner track leadC Client cutover lead, Partner cutover leadI PMO
- Baseline the planA SponsorR Client cutover lead, PMOC Partner cutover lead, Client track lead, Partner track lead
- Approve a change to the plan after baselineA Client cutover leadR Client track leadC Partner cutover lead, Partner track leadI Sponsor, PMO
- Design the freeze by transaction typeA Client cutover leadR Client track leadC Partner cutover lead, Partner track lead, Dept repI Sponsor
- Grant an exception during the freezeA Client cutover leadR Dept repC Client track leadI Sponsor, Partner cutover lead, PMO
- Execute the data load sequenceA Partner cutover leadR Partner track leadC Client cutover leadI Client track lead
- Reconcile converted data to sourceA Client track leadR Partner cutover lead, Partner track leadC Client cutover lead, PMO
- Accept the reconciliation resultA Client track leadC Client cutover lead, Partner track lead, Dept repI Sponsor, Partner cutover lead, PMO
- Coordinate third-party integration partnersA Client track leadR Partner track leadC Client cutover lead, Partner cutover leadI PMO
- Remove legacy system accessA Client track leadC Client cutover lead, Partner track leadI Partner cutover lead, PMO, Dept rep
- Department readiness and attestationA Dept repR PMOC Client cutover lead, Client track leadI Sponsor, Partner cutover lead
- Make the go and no-go decisionA SponsorR Client cutover leadC Partner cutover lead, Client track lead, Partner track lead, PMO, Dept rep
- Invoke rollbackA SponsorR Client cutover leadC Partner cutover lead, Partner track leadI Client track lead, PMO, Dept rep
- A accountable, exactly one
- R responsible
- C consulted
- I informed
- sponsor decision rows
Client and program columns Partner columns
Read down the accountable column. Accountability crosses to the client side at every acceptance and every decision, and it stays on the partner side only where the partner controls delivery. The sponsor holds three rows: the baseline, the go and no-go decision, and rollback. Every A has to be a named person who has confirmed the row in writing.
Most programs need a second grid for support and hypercare, and it's the one most often missing. Support accountability gets assumed and never assigned, which is why the first week after go-live goes on working out where calls go. Three rows decide whether the first month works: tier three definition, central versus department resolution, and the managed service boundary.
The same seven rows get contested on every program
Bring the settling argument into the session, so you aren't discovering the dispute in it.
Nobody wants thirty departments as their problem, so it lands with change management by default and isn't resourced.
Settle it. Split it. Content goes to change management, completion to a named rep in each department and the aggregate view to the PMO. One row becomes three, and all three get owned.
The partner converts what it's given. The client says the partner should have flagged it. Both are partly right.
Settle it. Accountable client side, responsible shared, plus a separate partner-accountable row for notifying the client of quality failures within a stated window.
It sits between the integration team, who know the interface, and the vendor manager, who owns the relationship.
Settle it. Accountable to whoever holds the commercial relationship, responsible to whoever knows the interface. Don't merge them.
The partner takes the work to a point and the client has to decide. Nobody writes down where that point is.
Settle it. Make each decision point its own row with a client-side accountable, and put it in the plan as a dated task.
Everyone assumes it's the partner. The contract usually says otherwise, and nobody reads it until it's needed.
Settle it. Read the agreement in the session. Where it's silent, assign it client side and raise the gap commercially.
It gets treated as a shared aspiration with no deliverable behind it, so it happens informally and incompletely.
Settle it. A partner-side accountable row with acceptance criteria, and a client-side accountable row for accepting that it happened.
Change requests keep arriving after scope freeze, and nobody owns the portfolio view or the regression consequence.
Settle it. One row for the portfolio, with the PMO accountable. One row for regression scope, with the test lead accountable.
Two of these have hard public evidence. On data, the published business case risk register for a large council ERP treated data migration volume and quality as mitigated by using a third-party supplier to manage an end-to-end migration cycle [R7]. That's the classic move: the activity transfers and the consequence stays with the client. On readiness, a state legislative evaluation found the state had intended the implementer to develop the change management plan. It called that a critical deficiency and traced generic contract deliverables and one-size-fits-all training straight back to it [R9].
When both sides claim a row, ask three questions in order
The first clear answer settles it, and you record which question did.
The agreement names it as something the partner owes. Partner-side accountable, client-side consulted. Add a paired row for accepting the deliverable, with a client-side accountable. If the agreement has no acceptance criteria for it, raise that commercially now, before acceptance comes around.
ClientCPartnerASettled by the contract. Read the clause in the room.
Completing it means choosing between options with a cost or risk consequence to the organization. Client-side accountable without exception, with the partner responsible for the analysis that supports it. Put the decision date in the plan along with the decision.
ClientAPartnerRClient side. A partner can't be accountable for a client's decision.
Delivery depends on people the partner doesn't direct, or systems and approvals it can't reach. Client-side accountable, because the partner can't deliver it. Record the dependency explicitly so the partner isn't held to it later.
ClientAClient side. Accountability follows control.
It's genuinely joint work with no contractual anchor, no decision and no access constraint. Split the row into two with a handoff between them. If it can't be split, assign it client side and escalate the ambiguity as a commercial gap.
Split it or escalate it. Never share the letter, and never leave it blank.
Skip this and an unowned client deliverable can end up in a court record. In a published High Court judgment from a large insurance sector transformation, the release plan expressly assigned the customer its own obligations: product descriptions, sprint decision-making, communication templates, non-standard business rules, all end-user training and the telephony solution [R10]. When the customer's subject matter experts under-delivered, the customer's own transformation director wrote that the supplier had stepped away and would now position this as a relief event [R10].
The grid feeds the plan, and the plan feeds the runbook
The RACI is the first link in a chain. It's only worth building if the other two get made.
Stable across the program and rarely changed. It tells you who answers for each activity. Governance meetings read it, and disputes quote it.
It changes constantly. Owner names are pushed from the grid, so the two agree by construction. If they ever disagree, the grid wins on accountability and the plan wins on who's doing the work today.
It's derived from the plan, and each gate names its decision maker from the grid. If a gate names someone who doesn't hold that row, one of the two is wrong.
Set the reopen triggers on the day you publish
A RACI published once and never revisited is accurate for about six weeks. Set the triggers at publication, because afterward nobody wants to reopen it.
Every row where they held an A or an R. Reassign and re-confirm, and don't let the row pass on by job title.
Rows held by anyone going part time, taking extended absence or picking up a second engagement.
Whether it brings activities the grid doesn't cover, and which existing rows it changes.
Design, test, cutover and hypercare need different grids. Ownership legitimately moves between them.
The activity didn't happen and the accountable party was surprised by it. It's the most valuable trigger and the least used.
Every row the rehearsal proved wrong. Rehearsals surface ownership gaps more reliably than any review.
Whether the deliverable set moved between the organizations.
Every accountable row gets confirmed in writing
One step gets skipped more than any other, and it's the one that makes the grid real. Each named accountable party confirms individually, in writing, that they hold the row. Their manager can't do it for them, and neither can the track lead.
A grid published without that confirmation is a proposal that looks like a decision, and you find out the difference at the moment you needed a decision. The failure scales, too. A 2026 federal audit of shared services adoption found key leadership roles vital to decision-making still unfilled, and two of its four recommendations were simply to fill the named accountable roles and appoint the governance chair [R11].
Two cutover leads sign. The sponsor signs the decision rows. The owner names get pushed into the plan, and the PMO holds the review triggers.
From then on the grid works as a control, and a disputed row gets settled by reading it.
Sources
- R1 UK Committee of Public Accounts, "Government shared services," HC 85, July 2026. publications.parliament.uk
- R2 UK National Audit Office, "Lessons learned: Governance and decision-making on mega-projects," HC 545, March 2025. nao.org.uk
- R3 Government Project Delivery, "The role of the senior responsible owner," updated September 2025. projectdelivery.gov.uk
- R4 HM Government, "Government Functional Standard GovS 002: Project delivery," v2.1, 2025. projectdelivery.gov.uk
- R5 National audit office performance audit of a public-sector pay system implementation, 2018. oag-bvg.gc.ca
- R6 Independent lessons-learned review of a national pay administration transformation. canada.ca
- R7 Statutory external auditor public interest report on a local government ERP implementation, February 2025. birmingham.gov.uk
- R8 National audit office performance audit of a defense ERP program, 2021. anao.gov.au
- R9 State legislative performance evaluation of a statewide ERP implementation, November 2024. legislature.idaho.gov
- R10 High Court judgment in a large insurance sector transformation dispute, 2021. caselaw.nationalarchives.gov.uk
- R11 US Government Accountability Office, "Federal Shared Services," GAO-26-108014, February 2026. gao.gov
Public cautionary cases are cited by source and left unnamed in the body so the article stays vendor and organization neutral. Field examples come from real Workday and ERP implementations, fully anonymized. General guidance, not legal advice.
Free field instrument
The cutover plan construction standard, on two pages.
The task schema, the line-level quality bar, the decomposition rules, the four dependency types and the baseline gate, plus the contested-row resolution test. Built to sit beside the plan and the grid.
Settle the ownership questions before the window.
If your cutover grid still has organization names in the accountable column, an independent pass through the contested rows costs less than one disputed change order.