It’s Friday evening. The new ERP system is scheduled to go live on Monday. The warehouse team has tested receiving and shipping, but accounting still can’t explain why the receivables balances in the new system differ from the old ones. If you’re the CEO, do you launch company-wide, start with a narrower rollout, or postpone?
A good decision serves the goal, carries a downside you can live with, and makes sense given the evidence available at the time. Timing matters, too. A small change you can undo may be worth trying today. A change that reaches customers or is difficult to undo may be worth one more round of testing.
Agree on what you need to protect
In this example, Monday is the target date. The business needs the warehouse to keep shipping, customers to get accurate invoices, and accounting to be able to trace the balances back to their source. If people in the room give those goals different priorities, the same Monday can look like a sensible launch date to one team and an unnecessary risk to another.
I’d ask the team to distinguish conditions each part of the rollout must meet, such as reconciling migrated receivables and explaining every discrepancy before the ERP issues live invoices, from tradeoffs we can accept, such as a few extra days of coordinating across two systems so part of the warehouse operation can start sooner. Then compare the options the team can actually carry out, including staying on the old system for now and setting a date to reconsider. If several options clear the requirements, ask how much each one does for the goal, who takes on extra work, and whether you can live with the worst plausible outcome.
What happens if you’re wrong, and can you undo it in time?
Before launch, I’d ask where the discrepancies could show up, who would have to fix them, and whether customers might receive incorrect invoices before the team notices. Switching back to the old software may be quick. Invoices already sent and transactions recorded during the changeover still need to be dealt with. To call a plan reversible, the team needs to rehearse both switching back and getting all transactions created in the meantime into the old system without duplicates.
Jeff Bezos calls reversible decisions “two-way doors” and argues that they can use a lighter decision process. I’d apply that idea to each consequence of the ERP change. Trying out receiving at one warehouse and issuing live invoices across the company may use the same software, but they affect different people and leave very different amounts of work if you have to reverse course. Amazon’s 2016 Letter to Shareholders
Which information is worth waiting for?
If there’s time for just one more check, I’d first ask what result would change the decision. Here, reconciling receivables by customer and document helps answer whether accounting is ready to issue invoices from the new system. Another progress report may leave that question open. Before deciding to wait, agree on when the answer will arrive and what the delay will cost, such as rescheduling the launch team or asking staff to coordinate across two systems for longer.
In a readiness update, I’d like to hear something like this. “We’re confident the warehouse can receive and ship goods in the cases we rehearsed. We don’t yet know whether transactions pending during the switch will be sent twice.” The scope of the rehearsal and the open question tell the CEO how far that confidence extends. If the next result will arrive after staff need to be notified, decide in advance what you’ll do if the evidence hasn’t arrived.
What evidence points to each option?
| Option | Evidence that supports it | What you have to accept |
|---|---|---|
| Launch company-wide | Receivables reconcile, tests pass from order entry through invoicing, and the team has rehearsed resuming work on the old system. | A problem the rehearsal missed could affect several departments at once. |
| Pilot at one warehouse | The pilot is isolated from live invoicing, the old system remains the source of record for accounting, and the team has rehearsed stopping the pilot and bringing transactions back without duplication. | Warehouse and accounting staff need extra coordination and must know which system is authoritative for each type of transaction. |
| Postpone and set a review date | Neither rollout meets its requirements by the deadline. For example, accounting still can’t explain all the receivables discrepancies, and the warehouse team hasn’t passed its rollback rehearsal for the pilot. | Keep the old system running, reschedule the team, and specify which checks must be completed before the next review. |
On the evidence available Friday evening, I’d hold off on approving a company-wide launch. If the team can verify that the warehouse work is isolated from live invoicing and pass the rollback rehearsal by noon Sunday, when staff need to be notified, I’d start at one warehouse. Otherwise, I’d postpone. A company-wide launch comes back into consideration once the receivables discrepancies are resolved and the tests and rollback rehearsal in the table have passed.
In this hypothetical company, the head of accounting signs off on the receivables reconciliation, the warehouse lead confirms the work can be done within the pilot’s scope, and the systems lead confirms the rollback rehearsal results. The CEO makes the call based on their evidence and owns the tradeoffs. If the pilot goes ahead, the cutover lead can stop it immediately if transactions are sent twice or the ERP issues a live invoice. Giving the person on the ground authority to stop makes the rollback plan usable when it matters.
Record the reasoning before you know the result
Before the meeting ends, write down five things so someone joining later can follow the decision.
- Decision and deadline. What outcome are we trying to protect, and when do we need to make the call?
- Options and requirements. Which options meet the minimum conditions, and what does each one cost us?
- Evidence and gaps. What do we know, how confident are we, and what could change the answer?
- Choice and owner. Who decided, what did they choose, why, and what downside did they accept?
- Stop conditions and review date. Who can stop the work, what would trigger a stop, and when will we look at the results?
Suppose the team skips reconciliation and gets through the first day without a customer complaint. The quiet tells you no customers have reported a problem yet. If a pilot meets every launch condition and still has to stop because a transaction goes through twice, open the record. When did the team see it? Were they able to stop as planned? What should they add to the next rehearsal?
In experiments with undergraduates, Jonathan Baron and John C. Hershey found that participants gave higher ratings to the decision maker’s reasoning when the outcome was favorable, even though participants understood they had all the relevant information available to the decision maker at the time. The researchers called this outcome bias. That’s why I’d save the reasoning before the result comes in, then use what actually happened to see which assumptions or contingency plans need work. Baron and Hershey, Outcome Bias in Decision Evaluation (1988)