← All Insights
Classical, agile, hybrid — which approach fits when
Three methodological worlds, three contexts. When plan-driven steering is the right choice and where hybrid models deliver the greatest leverage.
Three methodological worlds, three contexts. When plan-driven steering is the right choice and where hybrid models deliver the greatest leverage.
In programme management, there is a persistently dangerous assumption: that execution quality alone determines success. It does not. Across hundreds of IT transformation programmes, one pattern recurs with striking regularity — the right team, the right budget, and the wrong methodology. Projects fail not because people work poorly, but because the structural logic of the approach is fundamentally misaligned with the nature of the work.
Methodology choice is not a secondary concern to be resolved in a project kick-off workshop. It is a primary governance decision — one that shapes how risk is managed, how decisions are escalated, how teams are organised, and how progress is defined and reported. Get it wrong, and no amount of skilled execution will compensate.
Classical, plan-driven project management — whether anchored in PRINCE2, PMI/PMBOK, or a proprietary waterfall framework — is built on a single foundational premise: the scope is known, stable, and agreed before execution begins. Within that premise, it is a highly rational approach.
Where does classical PM deliver its best results? In environments where regulatory requirements demand comprehensive documentation — infrastructure compliance programmes, financial system migrations, safety-critical industrial implementations. In construction and civil engineering projects, where physical sequencing cannot be reversed: you cannot pour the foundation after the walls go up. In fixed-price, fixed-scope contracts where both client and vendor have agreed on deliverables, and where deviating from the plan carries legal and financial consequences.
The strength of classical PM is its governance clarity. Milestones are defined, approval gates are explicit, audit trails are built into the process. Stakeholders know exactly what they are getting, when they are getting it, and what it will cost. This predictability has genuine value — particularly at executive level, where boards and steering committees are managing portfolio risk across multiple programmes simultaneously.
Plan-driven management does not fail because it is inflexible. It fails when it is applied to problems that are, by nature, not yet fully understood.
Agile methodologies — Scrum, SAFe, Kanban, and their variants — emerged from a specific problem in software development: the gap between what customers thought they wanted at the start of a project, and what they actually needed eighteen months later. The Agile Manifesto's famous emphasis on "responding to change over following a plan" is not an argument against planning. It is an argument that in complex, innovation-driven work, early decisions carry enormous uncertainty.
Agile PM thrives when three conditions are met: requirements are expected to evolve based on user feedback and market signals; customer or stakeholder feedback is available in regular, short cycles (ideally two weeks or less); and teams can self-organise around problems without heavy hierarchical steering for every decision.
In software product development, digital transformation initiatives, and innovation programmes where the end state is genuinely unclear at the outset, agile approaches radically reduce the risk of building the wrong thing. Instead of discovering the misalignment at the end of an eighteen-month waterfall project, you discover it at the end of the third sprint — when correction is cheap.
The failure mode of agile is equally predictable: applying it to contexts where it does not belong. Scrum was not designed for fixed-price contracts with a non-negotiable scope. It was not designed for regulatory programmes where every deliverable requires formal sign-off before the next phase begins. In those contexts, the iterative, adaptive logic of agile creates governance gaps that stakeholders — rightly — find unacceptable.
Most large-scale IT transformation programmes are neither purely waterfall nor purely agile. They inhabit a middle ground where some elements are fixed — architecture decisions, regulatory constraints, budget envelopes, go-live dates — while others must remain fluid — workload sequencing, feature prioritisation, team organisation, integration design.
Hybrid project management is not a compromise between classical and agile. It is a deliberate synthesis that assigns each element of the programme to the methodology that best serves it. The governance frame remains classical: a stable programme structure, clear milestones, formal steering committee oversight, and comprehensive risk management. The delivery engine becomes iterative: sprints, backlogs, retrospectives, and continuous prioritisation.
Consider a cloud migration programme as a practical example. The architectural decisions — which cloud provider, which security framework, what the landing zone design will look like — are made once, through a structured design phase, and documented formally. They are not revisited every sprint. The regulatory compliance requirements are defined upfront and govern the entire programme. But the actual migration of individual workloads — which application moves in which sequence, how each is refactored, what the testing protocol looks like — benefits enormously from iterative delivery. Each workload becomes a sprint or a short delivery cycle, with retrospectives feeding lessons learned back into the next migration wave.
Before choosing a methodology, every programme manager should work through five questions honestly:
The most frequent methodology errors we encounter in the field follow three patterns. First: using Scrum for a fixed-price contract. The vendor has committed to delivering a defined scope for a defined price. The client expects a defined output. Scrum's adaptive backlog and sprint-by-sprint reprioritisation is structurally incompatible with that commitment. The result is scope creep, disputed change requests, and broken client relationships.
Second: using waterfall for a digital product. Building a customer-facing digital platform through an eighteen-month waterfall plan, then discovering at UAT that users want something fundamentally different, is an expensive and avoidable failure mode. Product development depends on learning — and learning requires feedback loops that waterfall does not provide.
Third, and most subtle: mixing approaches without clear structural boundaries. Hybrid PM only works when the boundary between the classical governance layer and the agile delivery layer is explicitly designed and agreed. When programme managers apply elements of both without defining the interface — which decisions are made in the steering committee versus the sprint review, what triggers a scope change request versus a backlog update — the result is methodological confusion. Teams receive conflicting signals about how to escalate issues, how to manage change, and how to report progress.
There is no universally correct methodology for IT programme management. The organisations that consistently deliver successful transformations are not those that have standardised on a single approach — they are those that have developed the organisational intelligence to match methodology to context, and the programme management discipline to maintain that match as conditions evolve.
The most important skill is not mastery of Scrum or PRINCE2 in isolation. It is the judgement to read a programme's context accurately, design a governance structure that fits that context, and adapt the approach when circumstances change — without losing the structural coherence that keeps stakeholders aligned and teams productive.
Choose your methodology the way a surgeon chooses an instrument: based on what the situation requires, not on what is most familiar or most fashionable.
We help organisations choose the right methodology — and build the governance structures that make it stick.
Contact us