I’ve been involved in project management for a good many years now, and one of the things that continues to fascinate me is how readily people become convinced that a particular way of managing projects is the answer to almost everything.
Over the years, I’ve seen organisations become enthusiastic about detailed traditional planning, then turn their attention to Agile, and more recently begin talking about Hybrid project management as though combining the two must surely provide the perfect solution.
Now, I’m certainly not suggesting that these developments are a bad thing, because project management needs to evolve as the work we’re doing becomes more complex and the expectations of customers change.
What concerns me is the tendency to choose a methodology because it’s fashionable, or because somebody in senior management has attended a conference and returned convinced that the entire organisation needs to start working differently.
I’ve seen perfectly sensible project teams struggle because they’ve been expected to follow an approach that simply doesn’t suit the work they’re trying to deliver.
So, I thought it might be useful to explore the differences between Agile, Waterfall and Hybrid project management from a practical point of view, rather than simply repeating the definitions you’ll find in training manuals.
I want to look at why each approach exists, the circumstances in which it can help, and how you can decide which one makes sense for your own projects.
Because when you’re responsible for delivering something important, the real question isn’t which methodology sounds most impressive, but which approach will give you the best chance of achieving the results your organisation needs.
Why Waterfall Project Management Still Has an Important Place
Let’s begin with Waterfall, which is the name commonly used for a traditional predictive approach to project management.
The underlying principle is that if we understand what needs to be delivered, and we have enough experience of the work involved, we should be able to develop a reasonably reliable plan before committing substantial resources to delivery. That plan gives everyone a shared understanding of the objectives, the work required, the estimated costs and the sequence in which activities need to take place.
Imagine that you’ve been asked to manage the construction of a new warehouse for a distribution company. Before the contractors arrive, you’ll need an agreed design, planning permissions, structural calculations, a budget and a schedule that takes account of the many dependencies involved in construction.
You’ll also need to arrange materials and equipment at the right time, because there’s little point having expensive machinery standing idle while the site is still being prepared. And you certainly wouldn’t want to discover halfway through construction that the foundations aren’t suitable for the building you’ve been asked to deliver.
Of course, even the most carefully planned construction project can encounter unexpected difficulties. Ground conditions may be different from those anticipated, a supplier might fail to deliver on time, or the customer could request changes that affect the original design.
However, because much of the work is familiar and the requirements can usually be established before construction begins, predictive planning provides a sensible basis for coordinating activities and managing the inevitable problems that arise.
I think this is worth emphasising because Waterfall sometimes receives an unfair amount of criticism from people who have become enthusiastic about Agile. There’s nothing outdated about planning carefully when the circumstances justify it, and there are plenty of projects where failing to establish a sound plan before starting work would be irresponsible.
The important consideration is whether we know enough about the requirements and the solution to make that planning worthwhile, rather than assuming that every project can be predicted with the same degree of confidence.
Why Traditional Planning Can Become a Problem
Now, let’s imagine a rather different situation. Your organisation wants to develop a new mobile application for customers, and although everybody agrees on the broad business objective, there’s considerable uncertainty about which features customers will actually find useful.
The marketing department has some ideas, senior management has its own expectations, and the project team has been asked to produce a detailed plan showing what the finished application will contain and when it will be delivered.
You could certainly approach this in a traditional way, spending several months gathering requirements, designing the application and then developing and testing everything before customers get an opportunity to use it.
The difficulty is that the assumptions made during those early discussions might turn out to be wrong, particularly if customers haven’t previously used anything quite like the proposed product. By the time the application is finally released, the organisation could discover that some of the most expensive features are rarely used, while something relatively simple that customers would have valued has been overlooked.
Now, I wouldn’t necessarily blame the project team for this, because they may have done an excellent job of delivering what was originally requested. The real problem is that the organisation tried to make too many detailed decisions before it had enough information to make them confidently.
When we’re developing something unfamiliar, especially where customer preferences are uncertain, there are limits to what we can learn from meetings, specifications and planning documents alone.
This is where the distinction between delivering the agreed scope and achieving genuine business value becomes particularly important.
A project can finish on time, stay within budget and satisfy the original specification, yet still disappoint the people who funded it if the finished product doesn’t deliver the benefits they expected. And once you recognise that possibility, it becomes easier to understand why a more adaptive approach may sometimes be the better choice.
How Agile Project Management Helps Us Learn as We Go
One of the most useful things about Agile is that it recognises that we don’t always know enough at the beginning of a project to make every important decision.
Rather than treating that uncertainty as a planning failure, Agile approaches allow us to develop the product in smaller increments, obtain feedback and use what we’ve learned to make better decisions about the work that follows.
Let’s return to our mobile application. Instead of spending a year developing the complete system, the team might begin by creating a relatively simple version containing the features considered most important.
A group of customers can then try those features and explain what they like, what they find confusing and what they would prefer to see improved. The development team can use that information to reconsider priorities, adjust the design and decide what should be included in the next increment.
What I particularly like about this approach is that it reduces the danger of investing large amounts of money in assumptions that haven’t yet been tested. If customers discover that a proposed feature isn’t especially useful, the team can reconsider it before spending months developing something that may add little value.
Equally, if feedback reveals an unexpected opportunity, the organisation has a chance to respond while the product is still being developed rather than waiting until the entire project has finished.
However, it’s important not to confuse flexibility with a lack of discipline, because Agile projects still need clear objectives, sensible priorities, capable people and appropriate control over expenditure.
The difference is that detailed plans are expected to evolve as the team learns more, while the overall direction remains focused on delivering something valuable. In my experience, this is often the point at which people who are accustomed to traditional project management begin to appreciate what Agile is really trying to achieve.
Where Scrum Fits Into Agile Project Management
While we’re discussing Agile, it’s worth clearing up a misunderstanding that I still encounter quite frequently, which is the assumption that Agile and Scrum are simply two names for the same thing.
Agile is a broader set of values and principles concerned with how teams collaborate, deliver useful results and respond to change, whereas Scrum is a particular framework that helps teams apply an adaptive approach to complex product development.
In Scrum, work is organised into short periods called Sprints, each of which has a clear goal and provides an opportunity to create a useful product increment.
The team regularly examines its progress, works together to overcome difficulties and reviews the results with stakeholders so that what has been learned can influence future decisions. This creates a regular rhythm of delivery and feedback, which can be particularly valuable when the requirements or the solution are expected to evolve.
The difficulty arises when organisations adopt the terminology and ceremonies associated with Scrum without understanding the conditions that allow it to work effectively.
I’ve come across situations where teams are encouraged to respond quickly to customer feedback, yet even relatively minor changes must pass through several layers of management approval before anybody is allowed to act. The team may be holding Daily Scrums and planning Sprints, but if the surrounding organisation makes adaptation unnecessarily difficult, many of the potential benefits are lost.
That doesn’t mean that governance should disappear or that teams should be free to make decisions without considering their wider consequences. It means that organisations need to think carefully about which decisions can sensibly be delegated, how priorities will be managed and what controls are genuinely necessary.
It’s also worth remembering that Scrum isn’t the only Agile framework, and that approaches such as Kanban may be more suitable when work arrives continuously and needs to be managed as a flow rather than through fixed-length Sprints.
Why Hybrid Project Management Is Attracting So Much Attention
Now, this brings us to Hybrid project management, which I think is particularly interesting because it recognises that a single project can contain very different types of work.
Some activities may be familiar, predictable and dependent on carefully planned sequences, while others may involve uncertainty and benefit from frequent feedback. Rather than insisting that every part of the project follows exactly the same delivery method, Hybrid allows us to combine approaches where doing so makes practical sense.
Imagine that you’re responsible for a major programme to open a new hospital. There will be construction work, regulatory approvals, installation of medical equipment, recruitment and training, and probably several important information systems that need to be operational before patients arrive.
Much of the physical infrastructure will require careful predictive planning, particularly where safety, compliance and contractual commitments are involved, because there are limits to how much uncertainty can be tolerated when you’re preparing a hospital for use.
However, suppose the programme also includes developing a new digital appointment system. The people responsible for that system might benefit from producing an early version, allowing doctors, nurses and administrative staff to try it, and then making improvements as they learn more about how the system will be used.
There’s no obvious reason why that software team should be required to follow exactly the same detailed delivery practices as the construction contractors, provided that both groups understand the overall programme requirements and the dependencies between their work.
This is where Hybrid can provide a sensible balance, because the programme can retain the planning and governance needed to coordinate the overall undertaking while allowing individual teams to use delivery practices suited to their responsibilities.
The appointment system might be developed incrementally, for example, but it must still integrate with the hospital’s other systems, meet security requirements and be sufficiently reliable when the hospital opens.
Hybrid doesn’t remove those obligations; it simply gives us more flexibility in deciding how different parts of the work should be delivered.
[INSERT RICH PICTURE 2 HERE — Hybrid Hospital Project]
How I Would Choose Between Agile, Waterfall and Hybrid
If somebody asked me to recommend a delivery approach for their next project, I’d begin by finding out as much as possible about what they’re trying to achieve, rather than immediately asking which methodology their organisation normally uses.
I’d want to understand how clearly the requirements are known, how familiar the proposed solution is, what constraints exist and whether there are opportunities to deliver useful results before the entire project is complete.
For example, if an organisation is replacing an existing system with a well-established commercial product, the requirements may be reasonably clear and the supplier may have considerable experience of similar implementations.
In that situation, predictive planning could provide a dependable way of coordinating procurement, configuration, testing, training and the final changeover. There may still be opportunities for iterative work, but the overall project could benefit from a structured plan with clearly defined milestones and responsibilities.
Now compare that with an organisation developing a completely new digital service for a market it hasn’t previously entered. The business may have a clear objective, but it might not know which features customers will value most or how their needs will develop once the service becomes available.
Here, I’d be much more inclined to explore an Agile approach because it would allow the team to test assumptions, gather feedback and progressively improve the product without committing the entire budget to decisions made at the outset.
And if the project involves a mixture of familiar, predictable work and more uncertain development activities, I’d seriously consider whether Hybrid would provide a better solution.
The important thing is to recognise that choosing an approach isn’t simply a matter of selecting a label for the project documentation. It’s a management decision that affects planning, governance, communication, risk, stakeholder involvement and the way the organisation responds when circumstances change.
Three Practical Examples of Choosing the Right Approach
Let’s take three everyday situations that illustrate how these decisions might work.
The first involves replacing an ageing payroll system with a well-established commercial product. The organisation understands its payroll requirements, the supplier has delivered similar systems before and there’s a fixed deadline for moving from the old system to the new one.
I’d probably favour a predominantly predictive approach here, because the project needs careful coordination around data migration, testing, compliance and the final changeover, although I’d still expect the team to configure and test parts of the system iteratively where that would be helpful.
Now imagine a company developing a completely new mobile application for customers in a market it hasn’t previously served. The organisation has an idea that appears promising, but there’s considerable uncertainty about what customers will find most useful.
In that situation, an Agile approach could allow the team to release a limited version, obtain feedback and then invest further effort in the features that demonstrate the greatest value, rather than spending the entire development budget on assumptions that may later prove incorrect.
Finally, consider a programme to modernise a regional transport network, including station infrastructure, ticketing equipment and a new customer journey-planning application.
The infrastructure and equipment installation may require predictive planning because of physical dependencies, safety requirements and contractual commitments, while the application development could benefit from iterative delivery and regular customer feedback.
A Hybrid approach would allow these different workstreams to operate in ways that suit their characteristics, provided that the programme has effective arrangements for managing integration, dependencies and overall progress.
The reason I like these examples is that they demonstrate how the choice of delivery approach should follow from the nature of the work.
We’re not trying to prove that one methodology is superior to another, and we’re certainly not suggesting that every project must fit neatly into a single category. We’re simply using professional judgement to decide how the work can be managed most effectively.
Why Hybrid Requires More Than Simply Mixing Methodologies
Although Hybrid can offer considerable advantages, combining different approaches introduces management challenges that shouldn’t be underestimated.
For example, suppose the overall programme has a fixed completion date and several important contractual commitments, while one of the delivery teams is working with an evolving Product Backlog and regularly adjusting priorities based on stakeholder feedback.
At some point, that team may identify a new feature that customers would find extremely valuable, but delivering it could affect a milestone or require additional work from another team.
Somebody then needs to decide whether the feature should be included, deferred or rejected, taking account of its potential benefits and the consequences for the wider programme.
That decision may involve the Product Owner, the project manager, the sponsor or other authorised stakeholders, depending on how responsibilities have been established.
What matters is that the decision-making arrangements are understood before disagreements arise, rather than leaving teams to discover halfway through delivery that nobody is quite sure who has the final say.
We also need to think carefully about how progress will be measured and reported, because different teams may use different indicators. A predictive delivery team might report progress against planned milestones, while an Agile team may focus on completed product increments and the value those increments provide.
Neither approach is inherently wrong, but the overall programme still needs a reliable way of understanding whether the work is coming together as intended and whether the expected business benefits remain achievable.
In my experience, the success of Hybrid depends heavily on the quality of the coordination between different teams and the clarity of the governance arrangements supporting them.
When those arrangements are properly thought through, the approaches can complement one another very effectively, but when they’re neglected, organisations may find that individual teams are performing well while the overall project struggles to deliver a coherent result.
Why Understanding All Three Approaches Can Improve Your Career
There’s another reason why I think it’s worth developing a good understanding of predictive, Agile and Hybrid delivery, particularly if you’re looking to progress your career in project management.
Organisations rarely have the luxury of undertaking only one type of project, and as your responsibilities develop, you’re likely to encounter situations where the approach that served you well previously is no longer the most suitable.
You might spend several years managing relatively predictable infrastructure projects, for example, and then find yourself responsible for a digital transformation initiative where requirements are evolving and stakeholders need regular opportunities to review the emerging solution.
Equally, somebody who has spent most of their career working in Scrum Teams may eventually become responsible for a programme involving procurement contracts, regulatory approvals and complex dependencies that require more predictive planning.
In either situation, understanding only one approach can become a limitation, because you may be tempted to apply familiar practices even when the circumstances suggest that something different would work better.
I believe the strongest project professionals are those who understand the principles behind different approaches and can explain why they’ve selected particular practices for the work they’re responsible for delivering.
This is also one reason why qualifications such as PMP, PRINCE2 and APM PMQ can be valuable when they’re taught properly.
Learning the terminology is useful, of course, but the real benefit comes from understanding how to apply the knowledge in practical situations, particularly when you’re faced with competing priorities, uncertainty or decisions that don’t have an immediately obvious answer.
It’s also an important part of preparing for scenario-based examination questions, where you may need to recognise the most appropriate response to a situation rather than simply remember a definition.
So Which Project Management Approach Is Best?
Well, if you’ve stayed with me this far, you probably won’t be surprised to hear that I don’t believe there’s a single answer to which approach is best, because so much depends on the circumstances of the project.
Where the requirements are reasonably stable and the work is familiar, predictive planning can give us a great deal of confidence about what needs to be done, how long it should take and what resources we’re likely to need.
However, when we’re dealing with something new, particularly where customers may not fully understand what they want until they’ve seen an early version of the product, an Agile approach gives us opportunities to learn and make adjustments before we’ve committed too much time and money.
Of course, there will also be projects where neither approach is entirely suitable on its own, and that’s where Hybrid can be particularly useful. We might have some activities that require careful planning and formal approvals, while other parts of the work would benefit from shorter development cycles and regular feedback.
The important thing is to recognise those differences and manage them sensibly, rather than insisting that every team must follow exactly the same procedures simply because somebody has decided that’s how the organisation manages projects.
So, if somebody asked me whether they should use Agile, Waterfall or Hybrid on their next project, I’d probably begin by asking them to tell me a little more about what they’re trying to achieve.
I’d want to understand how much they already know about the requirements, where the main uncertainties lie and whether there are opportunities to deliver useful results in stages. Once we’ve had that conversation, we’re in a much better position to make a recommendation that suits the project.
Develop Your Project Management Skills With Projex Academy
If you’ve found this discussion useful and would like to develop a deeper understanding of how different project delivery approaches work, you might like to explore the training available through Projex Academy.
Our PMP Masterclass covers predictive, Agile and Hybrid approaches as part of a broader understanding of professional project management, with particular attention to applying sound judgement in realistic project situations.
You can also explore our PRINCE2 Scrum Masterclass if you’re interested in understanding how structured project governance and Scrum practices can complement one another.
And if you’re looking to develop your professional knowledge more broadly, you’ll find our complete collection of Projex Academy Masterclasses, covering project management, Agile delivery and business improvement.
I’ve always believed that good professional training should help people understand not only what to do, but why they’re doing it and how to recognise when a different approach might produce better results. That’s the thinking behind the training I’ve developed over the years, and it’s the approach we continue to follow at Projex Academy.
Dave Litten
Project Management Trainer, Author and Founder of Projex Academy
