Choose the Approach Around the Deliverable
Most arguments about whether a project should be predictive, Agile or hybrid begin in the wrong place. They begin with the team's experience, the organisation's standard method or the sponsor's instinct, and only later ask what the project is going to produce. Yet the deliverable is often the strongest evidence available. A new building, a software service, a set of revised procedures and a qualified piece of equipment behave very differently while they are being made, and they tolerate change very differently once they exist.
The short answer to how deliverables influence the development approach is this. A deliverable pushes the approach one way or the other through a small number of practical characteristics: whether it can be released and used in pieces, how expensive it is to change once built, how early anyone can give useful feedback on it, and whether it has to be proven as a complete whole before anyone may use it. When those characteristics differ across the deliverables of one project, the approach should differ with them.
Start with what the project has to hand over
Section 4.3.1 of The Standard for Project Management places deliverables among the considerations that inform the choice of development approach. The practical reading is simple enough: before deciding how the work will be planned and controlled, look carefully at what the work produces. That step is skipped more often than experienced practitioners might expect.
Organisations with an established Agile practice sometimes run sprints against deliverables that cannot meaningfully be released in increments, and then wonder why each sprint review shows a partly finished thing nobody can use. Organisations with strong stage-gate governance sometimes insist on a fully specified baseline for a product whose users cannot describe their needs until they have handled a working version. Both habits are understandable, and both choose the method for the organisation's comfort instead of the work's needs.
A useful discipline at project start is to write down the major deliverables before any conversation about approach begins, and to include the less visible ones. Test and assurance evidence, trained users, updated operating procedures and a support arrangement ready to take over are all deliverables with their own behaviour. The list frequently shows that the project is not one kind of work at all, which is exactly the information the approach decision needs.
Reading the character of a deliverable
Omega uses four questions to read a deliverable's character. They are a practical way of thinking, not an official PMI framework, and none of them decides the matter alone.
Incremental usefulness is the first. Ask whether a partial version of the deliverable gives anyone real value or real learning. A customer portal can go live with three services and gain a fourth next month. A bridge with half a deck gives nobody a crossing. Where early pieces can be used, adaptive delivery can release value progressively; where they cannot, increments may still help the team learn, but they will not deliver benefit on their own.
Cost of change is the second, and often the most decisive. Configuration in a software product can usually be altered cheaply and quickly. Poured concrete, machined parts, printed materials and anything installed across many sites become expensive to change the moment they exist. The higher the cost of changing a deliverable after it is made, the more it pays to settle its design before committing to production, and the more a predictive baseline earns its keep.
Speed of feedback is the third. Some deliverables can be put in front of the people who will use them within days, through a working build, a prototype or a mock-up. Others only reveal whether they are right after a long build, or only in operation. Stated requirement stability deserves some suspicion here. Stakeholders who say their requirements are fixed are sometimes describing their confidence, not their knowledge, and a deliverable that allows fast feedback gives the team a cheap way to find out which it is.
Whole-system proof is the fourth. Safety-critical, regulated or contractually accepted deliverables may need to be verified as a complete, controlled configuration before anyone is allowed to use them. That does not rule out iterative development, but it does mean that whatever evolves must be frozen, recorded and tested at defined points, and those points become fixed commitments in the plan.
These questions interact. A deliverable can be cheap to change and still need whole-system proof; another can be expensive to change and still benefit from rapid early prototyping. The pattern of answers matters more than any single one, which is why simple rules such as "uncertain means Agile" tend to mislead.
One project, several kinds of deliverable
Consider a fictional defence programme upgrading the communications equipment on forty patrol vehicles. The project has four main deliverables: an installation kit of brackets and wiring harnesses, operator display software, qualification evidence for the fitted configuration, and trained vehicle crews.
The installation kit is expensive to change once manufactured and fitted. A harness that is a few centimetres too short on forty vehicles is not something the team can refine in the next iteration; it means rework on every vehicle and another round of availability negotiations with the operating units. The project manager therefore plans a design freeze, then manages manufacture and fitting predictively against a baseline tied to the dates each vehicle can be released from service. Before that freeze, though, the harness design benefits from quick prototype builds on a test rig, because each build is cheap and teaches the engineers something. The same deliverable is handled adaptively early in its life and predictively once commitment becomes costly.
The display software behaves differently. Operators struggled to describe the layout they wanted until they used one in a realistic exercise. The team runs short iterations with a small group of crew members, working from a prioritised backlog, and the layout improves quickly.
Qualification evidence is where the two approaches meet, and where most of the project manager's attention goes. Qualification must cover the integrated configuration, so the software cannot keep changing indefinitely. The plan defines which software version enters qualification, when it must be stable, who authorises that baseline and how later changes will be assessed. Configuration management carries the discipline that makes the adaptive stream safe to combine with the predictive one. Crew training depends on the final display layout, so course material is drafted late and tested with a pilot group before the full roll-out.
Nobody on this project decided to "be hybrid". The deliverables made that decision, and the project manager's contribution was to see it early and to manage the joins between the streams deliberately.
Using the deliverable test in the exam and on the next project
For a PMP® candidate, this is less about memorising labels and more about recognising what a scenario is describing. The current PMP Examination Content Outline states that predictive, adaptive/agile and hybrid approaches run through all three exam domains, with roughly 40% of items representing predictive approaches and the remainder divided between adaptive/agile and hybrid. Its Process domain includes recommending a development approach as part of developing the integrated plan, and preparing a schedule based on the selected approach. A useful exam-preparation habit is to read what the project is producing before scanning the scenario for method vocabulary: a description of a physical product that is costly to alter carries different implications from one describing a service users are already trying out. Reading a scenario by the product it describes is one of the habits practised throughout Omega's PMP® Exam Preparation, because it transfers so directly from exam questions to project start-up.
On a real project, the deliverable test is most valuable at three moments. The first is initiation, when the deliverable list can challenge an approach that has been assumed by default. The second is whenever a deliverable changes character, for example when a prototype becomes a production item or a pilot service moves to full release. The third is when the sponsor or governance board asks why different workstreams report in different ways. An explanation grounded in the deliverables, such as the cost of rework across a fleet or the value of weekly user feedback, is far more persuasive than an appeal to methodology preference, and it gives the board a clear view of where the controlled interfaces sit.
Experienced predictive practitioners will recognise much of this as long-standing good sense about design freezes and change cost. Experienced Agile practitioners will recognise the value of putting working things in front of users early. The deliverable is what tells a project manager which of those instincts applies, and where.
Interested in going further?
Choosing an approach from the nature of a deliverable, and managing the points where different approaches meet, is the kind of scenario judgement that structured PMP preparation lets you practise before you face it on a live project.
For the full treatment of development approach selection and the considerations behind it, The Standard for Project Management within the PMBOK® Guide Eighth Edition is the reference to keep close.
Ad · Amazon affiliate link.
References
A064: Choosing Predictive, Agile or Hybrid for a Real Project
A084: Selecting the Initial Development Approach
A066: How Project Characteristics Shape the Delivery Approach
A057: How to Recognise Predictive, Agile and Hybrid PMP Scenarios
A067: How Your Organisation Limits or Enables Agile Delivery
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
