6.4 Pace, Multimodal Delivery & Landing Points
Key Takeaways
- Pace is the rate at which change is introduced, and it is constrained by organizational capacity (how much change can be absorbed) and organizational ability (how well the organization can absorb it).
- A landing point is the stable operating state the organization reaches at the end of a tranche — a point at which business as usual can run safely and benefits can begin to be measured.
- Incremental progression means moving towards the target operating model through a series of landing points rather than a single transition.
- Multimodal delivery means combining linear, iterative, hybrid, and continual improvement lifecycles across the projects and other work within one programme.
- The delivery approach selects the mode for each piece of work based on requirement stability, risk, regulatory constraint, and the ability of operations to absorb frequent change.
6.4 Pace, Multimodal Delivery & Landing Points
[!NOTE] A vocabulary-dense section: Several of the terms below are defined in the MSP glossary and are examined at recall level. Learn the distinctions precisely — particularly capacity versus ability, and tranche versus landing point.
Pace, Organizational Capacity, and Organizational Ability
Pace is the rate at which a programme introduces change into the organization. Pace is a governed choice, not a by-product of how fast projects happen to finish: the programme board decides how quickly the business will be asked to absorb new ways of working.
Two distinct constraints bound the achievable pace, and the exam frequently tests the difference:
- Organizational capacity — the amount of change the organization can take on at a given time, alongside continuing to run business as usual. Capacity is a question of volume: available management attention, staff time not already committed, budget, and operational headroom.
- Organizational ability — how well the organization can absorb and sustain change: its skills, change maturity, prior experience, leadership strength, and cultural readiness.
An organization can have plenty of capacity and poor ability (lots of spare staff time but no experience of transformation), or high ability and no capacity (a very capable team already fully committed to three other programmes). Both must be assessed, and the lower of the two sets the ceiling.
| Concept | Question it answers | Typical evidence | If ignored |
|---|---|---|---|
| Pace | How fast are we asking the business to change? | Tranche lengths, cutover frequency, training load | Change fatigue, rejection, benefit erosion |
| Organizational capacity | How much change can be absorbed right now? | Committed headcount, budget, concurrent initiatives | Overload, missed operational targets |
| Organizational ability | How well can change be absorbed and sustained? | Change maturity, skills, previous programme outcomes | Adoption stalls after go-live |
Tranches, Landing Points, and Incremental Progression
A tranche is a structured grouping of projects and other work that delivers a step change in capability. Tranches are separated by governed review boundaries at which the programme's continuing justification is confirmed before further investment is committed.
A landing point is the stable operating state the organization occupies at the end of a tranche. The distinction matters: the tranche is the work; the landing point is the state you are standing in when that work stops. A properly designed landing point means:
- Business as usual can run safely and indefinitely from that state, even if the programme were stopped there.
- Some benefits can be measured, because outcomes have actually been achieved rather than merely enabled.
- The organization has a coherent operating model — not a half-migrated one where two incompatible processes run side by side without a plan.
Incremental progression is the resulting pattern: the organization advances towards the target operating model through a series of landing points rather than a single large transition. Each landing point is an intermediate state of the target operating model.
CURRENT STATE TARGET STATE
│ │
▼ ▼
┌────────┐ Tranche 1 ┌──────────┐ Tranche 2 ┌──────────┐ Tranche 3 ┌────────┐
│ AS-IS │ ────────────► │ LANDING │ ────────────► │ LANDING │ ────────────► │ TO-BE │
│ │ │ POINT 1 │ │ POINT 2 │ │ │
└────────┘ └──────────┘ └──────────┘ └────────┘
stable BAU + stable BAU +
first benefits more benefits
▲ ▲
tranche review tranche review
(continue / adapt / stop)
[!TIP] Exam tip: If a scenario says a programme reached the end of a tranche but operations cannot function without the next tranche also completing, the programme has not designed a genuine landing point.
Multimodal Delivery
Multimodal delivery is the use of more than one delivery lifecycle within a single programme. MSP does not require every project to be run the same way; it requires the delivery approach to state which mode is used where, and why.
| Mode | How it works | Best suited to | Watch out for |
|---|---|---|---|
| Linear project lifecycle | Requirements are defined up front and delivered in sequenced phases with a single major handover | Physical construction, regulated plant, work with fixed statutory specifications | Late discovery of wrong requirements; little room to adapt |
| Iterative project lifecycle | Work is delivered in repeated increments, with requirements refined from feedback each cycle | Digital products, service design, anything with uncertain user needs | Operations being asked to absorb change too frequently |
| Hybrid project lifecycle | Different parts of the same project use different modes — for example iterative software on a linear infrastructure programme | Most large transformations | Interface and integration points between the modes |
| Continual improvement | Ongoing incremental refinement of an existing capability rather than a bounded project | Embedding and optimizing after a capability lands | Being treated as a substitute for a genuine transformation |
Continual improvement deserves particular attention: in MSP it is a mode of work in its own right, typically running inside business operations after a capability has been adopted, and it is one of the mechanisms by which benefits keep growing after a tranche closes.
Choosing the mode
The delivery approach records the selection criteria. In practice the choice turns on four questions:
- How stable are the requirements? Stable and externally fixed points towards linear; emergent points towards iterative.
- Where is the risk concentrated? If the biggest risk is "we do not know what users need", iterate. If it is "the plant must be certified before it can operate", sequence it.
- What does the regulatory or contractual environment permit? Some safety and public-procurement regimes require defined specifications before build.
- What can operations absorb? Iterative delivery generates frequent change; if organizational capacity or ability is low, the programme may deliberately batch releases into fewer, larger landing points.
[!CAUTION] Common trap — mode is not maturity: A distractor may imply that iterative delivery is inherently more advanced, or that linear delivery is obsolete. MSP is explicitly neutral: the correct mode is the one that fits the work, its risk profile, and the organization's ability to absorb change.
Bringing It Together
Pace, landing points, and delivery mode are a single design decision, not three separate ones. A programme that selects iterative delivery for every project but has low organizational ability will produce a stream of releases that nobody adopts — outputs without outcomes. A programme that selects linear delivery for a genuinely uncertain digital service will reach its first landing point having built the wrong thing at scale.
The Structure theme therefore requires the programme to state, in the delivery approach and the delivery plan together: what the tranches are, what state the organization will be standing in at the end of each one, how fast change is being introduced, and which delivery mode each piece of work uses.
A hospital trust has budget and spare staff hours available for a transformation, but has never run a change programme before and has no trained change practitioners. Which constraint on pace does this describe?
A programme completes its first tranche. Operations can run indefinitely in the resulting configuration, and the first two benefits can now be measured. What does this stable state represent?
Within one programme, a new depot is being built to a fixed specification while a customer-facing app is being developed in repeated increments with user feedback. Which MSP concept does this illustrate?