When product delivery falls behind

Rescue starts with a decision

A failing enterprise product deployment is one where the expected outcome, delivery evidence and current plan no longer agree. Warning signs include missed releases, rising defects, ageing work, unresolved dependencies or sponsors unable to explain what comes next. One late milestone is not proof; a repeated gap between forecast and progress requires intervention.

First establish whether the work can still produce enough value to justify its cost and risk. Start with a shared account of what is working, what is blocked and which decision leadership needs to make, rather than another set of dates.

Build a fact base before changing the plan

In the first ten working days, review the product, delivery system, commercial commitments and operational exposure. Speak to the delivery team and sponsors. Compare plans with backlog, release, incident, user research, testing, architecture and supplier evidence.

Audit flow, not just estimates

Look at cycle time, deployment frequency where meaningful, work in progress, ageing work, blocked time, rework and change failure. These reveal different constraints. A team may complete tasks while the priority journey remains unfinished, or report high sprint velocity while releases wait for security approval.

Do not compare story points across squads. Estimates support local planning, not business measurement. Pair delivery data with product evidence: can a user complete the task, does the data arrive, and can operations support the release?

Classify the constraint

Separate symptoms from causes. Delays may stem from unclear decisions, unstable requirements, fragile integrations, manual environments, unavailable data or missing assurance routes. Adding developers to unresolved decisions increases coordination without throughput.

Map the path from user need to supported release. Record ownership and waiting time at each transition. The Government Digital and Data Playbook recommends measuring agile progress against outcomes: each increment should advance an agreed result, not just record activity.

Reset the outcome and scope

With the fact base agreed, decide what must be preserved and what can change. State the business outcome, the user group, the minimum usable release and the risks that cannot be accepted. Identify work that can be deferred, removed or delivered in a later increment. Keep controls for security, data handling, accessibility and operational readiness visible in the scope decision.

Write this reset as a short recovery brief. Record the baseline, the next usable outcome, the three main constraints, each constraint owner and the evidence that will trigger a further investment decision. This gives executives a direct view of what changed and gives the team a stable reference when new requests arrive. Keep the brief current as evidence changes; it is a decision record, not a new business case.

Do not hide quality work under a “minimum viable product” label. A viable release must be safe, observable in production and supportable. If not, narrow the user group or feature set.

Re-form the delivery group

Recovery needs the skills to resolve the constraints, not only roles from the original statement of work. Bring product, design, engineering, data, testing, operations and commercial decision-makers into one delivery rhythm. Name a person who can prioritise and give the group a route to executives for decisions outside its authority.

Keep the team small enough to coordinate without losing essential review or expertise. Agree a weekly demonstration and decision log. Use risk reviews to clear dependencies, not add status meetings. Suppliers and internal teams need one backlog, explicit ownership and a route to raise scope changes.

Recover in stages

Set a short recovery horizon of one or two delivery cycles with an exit test. The first increment should prove the riskiest element: a data integration, user task, deployment mechanism or production control. It should produce evidence, not another completion estimate.

At each review, compare flow and product quality with the baseline. If the constraint moves, update the plan. If the approach cannot meet the outcome within acceptable cost or risk, escalate a stop, pause or re-scope decision. Recovery does not mean automatic continuation.

For longer programmes, use 30-day checkpoints to assess risk reduction, smaller releases and learning from real use. As dependencies are removed, document system ownership, deployment steps, data definitions and runbooks. A release understood only by the rescue team is not sustainable.

Make the commercial path workable

Review decisions, approvals and scope changes under the agreement. Define acceptance evidence, change authority and knowledge transfer. Adjustments must fit the contract and procurement controls; do not assume an informal reset.

Further reading

• GOV.UK: Digital, Data and Technology Playbook
• Google Cloud DORA: Software delivery performance

Recovery restores the organisation’s ability to make informed decisions. That may mean a smaller release or stopping the approach before more investment is committed. If your programme is missing outcomes and the delay is unclear, contact Naqib and Jas to discuss a delivery and engineering baseline.