Three weeks before cutover, in the readiness review, the sponsor asks you a question you were not expecting: “So what actually runs differently on day one?”
You have an answer for everything else. Training is at 84% and the last sessions are booked. The comms have gone out on schedule. The cutover plan runs to 24 pages and has been rehearsed twice. The data is loading at the rate the plan said it would.
What you do not have is a written answer to their question. You start listing things: the new approval limits, the reports that will come out of the system, the shared service picking up supplier invoices. They wait. Then they ask whether any of that is written down anywhere with a name against it, and the honest answer is no. It lives in the process designs, in the training decks and in the heads of about 40 people, and nobody has put it on one page.
That silence is yours. Eight months from now, when the old spreadsheets are still running in two plants and the CFO asks where the benefit went, the sponsor will remember who could not answer this question while there was still time to do something about it.
This issue is that page. It is called the day-one register, it fits on one side of A4/letter, and by Monday you can have the first three lines written. The reason your programme does not already have one comes from the way programme plans are built, which is also why nobody notices it is missing.
Why the page does not exist
Look at what your programme actually tracks. The plan tracks the build: environments, configuration, interfaces, data loads, test cycles, each with a date and a person who gets called when it slips. The change plan, if there is one, tracks activities: how many people have been trained, how many comms have gone out, how many champions have been named, how many process designs have been signed off.
An activity and an operating change are different things, and the plan only tracks the first. Training three thousand people is an activity. “From day one, purchase orders above £25k are approved in the system by the category manager, and the email approval stops” is an operating change. You can train every single person and still change nothing on Monday.
My view, and I hold it firmly: that is what usually happens. People go to the training, pass the quiz, and on Monday morning they do what they did on Friday, because nobody told them, in writing, with a date, what stops.
"You can train every single person and still change nothing on Monday."
The plan does not carry the second list because the second list has no owner. The build owner owns the build. Nobody owns what the business does differently, so nobody writes it down. Last week’s issue was about that missing person, the one senior owner who holds the change the way the build owner holds the build: A committee is not an owner.
This week is about the page that person holds, because an owner with nothing written down has a title and nothing anyone can hold them to.
What a line looks like
A day-one register line has five parts. All five have to be there, or the line is a wish.
The process. A decision, a process or a control, by name. Not “procurement” but “approval of purchase orders above £25k”. Not “month-end” but “the intercompany reconciliation”. If it takes a paragraph to name, it is two lines.
Who runs it differently. One name from the business: the category manager, the plant controller, the team lead in the shared service centre. The programme never owns a line, because the programme does not run anything after go-live.
From when. Day one for most lines. Some start later because the calendar says so: a month-end line starts at the first month-end, and that is fine, as long as the date is written down and the owner has agreed it.
What stops. This is the part nobody writes, because writing it means naming the spreadsheet, the email chain or the local workaround people are attached to, and the person who has to switch it off. Write it anyway. If nothing stops on day one, nothing has changed. The new system has been added to the old way of working, and the business is now running both.
“If nothing stops on day one, nothing has changed. The new system has been added to the old way of working, and the business is now running both.”
The week-one evidence. What would you look at on the Thursday of the first week to know this line is running? Approvals in the system with no email trail. No new rows in the old tracker. A report that came out of the system rather than being rebuilt in a spreadsheet. If you cannot name the evidence, you cannot tell running from not running, and the line will be reported green by default.
Two lines filled in, so you can see the shape:
Process: purchase order approval above £25k.
Who runs it differently: the category manager, one name.
From when: day one.
What stops: approval by email, and the finance inbox that queues them.
Week-one evidence: every PO above £25k carries a system approval and no email; the inbox queue is empty.Process: the intercompany reconciliation.
Who runs it differently: the group controller, one name.
From when: the first month-end after go-live.
What stops: the reconciliation spreadsheet and the two-day manual match.
Week-one evidence: none until month-end, so the line reports “not yet due” and the sponsor knows why.
The register is one page. Twelve to twenty lines on a large programme is my honest range. If you have sixty, you have rewritten the process catalogue, and nobody senior will read it. Choose the lines where money, control or a customer changes hands. The rest already lives in the process documentation, which is where it belongs.
Who holds the page
The page has one holder, and every line has one name.
The holder is the adoption owner: the senior person from last week’s issue, a peer of the build owner, with the change budget and the authority to say the business is not ready. They write the register with the business before the gate, they put it on the table at the gate, and they report against it after go-live. It is the first concrete thing that role owns, and my view is that it is what makes the role real to everyone else: a person with a page they are answerable for.
The name on each line is the operating owner: the person who runs that process differently from Monday. Filling that column is where committee ownership fails all over again, because "the business" is a department, and a department cannot run a process differently on Monday morning. A named person can. A named controller can. If a line comes back with a department in the owner column, that line is not ready, however green the training numbers are. I still catch myself typing “ business” into an owner column when I am in a hurry (it is easier, and it commits nobody, which is exactly why it is easier).
"A department cannot run a process differently on Monday morning. A named person can."
If your benefits register has names in its owner column, the two pages should agree with each other. Every day-one line is the thing that makes one benefit line real. Where a benefit has no day-one line behind it, ask what is actually going to change so the money arrives. Quite often the answer is nothing yet, and it is better to hear that in the readiness review than in the year-one benefits review.
What the page is for
Three uses, in this order.
At the readiness gate, the question changes. Most gates ask whether training is complete, whether the comms have gone out and whether the business has signed the readiness statement. Those are activity questions, and all three can be yes while nothing is ready to run; a readiness pack built from them is the failure I wrote about in July, in Technically correct, strategically useless. With the register on the table, the gate asks one question, line by line: “Is this ready to run on Monday?” The operating owner answers for their own line, and the answer is yes, no, or not until a date. A no on a line where money changes hands is a go-live conversation. A no on a reporting line is a workaround with a date against it. Telling those two apart in one meeting is the whole reason the register fits on a page.
For the first 30 days after go-live, the register is the adoption owner’s report to the sponsor. The adoption report is one page, and every line on it says one of three things: running, not running, reverted. It replaces the adoption dashboard, which counts logins and cannot tell you whether the category manager has stopped approving by email. The weekly readout takes ten minutes, because there are fifteen lines and every one of them has a name.
"The adoption report is one page, and every line on it says one of three things: running, not running, reverted."
A line that is not running escalates the same day, with a name attached, on the same route a technical defect would take. The old spreadsheet comes back in a plant on Tuesday; the plant controller owns that line; the adoption owner is on the phone to them on Tuesday, and the sponsor hears about it on Wednesday if it is still running the old way. Compare that with what usually happens: reversion turns up as an anecdote in hypercare, then as a footnote in the month-two review, and by then it is how things are done. A steering committee that hears about it a month later has already failed, in the way I described in SteerCo fail 48 hours earlier.
Where this still fails, and what to do then
You are already past cutover and there is no register. Write it now, from what was supposed to change. Take the process designs and the business case, list the lines, and put a name against each one. Writing the register after go-live starts an argument over about half the lines, from people who will tell you that change was never agreed, or was agreed with someone who has since left, or is "in progress". That argument is the conversation the programme should have had before the gate, and having it in month two costs a great deal less than having it in month eight, when the CFO asks where the benefit went.
"Writing the register after go-live starts an argument over about half the lines. That argument is the conversation the programme should have had before the gate."
The line nobody will own. Sometimes a change that is in the business case has no operating owner, because the person who would run it differently was never asked, or said no quietly. Do not leave it on the page with a department name against it. Take it to the sponsor as a decision: name an owner this week, or take the benefit that depends on it out of the case. Either answer is honest. Leaving a department name on the page is not.
The programme where nothing runs differently, by design. Some migrations were decided as like-for-like: same processes, new system, change deferred to a later phase. If that decision was made openly, you do not need this register. Write the three lines that do change, put them in the readiness pack, and leave the rest alone. If the decision was never made openly, and the business case still promises savings, then the empty register is the most useful page you will produce this month, because it shows the sponsor in one look that the case is buying a postponement. That conversation is uncomfortable now and expensive later.
And the workstreams that change nobody’s day, a technical upgrade, an infrastructure move, do not need a line at all. Leave them out.
This is an afternoon’s work and two hard conversations. You do not need a tool, a workshop or a template pack. You need the process designs, the business case, an hour with the adoption owner, and the nerve to fill in the “what stops” column truthfully.
Tonight, write three lines for your own programme: the process by name, the person who runs it differently, and what stops. If you can write three without asking anyone, write the rest tomorrow with the adoption owner. If you cannot write three, that is your programme status, and it tells you more than the training percentage does.
Reply and tell me which line you could not write, and who you think should own it; the next issues get built from what comes back.
Roman