The Landscape: What Came Before Us
Whatever is in this book is what survived. The rest did not make the cut.
Why Frameworks Matter
Delivering change in a complex, global organisation is a moving target. What’s “best practice” today may feel outdated in a few years. Tools, methods, and leadership approaches evolve constantly.
That’s why any serious approach to delivery management needs a reference framework — not a static checklist, but a compass that shows where you are and where you want to go. A framework provides:
- Clarity: A structured way to discuss strengths and gaps without the conversation dissolving into opinions and politics.
- Direction: A target state based on proven practices, not theoretical ideals.
- Adaptability: The ability to update and evolve as the organisation matures and the world changes.
Before we built ours, we studied what was already out there. Not to copy it, but to understand what works, what doesn’t, and what’s missing.
The Established Models
P3M3® — Portfolio, Programme, and Project Management Maturity Model
The most comprehensive of the traditional models, developed by Axelos. P3M3 assesses organisational maturity across three layers (portfolio, programme, project) and seven perspectives: Governance, Management Control, Benefits Management, Risk Management, Stakeholder Management, Finance Management, and Resource Management. Each perspective is scored across five maturity levels, from Awareness to Optimised.
What we learned from it: The seven-perspective structure is sound. It provides genuine coverage of the fundamentals. We adopted it as our core dimensional framework.
What we left behind: P3M3 can feel heavy — long interviews, complex scoring, detailed reports. More importantly, it stops at assessment. It tells you your maturity score but doesn’t hand you the tools to improve. It’s easy to turn into a paperwork exercise rather than a transformation tool.
OPM3® — Organisational Project Management Maturity Model
PMI’s model focuses on aligning projects and programmes with organisational strategy. It covers standards, measurement, control, and continuous improvement.
What we learned from it: The emphasis on strategic alignment is valuable. The connection between organisational strategy and project execution is a thread we wove throughout HoLiDySt.
What we left behind: Less detail on benefits management and cross-enterprise governance. It also feels dated compared to more modern, agile-influenced approaches.
MSP — Managing Successful Programmes
Axelos’ programme management methodology. Strong on governance, benefits management, and the relationship between programmes and organisational strategy.
What we learned from it: The benefits management approach — particularly the concept of a benefits dependency network — heavily influenced our programme playbook. MSP’s governance model informed our multi-layered governance structure.
What we left behind: MSP is comprehensive but can be bureaucratically heavy. It also predates the agile revolution and doesn’t naturally accommodate hybrid delivery.
PRINCE2 — Projects IN Controlled Environments
The most widely used project management methodology globally. Product-based planning, defined roles, stage gates, and exception management.
What we learned from it: Stage-gate governance, clear roles and responsibilities, and the principle of “manage by exception” are all embedded in HoLiDySt’s project playbook.
What we left behind: PRINCE2 is a project methodology, not a programme or portfolio framework. It also assumes a waterfall delivery model, which limits its applicability in agile and hybrid contexts.
SAFe — Scaled Agile Framework
The dominant framework for scaling agile practices across large enterprises. SAFe provides structures for team, programme, large solution, and portfolio-level agile delivery.
What we learned from it: SAFe demonstrated that agile principles can work at enterprise scale — but they need a governance wrapper to do so. The concept of agile release trains, lean budgeting, and portfolio kanban all influenced our thinking.
What we left behind: SAFe can become its own bureaucracy — a paradox for an agile framework. It also focuses primarily on technology delivery and doesn’t fully address the change management, stakeholder engagement, and benefits realisation challenges of multinational transformation.
Our position: HoLiDySt provides the governance and strategic layer; agile methods like SAFe provide the delivery engine at project level. We don’t replace SAFe — we give it a home inside a governed portfolio.
Change Management Frameworks: Prosci ADKAR and Kotter
Prosci’s ADKAR model (Awareness, Desire, Knowledge, Ability, Reinforcement) and Kotter’s 8-Step Change Model are the most widely used approaches to organisational change management.
Our position: HoLiDySt’s change management dimension is method-agnostic. We define what needs to happen (change impact assessment, stakeholder engagement, adoption tracking, champion networks) but don’t prescribe which underlying model to use. Bring your preferred change approach — ADKAR, Kotter, or another — and plug it into the framework.
TOGAF — The Open Group Architecture Framework
An enterprise architecture framework used for designing, planning, implementing, and governing enterprise information technology.
What we learned from it: TOGAF’s architectural thinking — layers, domains, reference models — influenced how we structured the maturity model. The idea that you assess and improve across multiple interconnected dimensions, not in isolation, comes partly from enterprise architecture thinking.
Other Models
- MoP (Management of Portfolios): Useful for portfolio selection and prioritisation, but not a full maturity model. Elements integrated into our portfolio playbook.
- PfM2: The EU’s project portfolio management model. Narrower in scope but informative for public sector contexts.
- CMMI: Strong for software and process maturity, but doesn’t fully cover portfolio/programme delivery.
- OKRs (Objectives and Key Results): A strategy-to-execution framework increasingly used alongside traditional KPIs. We integrate OKR thinking into our Vision-to-Value mapping approach.
- Design Thinking: Human-centred design principles that complement our emphasis on stakeholder engagement and user adoption.
Why We Didn’t Just Copy
Organisations often spend months filling out maturity assessments, only to end up with:
- A colourful heat map.
- A 150-page consultant report.
- …and no practical tools to actually improve delivery.
The gap in every established model is the same: they assess well but don’t equip well. They tell you where you are but don’t hand you the templates, governance models, workshop guides, and practitioner tools to get where you need to be.
We also found that traditional models consistently underweight the human factors — leadership, culture, adoption, resistance — that actually determine whether a transformation succeeds or fails. You can have perfect governance and still fail if your sponsors aren’t visible, your change champions aren’t empowered, and your training programme is a compliance exercise rather than a capability builder.
Our Approach
We took what works from these models and left behind what doesn’t:
Kept: Comprehensive coverage of portfolio, programme, and project maturity. Core dimensions like Governance, Benefits, Risk, Finance, and Resources. Stage-gate governance. Benefits dependency thinking. Structured assessment methodology.
Left behind: Long, bureaucratic assessment cycles. Generic reports with no tools for real improvement. Rigid assumptions about delivery methods. Frameworks that treat change management as an afterthought.
Added: Six modern transformation capabilities that traditional models miss entirely — Change Management & Adoption, Transformation Leadership, Agility & Adaptability, Technology Enablement, Data-Driven Benefits Analytics, and Learning & Knowledge Management. A template library that eliminates blank-page starts. A categorisation framework that right-sizes the methodology. Integration with agile and hybrid delivery. Practitioner guidance that tells you not just what to do, but what typically goes wrong and how to avoid it.
In short, we use maturity assessment as a stepping stone, not an end goal. It tells us where we are, so we can define where we want to be — and get there without drowning in paperwork.
The Baseline Imperative
It sounds obvious, but it needs saying because it’s so often ignored:
If you want to improve something, you need to know where you’re starting from.
You wouldn’t start a fitness plan without knowing if you can jog a kilometre without collapsing. You wouldn’t fix a leaky boat without first finding where the holes are.
Yet, in transformation management, organisations routinely jump straight to buying tools or launching massive PMOs without really understanding their current maturity. The result is predictable: solutions that don’t fit the problem, investments that don’t address the actual gaps, and improvement efforts that fix what isn’t broken while ignoring what is.
That’s why this framework starts with assessment — not as an academic exercise, but as a practical foundation:
- Measure where you are today.
- Understand what’s already working well (so you don’t fix what isn’t broken).
- Pinpoint exactly where to improve, with targeted actions instead of throwing more process and paperwork at the problem.
Baseline → Target → Practical steps in between. It’s not rocket science — just good practice.