GBMC Autumn 2026 Newsletter

Company X wanted to adopt a common PPP management methodology across all its Business Units (BUs) — IT/IS, Infrastructure, Marketing and Sales, Maintenance, and Logistical Services. To lead the initiative, the company hired a PMO Head from outside the organization. We’ll call him Charles.

Charles had led a similar initiative successfully at his previous company and was eager to repeat that success — and to make his mark. Company X, in turn, assumed his prior success would translate naturally to their environment (a classic case of the halo effect).

The Enterprise PMO tasked with introducing the new methodology was placed under the IT/IS Business Unit, which had deep experience managing integration and digitalization projects — but far less experience managing organization-wide change.

Charles assembled a team and set to work on principles, processes, tools, and templates. One team member, Bob, was responsible for Business Change Management: adapting current processes, engaging stakeholders, planning training, identifying a pilot group, and setting up help-desk support — the standard components of any rollout plan. Bob drafted an early newsletter announcing the PPP approach and its milestones. Almost in passing, it also mentioned that Capex and Opex budgeting would shift to a new model, with the CEO and the PMO having final say on allocations to each BU — a significant departure from a past where BUs had operated almost as independent fiefdoms over their own budgets.

Six months in, Charles reported progress to IT/IS senior management, who received it enthusiastically and encouraged him to continue. Charles read this as a signal that the whole company — not just IT/IS — was behind the project. Needing more resources, he pulled Tony off Change and Business Implementation work to support the core PPP team instead.

Twelve months in, Charles presented the results to the Board and the CEO. The deck was polished — clear figures, workflow diagrams, expected benefits. Fifteen minutes in, William, the Director of Logistical Services, interrupted:

William: “Charles, who from our BU participated in this project?”

Charles: “Bruno helped develop the Project Charter.”

William: “And… that’s it?”

Charles: “Yes — he was tied up with vehicle acquisitions and couldn’t make the other progress meetings.”

William: “I’m sorry, Charles, but this doesn’t work for us.”

Murmurs spread through the room. A Director from Marketing and Sales pressed for clarity on the budget-allocation rumors he’d heard. Voices rose. The CEO stepped in, halted the presentation, and asked to meet with the Director of IT/IS privately.

1. Agreement before execution. A solid business case isn’t enough. Before building anything, confirm that every affected Business Unit actually agrees to the change — not just the unit sponsoring it.

2. A weak case for change. The business case should explicitly address the cost of not changing, state benefits with real metrics, and be backed by a Benefits Management Plan — not just describe the new methodology.

3. The wrong owner for sensitive decisions. Budget allocation is a governance issue, not a PMO issue. It needed a senior sponsor — ideally the CEO or a steering committee — driving it, not a newly hired Enterprise PMO head.

4. Outputs were prioritized over outcomes. Business implementation typically requires more effort than building the methodology itself. Pulling Bob off change management and stakeholder communication to accelerate “deliverables” was a critical error — it traded long-term adoption for short-term output. This is a common trap: project teams get absorbed in producing artifacts and lose sight of outcomes, user experience, and change management.

5. Communication was treated as a checkbox, not a lever. Throughout the project, engagement with the other BUs was an afterthought rather than a core workstream. Good, specialist-led communication doesn’t just inform stakeholders — it builds the support a project needs to survive contact with reality. PMI’s research on project communication backs this up: poor communication is consistently linked to project failure.

6. Unvalidated assumptions. Charles assumed IT/IS’s enthusiasm meant corporate-wide support. It didn’t. Treat every cross-functional assumption as unverified until you’ve tested it directly with the people it affects.

7. Past success doesn’t transfer automatically. A PPP rollout that worked in one organization can fail in another with a different culture and a different appetite for change. Prior success is a starting point, not a guarantee.

8. Lessons learned were never sought. No prior rollout experience — internal or external — was consulted before the project began. Even a structured look at other organizations’ PPP rollouts, or a quick consultation with research tools available today, could have surfaced these risks early.

9. Bring in outside expertise early. Engaging people who’ve run similar initiatives before — even briefly, at the design stage — is inexpensive insurance against exactly this kind of failure.

None of these failures were about the methodology itself. Charles’s PPP framework may well have been sound. What failed was the change process around it: no shared ownership, no validated support, and communication treated as an afterthought instead of the main event. Methodology rollouts don’t fail on the whiteboard — they fail in the room where the people who weren’t consulted finally get to speak.

This newsletter was refined using Calude (AI)

George Merguerian, BSc Eng, MBA, PMP®, PRINCE2 Programme Manager, PfMP®, OPM3® Advanced, SA/CM™ (Certified Agile Master)

Senior Partner, Global Business Management Consultants

www.globalbusinessmanagementconsultants.com | [email protected]
www.bmc-global.com