Day one after the SI leaves
The war room went dark Friday at 5. Here's the first Monday hour by hour, from the access queue at 8:10 to the question someone asks at 4:40pm. Every moment of it was decided months earlier.
Every deployment has two endings. The one on the plan is go-live: the cutover weekend, the first payroll, the champagne email. The other one is the Friday when hypercare closes and the SI's badges stop working. Nobody puts that one on a slide or sends an email about it.
I've watched the Monday after that Friday enough times to walk it by the clock. The hours below are a composite, but every moment in them comes from a real program. If your deployment ended with a calendar date instead of an exit gate, most of them are already on your schedule.
The day, by the clock
Badge in. The war room is dark.
- Whiteboards wiped, chairs pushed in
- System up, payroll ran Friday, dashboards green
The whiteboards are wiped and the chairs are pushed in for the first time in fourteen months. For a year, this room was where problems went to die: you walked in with a broken business process and walked out with a named person and a date. As of this morning, problems have nowhere to go.
Nobody notices at 7:55. The system is up, payroll ran Friday, and the dashboards are green. The empty room stays invisible until the first thing breaks, which will take about 95 minutes.
Until FridayThe war room: walk in with a problem, walk out with a named person and a date
From MondayProblems have nowhere to go
The access requests start stacking.
- New manager can't see her team
- Cost center moved, approver chain broke
- Terminated contractor still has a live account
A new manager can't see her team. A cost center moved and the approver chain broke. A terminated contractor still has a live account, which is the one that should scare you. During hypercare these were fixed inside an hour because a consultant with security access sat in the room. Today the same requests go to a help desk that doesn't have a Workday queue yet, get triaged as "software issue," and wait.
Access is always the first thing to pile up, because access changes every single day. People are hired, moved, promoted and terminated whether or not anyone owns the security model. By Friday this will be the longest queue you have.
Until FridayA consultant with security access in the room fixes it inside an hour
From MondayA help desk with no Workday queue triages it as "software issue," and it waits
An integration fails. The alert goes to a folder.
- Benefits file to the carrier: 3 records errored
- Alert sent to the project team's shared mailbox
- Nobody is in the folder
The benefits file to the carrier errors out on three records. The integration did exactly what it was configured to do and fired an alert. The alert went to a shared mailbox set up for the project team, and that team no longer exists, so nobody is reading it.
This is the quietest failure mode in ERP and the most expensive per incident. An unwatched integration fails silently for days, and you find out from the far end: the carrier, the bank, the state agency. The fix costs nothing when you sign the contract: a clause saying every integration alerts a person rather than a mailbox. On the first Monday that clause is worth more than most of the testing budget.
Until FridayA shared mailbox created for the project team
From MondayThe same mailbox. The project team no longer exists, so nobody is in the folder
The tickets queue. Everyone is back at their day job.
- Tickets queued: three today, five tomorrow
- 40 hours a week of Workday work, inherited by nobody
The functional leads who carried the design are payroll managers, accountants and HR business partners. The plan always said they'd return to their day jobs after go-live, and their calendars agree. What the plan never said is who inherits the 40 hours a week of Workday work they were doing. The honest answer was nobody, and writing that down would have forced a hiring conversation the budget didn't want.
So the tickets queue, three today and five tomorrow. The backlog that eventually gets labeled "adoption problems" starts here, in week one, as work nobody owns.
Until FridayFunctional leads doing 40 hours a week of Workday work
From MondayThe leads are back at their day jobs, and nobody inherits the 40 hours
Report request 14. Nothing gets retired.
- Built fast, saved next to the other 400
- No owner, no naming standard, no retirement rule
A director asks for a report that doesn't exist. Someone builds it fast, saves it next to the other 400, and moves on. The catalog grew again, with no owner, no naming standard and no retirement rule. Run this pattern for two years and you get the report estate every rescue engagement finds: hundreds of near-duplicates, a handful that matter, and nobody who can say which is which.
The rule that prevents it is simple. Every report has an owner or it goes, and you retire more than you build.
Until FridayThe war room, with a named person and a date
From MondayBuilt fast and saved next to the other 400, with no owner
Someone asks the question: "who owns this now?"
- Security thinks the help desk does
- The help desk thinks HRIS does
- HRIS is one analyst who was hired for the old system
- Finance assumes HR has it, because the project sat under the CHRO
It happens in a hallway or on a Teams thread, and it's always phrased the same way.
That question defines the next two years, because a system nobody owns decays. Two feature releases a year ship whether you test them or not, access drifts, integrations rot, and the report catalog keeps growing. If you answer the question before Monday, you get to run the system as a product. Leave it to a rescue engagement and that engagement starts by reconstructing what happened.
From MondayEvery route that worked until Friday belonged to the project, and it closed with the project
Nothing failed on Monday
The software worked all day. Every one of those moments traces to a decision made months earlier, usually in a budget review and usually framed as discipline. The run team was a line item, and it got cut. Hypercare got a calendar date instead of an exit gate. The knowledge transfer plan became a SharePoint folder of recordings nobody will watch.
The industry data says the average program delivers 56% less value than the business case promised. In my experience that gap opens in the first year of running rather than at go-live. It opens slowly, too, so nobody notices for about nine months.
56%less value than the business case promised, on the average program
After go-live the system is a product. Whether it compounds or decays comes down to three things, and all of them cost money before Monday: a funded run team, one intake queue, and a named owner per area.
The run-ready check
Five conditions, all checkable before your hypercare end date. Tick what's true today.
If your Monday is already behind you
Most teams get to this after the fact. The recovery sequence is the same at month two or month nine, just slower. Name the owners first and stand up the single intake queue second. Then walk the integration alert routing in one afternoon, because that's where the silent damage is piling up. Fund the run team from the value the business case already promised. You're asking to stop losing money that's already been spent, which is a different conversation from asking for new money.
I run day-one readiness reviews in the last month of hypercare, and run-team rescues after the fact: owners, intake, release governance, and the report estate. The full first-year playbook is free in The Complete Workday Run Guide, and the hypercare exit conditions are in Hypercare that stabilizes the business.
Put independent eyes on your program.
If you're betting tens of millions on an ERP program, a candid second opinion is the cheapest insurance you'll buy.