A global integration where delivery depended on changing the system around the work.
Outcomes
- Recovered a 3-week BAT schedule slip by changing the execution model and tightening daily governance
- Finished BAT on time and protected the Wave 8 go-live date
- Maintained true business acceptance by keeping the business in the approval role (observe + sign off)
- Part of Gillette’s 8-wave SAP APO DRP program that enabled approximately $3B in sales
- Helped enable Gillette data center closure contributing to approximately $1M/year run-rate savings
The problem
By the time Wave 8 entered BAT, the business side was not bought into the implementation.
They delayed participation in configuration and resisted the work needed to build scenarios, learn the system, and execute test steps confidently.
For the first few weeks, my IT team and I monitored progress and supported where we could.
But the trend line was obvious:
BAT was slipping, and the business wasn’t going to catch up in time.
What I did
I recommended a change that was simple in concept—and critical in execution:
Flip the BAT roles so the work could move without breaking acceptance.
1) Flipped execution: IT runs scenarios, business approves.
Instead of “business executes, IT supports,” we shifted to an operating model where IT executed the BAT scenarios (hands on keyboard) while the business rode along—observing runs, reviewing results, and signing off outcomes.
This removed the execution bottleneck while keeping acceptance real.
2) Reinforced training in parallel (without becoming the critical path).
We didn’t ignore readiness—we rebuilt it while delivery continued. Training and reinforcement ran alongside execution so the business could build fluency without slowing the schedule.
3) Ran a daily war room with live scenario tracking.
We met daily in a war room with a clear cadence:
- Confirm the scenarios for the day
- Execute end-to-end
- Capture outcomes and approvals in real time
- Surface blockers immediately
- Decide the next step while everyone was in the room
That cadence is what turned “late testing” from a slow reporting loop into a decision system.
Why this mattered
This wasn’t a story about pushing people harder.
It was a story about removing the bottleneck without compromising the integrity of acceptance.
When a team is behind late in testing, the instinct is to demand more effort.
But effort doesn’t fix a broken operating model.
In this case, the only way to protect go-live was to change the execution system:
- IT executed to keep the work moving
- The business approved to keep acceptance intact
- Training ran in parallel to rebuild readiness
- Daily governance compressed decisions and prevented drift
Testing isn’t a phase. It’s a decision system.
When late testing slips, don’t wait for motivation to save you. Change the operating model so progress becomes possible.
The playbook that worked here:
- Remove the bottleneck (role-flip execution)
- Keep acceptance real (business observes + signs off)
- Increase decision speed (daily war room)
- Reduce ambiguity (live scenario tracker)
- Build readiness without stalling delivery (train in parallel)
If you’re heading into late-stage testing on a major transformation, my advice is simple:
Don’t ask people to “try harder” inside a system that isn’t working.
Fix the system. Then the work can move.
0 Comments