Choose between predictive, agile and hybrid delivery for each part of an IT project, and explain the choice to a sponsor.
Why it matters
In your agile course you learned how Scrum and Kanban teams deliver in small increments. In the real IT world, few projects are purely agile. A project to replace a clinic's booking system might include a software build (well suited to sprints), a hardware purchase with a six-week lead time, a data migration that has to happen on one weekend, and a regulator who wants a signed test report before go-live. A project lead's first big decision is how to deliver each part, and the honest answer is often "a bit of both".
This lesson gives you a practical way to choose, and the words to explain your choice to a sponsor.
Three approaches
Predictive (often called waterfall or plan-driven) fixes scope early, plans the whole job up front and then executes the plan in phases: requirements, design, build, test, deploy. Change is possible but goes through formal change control. It works best when requirements are stable and well understood, when work must happen in a fixed order, or when mistakes are expensive to undo.
Adaptive (agile) fixes time and team size, and lets scope flex. The team delivers working increments every one to four weeks, gets feedback and re-plans. It works best when requirements are uncertain, users can give frequent feedback, and the product can be released in pieces.
Hybrid combines the two on purpose. Common patterns are:
- Predictive shell, agile core. Phase gates, a fixed budget and a launch date at the top; sprints inside the build phase.
- Agile build, predictive rollout. Features are built in sprints, but deployment to 40 sites follows a detailed cutover plan.
- Workstream split. The software team runs Scrum while the infrastructure, procurement and training workstreams run on a schedule.
Hybrid is not "agile without the discipline" or "waterfall with stand-ups". Each workstream should use the approach that fits it, and the plan should show how they connect.
A simple way to choose
Ask five questions about each major piece of work. Score each one towards predictive (P) or adaptive (A).
| Question | Leans predictive | Leans adaptive |
|---|---|---|
| How stable are the requirements? | Known and agreed | Likely to change or be discovered |
| Can we deliver in usable pieces? | No: it is all or nothing | Yes: users can use part of it |
| How costly is a change late on? | Very (hardware, contracts, regulation) | Low (software behind a feature flag) |
| How available are users for feedback? | Rarely | Every week or two |
| What does governance require? | Signed designs and phase gates | Outcomes and regular demos |
If most answers lean one way, use that approach for that piece. If they split, use a hybrid and say which parts are which.
Worked example: Northside Clinics booking portal
Throughout this course you will follow one project. Northside Clinics, a group of 12 clinics, is replacing its phone-only appointment booking with an online portal. The budget is $480,000 over nine months.
| Workstream | Assessment | Approach |
|---|---|---|
| Patient-facing portal | Requirements will change once patients try it; can release to one clinic first | Agile (two-week sprints) |
| Integration with the clinical records system | Vendor API is fixed, contract needs a defined scope | Predictive, with a fixed-scope statement of work |
| Kiosk hardware for waiting rooms | Six-week lead time, cannot change after ordering | Predictive |
| Staff training and rollout to 12 clinics | Depends on clinic calendars; must be scheduled | Predictive rollout plan, clinic by clinic |
So the project is a hybrid: one governance framework, one budget and one integrated schedule, with the portal team working in sprints. The integrated schedule shows the dependencies that matter: the portal cannot go live at a clinic until the integration is tested and the kiosks are installed there.
To explain this to the sponsor, keep it short:
"We will build the portal in two-week sprints and show you working software every fortnight, because we expect to learn a lot from patients. The records integration and the kiosk order are fixed by contracts and lead times, so we will plan those in detail now. You will see one combined schedule and one status report."
Making a hybrid work
- Align cadences. Hold steering meetings on a rhythm that matches sprint reviews, so the board sees real demos.
- Use milestones as the bridge. Predictive workstreams report against milestones; the agile team maps its release plan to the same milestones.
- Keep one risk register and one change process. Agile backlog changes inside the agreed scope do not need a change request; changes to budget, date or major scope do.
- Agree what "done" means for each workstream so that handoffs are clear.
Common mistakes
- Choosing by habit or fashion. "We are an agile company" is not a reason to run a hardware order in sprints.
- Two disconnected plans. If the agile team and the infrastructure team plan separately, nobody sees the dependency until it breaks.
- Fixed scope, fixed date, fixed budget and "agile". Something has to flex. Say what.
- Forgetting the people side. Teams used to one approach need coaching to work alongside the other.
Quick recap
- Predictive fits stable, sequential, costly-to-change work; adaptive fits uncertain work that can be delivered in pieces.
- Hybrid means choosing per workstream on purpose, inside one governance framework.
- Use a short set of questions to decide, then explain the choice in plain language.
- Connect workstreams with shared milestones, one risk register and one change process.
Try it
Open the Do tab and answer the quiz to check you can pick an approach for different kinds of work.