How Project Characteristics Shape the Delivery Approach
Discussions about delivery approach usually start with the thing being built. Software suggests Agile, a building suggests a Gantt chart, and a mix of both suggests hybrid. That instinct is useful, but it leaves out half the evidence. Two teams can build almost identical deliverables and still need different ways of working, because the projects around those deliverables are different. Who can give feedback and how often, which dates cannot move, how funding is released and what has already been promised in a contract all shape the approach as much as the product does.
The short answer to the reader's question is this: the project itself contributes its own set of conditions to approach selection, and a project manager who reads only the product will sometimes choose an approach the project cannot sustain.
The project as its own input
Section 4.3.2 of The Standard for Project Management treats the project as a distinct influence on development approach selection, sitting alongside the nature of the deliverable and the organisation delivering it. Keeping those three apart is practical as well as tidy. The deliverable tells you how stable the requirements are likely to be and whether value can be released in pieces. The organisation tells you what structures, culture and capability are available. The project tells you what this particular piece of work is committed to, who is involved in it, and under which constraints it will run.
Those project-level conditions are easy to overlook because they rarely appear in the product description. A requirements document can describe a flexible, feedback-friendly product while the funding letter releases money only against a fixed specification. A backlog can look ideal for iterative delivery while the people who need to review each increment are available twice a year. The approach has to work with both sets of facts.
This also explains why simple rules fail. "High uncertainty means Agile" assumes that the project can support frequent feedback, flexible scope and a steady team. When it cannot, an adaptive approach becomes adaptive in name only: sprints run, but nothing is reviewed by the people whose judgement matters, and scope is quietly fixed by a contract nobody mentioned at the kick-off.
Reading the conditions that matter
Stakeholder access is often the first condition worth checking. Adaptive delivery depends on people who can look at an increment, say what is wrong with it and make prioritisation decisions without a month's delay. If the customer is a distant commissioning body, a regulator or a board that meets quarterly, the feedback loop that makes iteration valuable may not exist. That does not rule out adaptive work, but it may mean building proxies, such as a user panel or an empowered product owner, and being honest about how much authority those proxies really hold.
Schedule constraints come next. A fixed external date, whether it is a statutory deadline, an event or a dependency owned by another programme, changes what can be negotiable. Iterative approaches often protect time and cost while flexing scope. Where the date is immovable and a minimum scope is also immovable, the project needs strong upfront planning for that core, even if the work around it can evolve.
The funding pattern shapes the approach in ways teams often notice late. Money released in stage-gated tranches against defined outputs fits naturally with predictive phases and formal gates. Money allocated to a persistent team over a period fits more naturally with incremental delivery and value-based prioritisation. When the two are mismatched, the team ends up producing documents to unlock funding for work it intends to discover as it goes.
Contractual and regulatory obligations add a further layer. A fixed-price contract with a detailed specification, or an approval regime that requires evidence at defined points, pulls towards stronger baselines, traceability and change control. Those demands can coexist with iterative design, provided the approach is built to satisfy them deliberately and does not treat them as an inconvenience to be worked around.
Duration, team continuity and the number of dependencies complete the picture. A short project with a stable team can absorb learning quickly. A long one with rotating contractors and many interfaces to other work may need more structure simply to keep everyone aligned.
A council service with two clocks
Consider a fictional council replacing the way households confirm their electoral registration details. The work includes a new online form and a revised printed form posted to every household. The online form is exactly the kind of deliverable that benefits from iteration: residents misread questions, accessibility issues surface only in testing, and wording improves with each round.
The project, though, has two clocks. The printed forms go out on a date the team cannot move; the online form behind them can change every week. The print run needs a procured supplier, approved wording, a proof sign-off and a mailing slot booked well ahead. Funding for the print and postage is fixed in the annual budget. The electoral services manager, whose approval is needed for any wording change, is only lightly available during the busiest months.
A sensible project manager here does not choose one label for the whole project. The printed route runs predictively, with a baseline, a procurement plan and firm milestones back-scheduled from the posting date. The online form runs adaptively, with fortnightly testing sessions and a small group of residents recruited early. The electoral services manager agrees a standing decision window each fortnight, and wording that must match across print and screen is frozen at the proof sign-off milestone. After that point, only the online-only content keeps evolving.
Now imagine a neighbouring council building a very similar online form, but with no printed route, a service owner who sits with the team, and funding for a persistent digital team. The product is nearly the same. The project is not, and an adaptive approach throughout is entirely reasonable there. Nobody chose differently because of taste; the conditions pointed in different directions.
When the conditions shift
Project characteristics are not fixed at initiation. A sponsor leaves and the replacement wants a firm scope before releasing the next tranche. A regulator introduces an evidence point. A key user group becomes more available once a pilot is live. Each of these changes the evidence the original approach was built on, and the approach may need to shift with it. That is why approach selection belongs within ongoing tailoring and is revisited at phase gates, major releases and moments when funding or governance changes.
In practice, this means recording why the approach was chosen, in terms of the specific project conditions that justified it. When a condition changes, the team can see immediately which parts of the approach rested on it. A decision log entry that says "adaptive, because requirements are uncertain" is far less useful than one that names the stakeholder access, the funding model and the fixed dates that made adaptive delivery workable.
For a PMP® candidate, the useful habit is to read scenario questions for these project-level clues. The current PMP Examination Content Outline includes recommending a development approach as part of planning, and states that predictive, adaptive and hybrid approaches run through all three exam domains, with roughly 40% of items representing predictive approaches and the remainder split between adaptive and hybrid. A scenario that mentions a fixed regulatory date, a sponsor who reviews monthly or a fixed-price supplier is telling you something about the project, and that information deserves as much weight as the description of the product. Building that reading habit is one of the judgement skills covered in our PMP® exam preparation course, where approach selection is practised against the conditions a scenario actually describes.
On a real project, the same discipline protects the team from choosing an approach it cannot live with. Before settling on predictive, adaptive or hybrid, list who will give feedback and when, which dates are external, how money arrives and what has already been committed. If the proposed approach depends on something that list cannot provide, change the approach or change the condition before work starts.
Interested in going further?
Choosing an approach from project conditions is a judgement that improves with deliberate practice on realistic scenarios. Structured PMP preparation gives you repeated opportunities to read those conditions and defend the approach you recommend.
The PMBOK® Guide Eighth Edition sets out the wider thinking on development approach selection that this article draws on.
Ad · Amazon affiliate link.
References
A067: How Your Organisation Limits or Enables Agile Delivery
A064: Choosing Predictive, Agile or Hybrid for a Real Project
A065: Choose the Approach Around the Deliverable
A057: How to Recognise Predictive, Agile and Hybrid PMP Scenarios
A080: Tailoring the Life Cycle and Development Approach
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
