Here's the answer up front: a go-live war room is not a place you go to when something breaks. It is a command center you build the night before launch. Three things: people, checklists, and a decision chain. Seven people in the room, 13 checklists on the wall, and anyone can get a decision in 15 minutes. Get those three right and you can contain whatever week one throws at you. Miss one, and you'll be woken at 2 a.m. by the client's phone call.

Why Week One Demands a War Room

A WMS go-live is different from other IT launches. You can roll back an ERP. You cannot roll back a WMS — the inventory is already moving under the new logic: locations, stock, waves, all running on the new rules. There is no going back to the old system. You can only fix forward. I've seen this exact pit three times: three times the client said "our team is trained, there will be no problems," and three times massive picking errors hit on day three and the floor turned into chaos.

The war room solves three real problems. First, information aggregation: an anomaly spotted by a floor operator must be seen by someone within 10 minutes, not in the end-of-day report. Second, fast decisions: when a wave rule is wrong, who has the authority to say "kill that wave, go manual"? That cannot wait for a project manager meeting. Third, it steadies nerves. Floor staff will panic in week one. A fixed place with fixed people sitting in it cuts the panic in half.

Who Sits in the Room: 7 Roles, No Substitutions

  1. Commander (usually the client's project manager or warehouse manager): the only person with final say. In the room all day.
  2. WMS consultant (implementation partner): knows the configuration, can change rules and waves on the spot.
  3. IT liaison (client side): owns troubleshooting for ERP, marketplace, and carrier interfaces.
  4. Operator representative: a veteran floor worker who can tell "system bug" from "we did it wrong."
  5. Hardware/device support: scanners, printers, Wi-Fi APs. His problem.
  6. Data clerk: watches inventory discrepancies full-time, runs daily cycle counts and reconciliation.
  7. Scribe: logs every issue, decision, and fix time. The week-one review lives or dies on this log.

Smaller warehouses can double up roles, but commander, consultant, and IT liaison must be dedicated. No sharing.

13 Checklists: Print Them, Pin Them, Check Them Daily

The go-live eve checklist (I make every client print this and pin it on the wall):

Environment

  1. Production locations, zones, printers, and scanners all tested in production — not the test environment, production.
  2. Wi-Fi coverage walked and tested across the entire warehouse: picking zones, docks, returns. Every zone. This pit I've seen three times — they tested in the office, and on go-live day the dock scanners couldn't connect.
  3. Interface connectivity: order download from ERP, inventory upload, carrier label APIs — each one run with real orders.

Data 4. Opening inventory imported and cycle-count confirmed, with a separate list of variance SKUs. 5. Item master data (barcodes, UOM conversions, lot/expiry attributes) frozen — nobody touches master data during go-live week. 6. User accounts, permissions, and roles all assigned, with at least one admin account per shift.

Process 7. SOPs for the six flows — receiving, putaway, picking, verification, shipping, returns — printed and posted on the floor. 8. Final wave strategy, replenishment rules, and slotting parameters screenshotted and archived. 9. Exception playbook: short picks, damaged goods, unscannable barcodes, stuck transactions — for each, step one is "call whom."

Contingency 10. Fallback plan: under what conditions do we degrade to manual/semi-manual operations, and who gives that order. 11. Key contact phone list: implementation partner, hardware vendor, network vendor, carrier interface support — pinned where everyone can see it. 12. Daily standups at fixed times (I suggest 8:00 a.m. and 8:00 p.m.), no exceptions. 13. Issue severity standards: P0 (line down) 15-minute response, P1 (local impact) 1 hour, P2 (experience issue) same day.

The Usual Wrecks: Three I've Seen, Same Script

Wreck one: the wave rule breaks on day one. An East China 3PL mixed different clients' goods into one wave on launch day. They had only tested the rule with one client's data; in production a dozen clients ran at once and the client-grouping condition was never configured. The war room decision: suspend auto-waving, build waves manually, consultant fixes the rule within two hours. Damage contained to one shift.

Wreck two: supplier barcodes don't match the system. A cosmetics warehouse — supplier cartons carried 14-digit barcodes, but the item master only had the 13-digit EAN. Receiving couldn't scan, and 40+ pallets piled up at the dock. This pit I've seen three times, always because nobody did a physical spot-check of master data. The right move: one week before go-live, randomly pick 50 SKUs and compare physical barcodes against the system.

Wreck three: nobody covers the night shift. The war room buzzed all day, everyone left at 10 p.m., and night-shift operators with a stuck transaction could only sit and wait. After that lesson, my rule is ironclad: week one, the war room covers every operating shift. At minimum the consultant and IT liaison stay for nights, phones on.

Engineers at work in a warehouse control room

The Counterintuitive Call: Week One's Goal Is Not "Zero Issues"

Many clients set the week-one target as "no problems." That's wrong. After 30+ projects I can say with certainty: week one will have problems. The only question is whether you contain them before they spread. So the war room's KPIs should not be "issue count" but three numbers: average response time for P0 issues, average time from discovery to closure, and the share of repeat issues. Get the first under 15 minutes, the second under 4 hours, the third under 10% — that's a successful week.

One more trade-off: should you cut throughput in week one? My answer: deliberately cut 20–30%. Don't listen when the sales team says "orders can't wait." Running at 70% capacity while the process beds in, then going full speed in week two, beats running at 100% in week one and reworking everything. I've run this math for three clients: one full rework costs two to three times the lost throughput.

When week one ends, do one thing before disbanding the war room: take the scribe's issue log and walk through it line by line. Mark each as configuration, training, or process-design. Fix the configuration ones on the spot, put training gaps into week two's refresher plan, and park process-design issues in the change backlog. That log is one of the true deliverables of your project.

By Lin Xiao, WMS Implementation Consultant