Most software rollouts fail for the same reason. The tool works. The people do not adopt it. A PMO at a global telecom with more than 105,000 staff across 21 countries ran into the same wall and built a fix.
According to a Planview case study, the PMO Delivery Lead turned a resistance problem into a working rollout using three practices: showing value, recruiting champions, and rewarding early wins. None of it was exotic. All of it was disciplined.
What happened:
- The PMO handles around 134 monthly demands and up to 250 active projects.
- The previous setup was spreadsheets, notes, and emails.
- They used role-based training plus short videos to show value.
- Champions in each business area carried the message two ways.
Why this is a delivery story, not a software story
The tool here is demand management software. The real product is adoption. The PMO recognised that before they wrote a single config file. They answered the only question that mattered: why should anyone in this organisation change what they did yesterday.
For delivery leads running their own rollouts, this is the part to copy. Pick the tool last. Pick the adoption story first.
Our analysis
The three practices line up neatly with what usually goes right and wrong in this niche. Showing value answers the "what is in it for me" question that every adopter silently asks. Champions turn a top-down mandate into a peer network. Incentives close the loop so early effort is visible.
Who benefits: portfolio leads who want one source of truth for demand. Who loses: the spreadsheet loyalists, until they see the reporting meetings shrink.
Compared with the usual situation in this space, most rollouts focus on configuration and training, then wonder why adoption stalls. The Planview playbook treats adoption as the primary deliverable and config as the easy part. That inversion is the lesson. And the stakes are high: a separate data point cited in the same case study notes that roughly three-quarters of organisational change efforts collapse, often because buy-in was never earned.
A worked example
Say you are rolling out a new intake tool across five squads. Run a short session per role, not one generic webinar. PMs see how it removes status meetings. Engineers see how it cuts the duplicate-ticket problem. Finance sees how it cleans up the monthly forecast. Then ask each squad to nominate a champion with protected time on their calendar. The PMO runs a recurring short champion call to handle questions and pass updates back to the PMO. Adoption stops being a decree and starts being a service.
The PMO's own n
Key takeaways
- Show value in each role's language, not in the tool's language.
- Recruit champions with protected time, not good intentions.
- Treat adoption as a deliverable with its own acceptance criteria.
Frequently asked questions
How do you measure adoption after rollout?
Track weekly active users per role, plus the share of demands that enter the system through the new tool rather than email.
What is the fastest way to lose a rollout?
Skip the value story and assume config will carry it.
How many champions do you need?
At least one per distinct user group, with protected time to act as the two-way bridge between the PMO and their team.
What is the typical failure mode for tool rollouts?
Reaching partial adoption, then stalling because leadership attention moves to the next initiative.