Continuous Delivery vs Periodic Delivery

Most arguments about delivery cadence begin as arguments about capability. Once a team can deploy on demand, holding work back starts to feel like waste. Once a programme has organised itself around quarterly releases, delivering more often feels reckless. Both positions describe the delivering side of the handover, and the decision belongs on the other side of it.

Value is not created at the moment something is released. It is created when someone can use it, and the people who will use it have a finite capacity for absorbing change. The question that settles cadence is not how often the team can finish something, but how often the receiving organisation can take something on and turn it into a result worth having.

The short answer is this. Continuous delivery suits work where each increment can be used on arrival at very low cost to whoever receives it. Periodic delivery suits work where receiving a change is expensive enough that grouping several changes together is genuinely cheaper than handling them one at a time. And delivering once, at the end, remains correct where the thing being built has no useful intermediate form.

The cadence the work allows, and the cadence the business can absorb

It helps to separate two rhythms that are routinely treated as one. The first is production cadence: how frequently the team can complete something usable and hand it over. The second is adoption cadence: how frequently the receiving organisation can take it, learn it, test it, approve it and start relying on it.

Production cadence is largely within the project's control. Adoption cadence usually is not. It is set by retraining, internal communications, updated procedures, contractual notice periods, customer acceptance testing, safety or regulatory approval, planned downtime windows, seasonal trading freezes and the simple fact that operational staff have a day job. A team that ships fortnightly into an organisation that can only absorb change twice a year has not accelerated anything. It has built a queue.

This is consistent with Section 4.4 of The Standard for Project Management, which treats delivery cadence as a characteristic chosen alongside the life cycle, recognising that projects may deliver once, periodically, incrementally or continuously depending on what the context supports. Cadence is a design decision, not a by-product of how the team happens to work.

It is worth saying plainly that a single delivery at the end is not a failure of ambition. A structural steel frame, a regulatory submission, a plant shutdown and a certified aircraft modification have no partially useful state. Neither is periodic delivery a diluted form of adaptive working. A predictive programme handing over in planned stages has made a real cadence choice, and often a well-reasoned one.

Five questions that settle the cadence

When a team is genuinely undecided, these five questions usually resolve it faster than a methodology debate.

• Can the increment be used on its own? If the receiver cannot do anything with it until three more pieces arrive, delivering it early moves inventory rather than value.
• What does each handover cost the receiving side? Count the training, comms, documentation, testing, downtime and support load, not just the deployment.
• What does waiting cost? Value forgone, risk carried longer, a competitor moving first, a compliance date approaching. If waiting is cheap, frequency buys less than it appears to.
• Does feedback change what we build next? Where the next decision genuinely depends on watching real use, small frequent slices earn their overhead. Where the requirement is settled and externally fixed, they may not.
• How reversible is it? Change that can be withdrawn quietly supports a faster rhythm. Change that is hard to undo, such as a data migration or a physical installation, argues for fewer, better-prepared handovers.

Underneath all five sits one trade-off. Delivering frequently lowers the cost of being wrong and raises the total cost of handing over. Grouping work does the reverse. The right cadence is the one where those two costs are roughly balanced for this project, in this organisation, this year. That balance moves, which is why cadence deserves reviewing rather than fixing.

When delivery and release come apart

The most common resolution is not a compromise between the two rhythms. It is separating them.

A software team can complete, integrate and technically deploy work continuously while making it visible to users only at chosen moments. Physical delivery has its own version of the same idea: sectional completion, phased commissioning and staged handover all allow work to finish continuously while the receiving organisation takes possession at intervals it can manage. In both cases the team keeps the feedback, quality and risk benefits of a short cycle, and the business keeps a change rhythm it can survive.

Consider a retail programme replacing till software across three hundred and forty stores. The delivery team can release weekly and would prefer to. Each change that alters what staff do at the till, though, costs a briefing before opening, a heightened support window and a rewritten procedure card in every store. So the programme splits its cadence. Anything invisible at the counter, including reporting, pricing rules and back-office corrections, goes live continuously. Anything that changes the till workflow is grouped into four releases a year, positioned away from peak trading, with a firm freeze in the weeks before Christmas. That is not half a cadence. It is two deliberate cadences serving two different receivers, and it is a good example of what a hybrid delivery approach actually looks like in practice.

The same logic applies in reverse. A programme delivering into a regulated environment may be able to release continuously to an internal validation environment while the external release cadence is set entirely by the approval body. Naming which constraint owns which rhythm prevents a great deal of unproductive argument.

Cadence is a decision you revisit

Delivery cadence is often chosen once, early, when the least is known, and then defended for the rest of the project. Conditions move. An operations team that could absorb change quarterly in year one may be capable of monthly change by year two, once the supporting process has matured. A product that started with weekly releases may need to slow down as its user base grows and the cost of a mistake rises. Reviewing cadence at phase boundaries, or whenever the receiving side changes shape, costs very little and prevents a rhythm from outliving its reasoning.

For a PMP candidate, the useful thing to recognise is that cadence is treated as a delivery judgement rather than a methodology badge. The current Examination Content Outline includes assessing incremental delivery opportunities within its value-based delivery task, and predictive, adaptive and hybrid approaches run across all three exam domains rather than sitting in one. A scenario that mentions frequent releases is not automatically pointing at an adaptive answer, and a scenario with a fixed handover date is not automatically predictive. Reading cadence decisions quickly is a habit worth building, and it is one of the areas covered in Omega's PMP® Exam Preparation, where the reasoning is practised against realistic situations rather than labels.

On a live project, the practical test is simpler than any of this suggests. Ask the people who receive what you deliver how much change they can take in a month, and what each handover costs them in time they do not currently have. Their answer, set against what waiting costs the organisation, is the cadence. Everything else is a preference.

Andre Malowney

Interested in going further?

Cadence decisions look straightforward until a real project puts a capable delivery team on one side of the handover and a stretched operations team on the other. Structured preparation gives you a way of reasoning through that tension consistently, across predictive, adaptive and hybrid work.

Delivery cadence sits within the life-cycle and development-approach material in The Standard for Project Management, published with the PMBOK® Guide Eighth Edition.

Ad · Amazon affiliate link.

References

A068: What Delivery Cadence Really Means
A013: Value Delivery in Project Management: What It Means in Practice
A014: Intended Value vs Realised Value
A015: When Delivering the Scope Destroys the Value
A066: How Project Characteristics Shape the Delivery Approach

PMP and PMBOK are registered marks of the Project Management Institute, Inc.