Traditional Project Management Needs to Evolve to Meet the Demands of Durable Capability

PMI's methodology, Prince2's stage and deliverable model, and the broader family of established project disciplines are not weak. They carry real structure: defined governance through sponsors and steering committees, risk management relating to project delivery, stakeholder engagement through scheduled meetings, deliverable acceptance criteria and sign-offs, change control to monitor scope creep. Organizations are not running their projects carelessly.

And yet, the failure modes this series has documented still show up. Technology gets delivered. People get trained. The milestone gets hit, the ROI is documented, the stage gate closes, the dashboard shows green. Workarounds appear anyway. However, that is not evidence that these methodologies are insufficient as disciplines. They are evidence of where project management stops and where reality begins.

Solving Before Validating

These methodologies are built to execute, with real discipline, against a defined scope they were handed. The business case itself often carries the same gap. Objectives get built almost entirely around ROI: what the new system or process will save in licensing or purchasing costs. That case gets built against the future state, and the cost of continuing to operate in the old model, the people, time, rework, and waste embedded in it, gets left out of the comparison. The project gets approved on a number that looks rigorous, savings calculated, payback period modeled, but the objective was never actually comparing the full cost of the current state against the full cost of the new one. It was measuring savings, not measuring the real delta. An objective built that way can clear every approval gate and still be solving for the wrong magnitude of problem. The fix gets planned before the problem and the cost of the current state get validated. This is backwards.

Where the Failure Modes Actually Live

The Adoption Problem starts with a flawed assumption baked into the objective itself: that new ways of working will take hold automatically once the new system exists, with only training on the new tool provided. People are told the change is coming. They are rarely given the information and detail that would let them understand why it is coming, what it changes for them, and what happens to the work they currently do around it. Real adoption work, communication, feedback loops, Q&A, surfacing the workarounds people are already planning, has to start before day one. The project's clock started at requirements and design. Adoption's clock should have started there too, and in most projects, it is only once the system goes live that the resistance becomes visible.

The Governance Gap is a genuinely different kind of problem: it shows up after the project closes, not during it. The steering committee and the escalation path exist to govern delivery decisions while the project is active, not to sustain the new ways of working once they are trained and handed over. The moment handover happens, that governance structure dissolves along with the project team. Nothing failed during execution. The structure simply was not built to give the manager or process owner a way to track actual performance against the project's stated objective.

The Executive Sponsor is doing real work for the life of the project: clearing obstacles, making prioritization calls, owning escalations. But that work is scoped to project execution. The sponsor shows up for the meetings where decisions get made. The communication that drives adoption, explaining why the change matters, reinforcing it consistently, being an active and visible voice for the people being asked to work differently, never happens. Sponsorship was never defined to include the role of communicator. The gap is not that the sponsor failed. It is that sponsorship's job description never updated to include the communication adoption actually depends on.

The Empty Chair is by far the most consequential failure mode here. It is the difference between a project that succeeds and one that technically closes. The teams whose work is impacted by the change, upstream or downstream, must have a standing requirement to be in the room before the problem is even fully scoped, not introduced after the fix has already been planned around people who were never consulted.

What This Means for the Work Ahead

This is not an argument that PMI, Prince2, or any established methodology needs to be replaced. The discipline behind stage-gated delivery and deliverable acceptance is sound, and worth keeping. The argument is that there is additional work and validation that has to happen before that discipline takes over, not after.

This is what FORGE is built to address. Filter and Objective are the validation layer that established methodologies assume already happened: sizing the problem correctly, and building an objective that accounts for the full cost of the current state and not just the savings of the future one. Root carries the weight of the Empty Chair. It is where the teams upstream and downstream of the change have a standing requirement to be in the room, before the problem definition is locked, not after a fix has already been planned around them. None of that replaces PMI or Prince2 discipline. It is the missing step before that discipline is handed a scope to execute against.

Generate is the direct answer to the Adoption Problem: building the people who will use the solution into the design as a tracked requirement starting well before go-live, with an adoption gate the project cannot pass through on schedule alone, not assuming the tool's existence does that work on its own. Endure is the direct answer to both the Governance Gap and the Executive Sponsorship gap: a designed way to track actual performance against the project's stated objective once the project team disbands, and to keep communicating and reinforcing the change well past go-live, so ongoing monitoring, accountability, and feedback loops have somewhere to land instead of ending when the project does.

What Comes Next

This is the map, not the full picture. The articles ahead go into what each phase actually requires in execution: what Objective looks like when it accounts for the full cost of the current state instead of only the savings of the new one, what Root looks like when the team isn't walking in with a preconceived solution already in mind, what Generate requires to produce adoption instead of a workaround running quietly alongside it, and what Endure looks like as an ongoing governance and communication practice, not a line in a lessons-learned document.

PMI, Prince2, and the methodologies built around them carry real discipline. The work ahead is not asking them to do more. It is engaging them at the right time, with the right information, so the team executing has confidence the solution being built is correctly scoped, capable, and built to last.

Part of an ongoing series on operational design, process transformation, and what it takes to make change endure.