Case study
Sign-off Isn't Adoption
Four functions, four attainment reports, and none of them agreed. I consolidated them, got sign-off, reported the program done, and found out later that 70% of people had never moved.
- Legacy suite retired; the competing-report ambiguity ended
- Up to 840 resource hours a year given back
- 70% still on legacy at the point I reported the program done
- Diagnosed as two causes, roughly 30% trust and 40% habit
Context
Attainment reporting at AWS was fragmented across Sales, Sales Operations, Revenue Operations, and Finance. Each had built its own view over the years, and the views didn't agree, so leaders opened reviews by arguing about which number was right instead of what to do about it. I was asked to consolidate the estate onto QuickSight.
I owned none of those teams. And the ask to each of them wasn't really “help me build something.” It was “give up the report you built and trust mine instead.” That is a different conversation, and pretending otherwise would have cost me the first month.
Two problems, and I only saw one
The visible problem was authority. Four functions, four incumbent reports, no reporting line from me to any of them, and a migration that only works if every one of them moves.
The problem I didn't see was my own definition of done. I had decided, without ever writing it down, that the program finished when each function's leadership signed off on retiring their legacy suite. That is a perfectly reasonable milestone. It is not the same thing as anyone changing what they open on Monday morning, and the gap between those two is where this project actually lived.
How to get four teams to give up their own reports
Get it mandated from above
PassedAvailable to me, and it would have produced compliance on a date. Compliance is not usage. A team told to stop using its report will stop saying it uses its report, which is a reporting problem I would then own too.
Build something better and let quality do the work
PassedAssumes people migrate on merit. They don't, or not on any schedule you can plan around. A better report competing against a habit and a set of bookmarks loses more often than it wins.
Run a gap analysis across the whole estate
ChosenWhat exists, who actually uses it, and where the definitions diverge. That made the duplication visible and quantified, so I wasn't arguing with anyone. I was showing each function its own numbers and letting the overlap make the argument.
Why showing them their own data won
An argument you win by persuasion has to be re-won every time someone new joins the meeting. An argument settled by a team looking at its own usage data doesn't, because the evidence sits on their side of the table.
It also changed what I was asking for. Not “trust my report over yours,” but “here is where your report and three others compute the same thing differently, and here is what that costs in review time.” Nobody defends redundancy once they can see its shape.
What I ran
I scoped the migration as epics per team, each rebuilt report carrying acceptance criteria it was validated against before anything was retired. Standardizing definitions and dropping redundant metrics happened on the way through rather than as a follow-up nobody would fund. Engineering, the data platform team, and Business Operations went onto one schedule, and each function's leadership signed off on deprecating its legacy suite.
I also built a four-week soft-launch buffer into the plan, a period where the old pipelines and dashboards stayed live and only the landing page changed. I want to be accurate about this: I built it as generic schedule risk, not because I had predicted what went wrong. It turned out to be the thing that saved the program, but that was preparation paying off rather than foresight.
The month I found out I was wrong
I was reporting status as “teams have signed off,” and by that measure we were finished. Then, during a demo of the new reports, I dropped a quick Slack poll asking who was on the new suite versus the old. The yes responses were thin. Thin enough that it contradicted what I thought I knew, so I stopped and pulled the actual usage data. Seventy percent of usage was still on the legacy dashboards.
That 70% was not one problem, which is the part I nearly got wrong. About 30% were running both systems side by side, checking the new output against numbers they already believed. That is a trust gap, and honestly it is diligence rather than resistance. The other 40% simply hadn't moved: habit, saved views, a weekly routine built around specific screens. Two causes, two different fixes, and I had been one meeting away from applying a single blunt instrument to both.
So I spent the buffer, which is what it was for, and pushed overall delivery by two more weeks as margin. Cutting people off on the original date would have cost exactly the credibility the whole program ran on. For the trust group, I sent analysts their own geo- and region-filtered views so they could reconcile against numbers they already trusted, then ran one validation walkthrough where everyone could ask questions in front of each other. Most of the confusion cleared in that single session. For the habit group I made the switch graduated instead of a cliff: both reports on the landing page, then the old one out of view but bookmarks still working, then gone. And I went to the regional teams directly on Slack rather than waiting for them to come to me.
The last part was telling leadership that the status I had been reporting was wrong, that I had assumed everyone was moving and had not verified it, and that I would work through it geo team by geo team. That conversation was worse to anticipate than to have.
Results
The 840 hours is the number this project is usually described by, and it is the weaker half of the story. The part worth reading is that the program shipped, was signed off, stalled at 70% legacy usage, and got across only because there was slack in the schedule and time to diagnose two causes separately.