Project delivery
Delivery approach selector
Five factors scored from minus two to two, one row per component rather than per project, with a leaning formula and columns for the dominant factor and the decision it produced.
What it is
The delivery approach question is usually asked at project level and answered as an allegiance. Scoring it per component turns it into an assessment of the work actually in front of you, and the answers differ across the pieces of one project, which is the whole reason projects end up hybrid.
Five factors carry most of the weight. Requirement stability, feedback availability, regulatory constraint, the cost of a wrong turn, and the practical realities of the team and environment. Each is scored towards predictive or towards adaptive, and the sheet sums them into a leaning.
The total is not a vote. What the sheet is for is finding the factor that dominates, because a single irreversible and heavily regulated component pulls an otherwise adaptive project towards documented baselines whatever the other columns say. The dominant factor column is the one somebody will read when they challenge the decision six months later.
When to use it
- A project is being pushed towards one approach for the whole of it to keep governance simple.
- Hardware with a long lead and software with emerging requirements sit in the same project.
- You need to justify a hybrid arrangement to somebody who thinks it means indecision.
- Uncertainty has fallen since initiation and the original choice may no longer fit.
The columns
- Component
- Requirement stability
- Feedback availability
- Regulatory constraint
- Cost of a wrong turn
- Team and environment
- Leaning
- Dominant factor
- Decision
The template
| Component | Requirement stability | Feedback availability | Regulatory constraint | Cost of a wrong turn | Team and environment | Leaning | Dominant factor | Decision |
|---|---|---|---|---|---|---|---|---|
| Data migration | 2 | 1 | 1 | 2 | 0 | Predictive | Cost of a wrong turn. A bad migration corrupts the historical record | Predictive, with a trial run before the production pass |
| Exception queue | -2 | -2 | 0 | -2 | -2 | Adaptive | Feedback availability. Supervisors sit in the building and use it daily | Adaptive, two week cycles |
| Regional configuration | -1 | -1 | 1 | 0 | -1 | Adaptive | None dominant, so the practical factors decide | Iterative, three passes with regional leads |
| Acquirer certification | 2 | 2 | 2 | 2 | 1 | Predictive | Regulatory constraint. The gate and its evidence are set by the acquirer | Predictive, fixed sequence to the booked slot |
| Reporting suite | 0 | -1 | 1 | -1 | -1 | Adaptive | Feedback availability, though weakly | Hybrid, baselined scope delivered in cycles |
| Decommissioning | 2 | 1 | 1 | 2 | 1 | Predictive | Cost of a wrong turn. Switching off the wrong thing is not reversible | Predictive |
The Leaning column is a formula summing the five scores. It is a prompt rather than a verdict, and the two columns after it are where the actual thinking is recorded.
How to score
Each factor runs from -2 to 2. Negative points towards adaptive, positive towards predictive, zero means it does not discriminate here.
- Requirement stability. Positive when the outcome is known and unlikely to move, so defining it costs less than discovering it. Negative when nobody can describe good until they have seen something, which makes early definition a guess written down in an authoritative font.
- Feedback availability. Positive when users are reachable only at gates months apart, or the thing cannot be judged until finished. Negative when a usable increment can go in front of somebody able to react to it every few weeks.
- Regulatory constraint. Positive when traceability, evidence of design and staged approval are demanded, or a fixed price is signed. Negative when the regulator sets the outcome and leaves the route open.
- Cost of a wrong turn. Positive when a mistake is expensive, irreversible or dangerous, so analysis is cheap beside it. Negative when a mistake is cheap to undo and building is the fastest way to find out.
- Team and environment. Positive for large, distributed or contracted teams with release infrastructure still to be built. Negative for a small team working closely with the tooling to release whenever it wants.
One row per component, not per project
This is the point of the sheet. The factors give different answers for different parts of one project, and that difference is the whole reason a project ends up hybrid.
Deciding once for everything forces the components with least uncertainty to carry ceremony they do not need, or leaves the components with most of it running without the control they do need. Splitting the decision costs an integration plan and a shared view of dependencies, and that is work worth doing.
Find the dominant factor
One row pointing one way is rarely the whole answer, and the total is not a vote. What the sheet is for is finding the factor that dominates.
A single irreversible and heavily regulated component pulls an otherwise adaptive project towards documented baselines whatever the other columns say. The Dominant factor column is where you name that, and it is the column somebody will actually read when they challenge the decision in six months.
Where nothing dominates, say so. The practical factors then decide, and recording that is more honest than manufacturing a principled reason.
The decision column can say hybrid
The range runs predictive, iterative, incremental, adaptive, and hybrid draws from both ends at once. Reporting suite above scores mildly adaptive and lands on a hybrid arrangement, because the scope is contracted and the route to delivering it is not.
Whatever the decision, the seam is what needs designing next. What crosses the boundary between this component and its neighbours, in which direction, how often, and what each side has to be able to promise the other.
Revisit as evidence arrives
An approach selected at initiation was selected with the least information anybody will ever have. Rescore at phase boundaries. Uncertainty falls as work proceeds, and a component needing short cycles at the start may be well enough understood by the second phase to be planned out.
Record the rescore rather than overwriting it. The change in a factor over time is itself worth knowing, and it is the evidence behind the tailoring decision record.
Questions people ask
- Can one project really run three approaches?
- Yes, and most large ones already do informally. The cost is an integration plan and a shared view of dependencies, which is work worth doing compared with forcing low uncertainty components to carry ceremony they do not need.
- What if the score comes out near zero?
- Then nothing dominates and the practical factors decide. Recording that is more honest than manufacturing a principled reason, and it usually points at a hybrid arrangement.
- How often should it be rescored?
- At phase boundaries. An approach selected at initiation was selected with the least information anybody will ever have, and uncertainty falls as work proceeds.