By Paul Oppong, PPM Consultant at Sensei
AT A GLANCE
- Most PPM frameworks don’t fail because the methodology is wrong. The real challenge arises when frameworks are created without a deep understanding of how projects actually run day-to-day.
- Even after thorough discovery, workshops, interviews, and requirements sessions, a framework can look solid on paper but still be set aside, especially when project managers are under real pressure.
- Adding more documentation isn’t the answer. What really makes a difference is connecting with end users early, before any configuration starts.
“We’re updating our PPM framework” typically signals a specific issue
When an organisation says it’s updating its PPM framework, it’s often a sign that the current approach isn’t working as well as it could. In my experience, this usually happens because the framework was designed by people who don’t manage projects every day, so some practical challenges get overlooked.
Why thorough discovery still misses the mark
I remember one engagement where we ran discovery workshops with sixteen people in the room. Only four were project managers or regular users of the tool. The rest were senior stakeholders, program leads, and governance representatives- great people, but most hadn’t submitted a status report or updated a RAID log in years. The framework we designed together looked thorough on paper, but as soon as it went live, the feedback from project managers was clear: it didn’t reflect how they actually worked. The launch was tough from day one, not because the methodology was wrong, but because the people shaping it weren’t the ones using it every day.
Build for how projects actually run, not how they’re supposed to run
There’s a big difference between designing for the ideal project and designing for what really happens on the ground. In theory, RAID logs get updated every week, but in reality, updates often happen just before key meetings, usually when people are under pressure. If a framework doesn’t fit these real-world habits, it’s likely to be ignored.
Often, when I review an updated framework, I’ll find a SharePoint folder containing a methodology document that hasn’t been opened in months and templates that look right but haven’t been tested in real projects. The framework is there, but it’s not connected to the way people actually work.
It’s not the methodology, it’s the distance
After nearly two decades working with project frameworks, I’ve found that it’s rarely the methodology itself that causes problems. Things like stage gates, RAID logs and benefits tracking are important, but they’re not usually the stumbling blocks. The real issue is the gap between the people designing the framework and those using it in real life. When we close that gap, frameworks have a much better chance of succeeding. If we don’t, the same problems tend to come up again and again.
What I do differently: embed before you configure
This step is simple to describe but often gets missed in project planning, mostly because it’s not given enough time. Before I start configuring any framework, I make sure to spend time with the people who will actually use it. That means:
- Observing project managers as they report status, rather than depending solely on their descriptions of the process.
- Identifying which fields are skipped and inquiring about the reasons, rather than assuming the field itself is problematic.
- Discovering existing workarounds, such as supplementary spreadsheets, and understanding why these solutions are still necessary.
One of the first things I look at in any framework is how status gets reported, because that’s where users interact with the system most often. For example, when we worked with a Victorian government health agency, we started by collecting real status reports that project managers had created themselves, outside the official system, because those were the ones that actually worked for them. We also spoke directly with steering committee members to find out what information they needed to make decisions. From there, we designed a format that brought together most of those components. There were a few compromises, but the result matched how people really captured and used project information, not just what someone thought should happen in a workshop.
Most project plans don’t set aside time for direct engagement with end users, but including this step is key. It often makes the difference between a framework that gets used and one that sits on the shelf.
Next steps: turning visibility into better decisions
If your PPM framework isn’t getting the engagement you expected, the solution may not be another methodology review, additional templates, or more governance. Instead, it could be worth taking a step back and looking at how project teams are actually working day to day.
Spend time with the people who use the framework most often. Observe how project information is captured, where workarounds have emerged, and what reporting stakeholders genuinely rely on to make decisions. These insights often uncover practical challenges that workshops and requirements document alone can miss.
When frameworks are built around real behaviours rather than ideal processes, adoption becomes significantly easier. The result is a framework that supports project delivery instead of creating additional administration.
Looking to improve your PMO or PPM framework? Get in touch with us today to discuss how Sensei can help your organisations design practical, user-focused frameworks that align governance requirements with the realities of project delivery.
Q&A
Q. Why do “good” PPM frameworks often fail to stick?
Many frameworks are designed without enough connection to the realities of daily project work. Even the best discovery process can’t prevent problems if the framework doesn’t address the real pressures people face. The main issue isn’t the methodology; it’s the gap between those who design the framework and those who use it when things get tough.
Q. What are common signs our current PPM framework isn’t really functioning?
Some common signs are a SharePoint folder with a methodology document that hardly anyone opens, templates that look fine but haven’t been tested when things get busy, and ongoing conversations about ‘updating the framework’, which usually means it was never really adopted in the first place.
Q. If methodology isn’t the problem, what needs to change?
The most important factor is the relationship between the people designing the framework and the people using it. When designers and configurators work closely with those managing real projects, the framework is much more likely to reflect how things actually get done, rather than just assumptions.
Q. What should implementers do before configuring a new PPM framework?
Make time to work with end users before you start configuring anything. Watch how project managers report status, look for any workarounds they use, and find out why those are needed. Build your design around what you see in practice, not just what comes out of workshops.
Q. How does being closer to project delivery improve project management framework design and adoption?
As you get closer to project delivery, you can spot where a framework might struggle before it becomes a problem. You’ll notice which fields might get skipped or where people might take shortcuts when they’re busy. Designing for these real situations, rather than just the ideal process, makes it much more likely that your framework will actually be used.
About the author
Paul Oppong is a PPM Consultant at Sensei with more than 17 years’ experience helping organisations navigate complex delivery environments. He works alongside public sector leaders, executives and delivery teams to strengthen governance, support better decision-making and align delivery with strategy. In this article, Paul explains why even well-designed PPM frameworks can struggle to gain traction and outlines his approach to making them work in practice.
