Project Management Approaches: Predictive, Adaptive and Hybrid
In short
The three main project management approaches are predictive, adaptive and hybrid. Predictive (waterfall) plans the whole scope up front and suits fixed, well-understood requirements. Adaptive (agile) delivers in short iterations and suits requirements that change. Hybrid plans the fixed parts up front and iterates on the rest, which fits many software projects.
What are the three main project management approaches?
PMI's PMBOK Guide describes development approaches on a spectrum: predictive at one end, adaptive at the other, and hybrid approaches that combine the two. Each answers the same question differently: how much do we decide before we start building?
| Predictive | Adaptive | Hybrid | |
|---|---|---|---|
| Also called | Waterfall, plan-driven | Agile, iterative (Scrum, Kanban) | Blended, "water-scrum-fall" |
| Planning | Detailed plan for the whole project up front | High-level plan, detailed plan per iteration | Up-front plan for fixed parts, iteration plans for the rest |
| Requirements | Fixed early and signed off | Expected to change; reprioritized often | Core fixed, features flexible |
| Delivery | One release at the end of sequential phases | Working software every iteration | Planned milestones with iterative delivery between them |
| Handling change | Formal change control | Absorbed into the next iteration | Change control for fixed parts, backlog for the rest |
| Client involvement | Heavy at the start and at acceptance | Continuous, every iteration | Heavy at milestones, regular in iterations |
| Progress measured by | Completion against the plan | Working software | Both |
| Best for | Fixed scope, regulation, like-for-like migrations | New products, MVPs, unclear requirements | Fixed launch dates, hardware or third-party dependencies |
| Main risk | Building the wrong thing well | Scope drift without a strong product owner | Two sets of rules if the boundary isn't clear |
What is the predictive approach?
The predictive approach plans the whole project before building starts, then delivers it in sequence: requirements, design, build, test and release. Think of a building: you finish the blueprint before you pour the foundation, and you pour the foundation before you raise the walls.
It works when requirements are known and unlikely to change. In software, that includes like-for-like platform migrations, integrations with a fixed external specification and work with regulatory sign-offs at set points. Its weakness is late learning: if users only see the product at the end, any misunderstanding surfaces when it's hardest to fix.
What is the adaptive approach?
The adaptive approach delivers working software in short cycles and adjusts the plan after each one. The Manifesto for Agile Software Development (2001) sums up its priorities, including working software over comprehensive documentation and responding to change over following a plan. In Scrum, a widely used agile framework, each sprint is a fixed time box of one month or less, according to the Scrum Guide.
A typical example is a new mobile app. The team launches an MVP with a few core features, learns from real users and decides what to build next from that evidence. The risk is drift: without a product owner who says no, the backlog keeps growing and the release date slips.
What is the difference between predictive and adaptive project management?
The difference is when you decide. Predictive project management decides most things up front and treats change as an exception. Adaptive project management decides a little at a time and treats change as normal.
- Planning horizon. Predictive plans the whole project. Adaptive plans the next iteration in detail and the rest loosely.
- Feedback. Predictive gets most user feedback at acceptance. Adaptive gets it every iteration.
- Progress. Predictive tracks completion against the plan. Adaptive tracks working, tested software.
- Change. Predictive routes change through change control. Adaptive adds it to the backlog and reprioritizes.
When should a software project use a hybrid approach?
Use a hybrid approach when part of the project can't move and part of it is still uncertain. Common signs:
- A launch date is fixed, for example by an event, a contract or funding, but the feature list isn't.
- Hardware, IoT devices or third-party integrations need long lead times and early decisions.
- Security, compliance or architecture decisions must be made before features can be built safely.
- Several teams or vendors have to meet at shared milestones.
A typical hybrid project looks like this:
- Plan the fixed parts. Discovery, architecture, integrations and the release date.
- Iterate on the rest. Build features in sprints and reprioritize from feedback.
- Stabilize before release. Hardening, acceptance testing and launch at the planned milestone.
Is agile always better than waterfall for software?
No. Agile is the better default when requirements are uncertain and users can give feedback often, which is true of most new products. A predictive approach can fit better when scope is fixed by contract or regulation, when the work is well understood, or when several teams must hit the same dated milestones. Choosing agile for a fixed-scope migration adds ceremony without adding learning. Choosing waterfall for a new product risks months of work on features nobody uses.
How do we choose an approach with clients?
Our own delivery process is a hybrid. We set goals, scope and design up front during discovery and prototyping, then build from the MVP onward in agile iterations driven by user feedback.
Where a project starts depends on its situation:
- A fixed deadline. We shipped the Customer Support App, a WhatsApp-style chat platform for customer support, as an MVP in four weeks on the MERN stack with a small, focused team. When the date can't move, an MVP keeps the date and makes the scope the variable.
- An open feasibility question. For Zero Cheating, a Chrome extension that flags AI-written exam answers, the first question was whether it could work at all, so we started with a proof of concept in a controlled environment before planning the full build.
Before a project starts, we work through these questions together:
- Is the scope fixed by a contract, a regulation or an existing system? If yes, lean predictive for that part.
- Will users shape the product after they see it? If yes, lean adaptive.
- Is there a date that can't move? If yes, fix the date and let scope flex, usually through an MVP.
- Are there hardware, integration or compliance dependencies with long lead times? If yes, plan those up front.
- Who decides priorities each week? Adaptive work needs a product owner with the authority to say no.
- What is the riskiest assumption? Test it first with a prototype or proof of concept.
Our MVP development services follow this pattern for new products. For larger systems with fixed integrations, our custom software development services start with the up-front planning a hybrid approach needs.
How does the approach relate to the engagement model?
They're separate decisions. The project management approach decides how the work is planned and delivered. The engagement model decides how you work with a development partner: staff augmentation, a dedicated team or a fixed-price contract.
Some pairings come naturally. A dedicated development team suits adaptive and hybrid work, because the same team carries what it learns from one iteration to the next. A fixed-price contract needs a predictive scope baseline, at least for the part that is fixed.
Sources
Topic:
- #Project Management
Share this article
Frequently asked questions
Short answers to the questions readers ask next.
Is Scrum the same as agile?
No. Agile is a set of values and principles from the 2001 Agile Manifesto. Scrum is one framework for putting them into practice, with a Scrum Master, a Product Owner and Developers working in sprints of a month or less.
Who decides priorities in an adaptive project?
The product owner, who orders the backlog and owns the product goal. With a development partner, that person needs real authority to say no to new requests, or the backlog keeps growing and the release date slips.
How should a hybrid project report progress?
In one place, two ways. A milestone plan shows whether fixed commitments such as integrations and the launch date are on track, and a sprint demo shows the working software. Seeing both makes trade-offs visible early.
Can a project change its approach partway through?
Yes, and many do. A common pattern is predictive discovery and architecture, then sprints once the core is in place. Switch at a phase boundary, such as after a proof of concept, and agree the change with every stakeholder.
Need a team to deliver your next project?
Tell us what you're building and we'll walk you through how we'd approach it.
