PMI-ACP Delivery: Flow, Quality, and Continuous Improvement

What the Delivery domain covers

Delivery accounts for 28% of items under the March 2026 PMI-ACP outline. Its tasks include seeking early feedback, managing agile metrics, managing impediments and risk, recognizing and eliminating waste, performing continuous improvement, actively engaging customers, and optimizing flow. The domain tests whether practitioners can help work move toward useful outcomes while maintaining quality and learning from evidence.

Delivery is not simply the count of features completed. A team may finish many tasks but deliver little customer value if work waits for review, fails acceptance, or solves the wrong problem. The practitioner should understand the path from idea to usable outcome and notice where work, information, or decisions get stuck.

Seek early feedback through small increments

Early feedback helps teams evaluate customer satisfaction and adapt while work remains changeable. Delivering small increments shortens the time between investment and learning. Stakeholders should be engaged regularly, and their feedback should be considered alongside product priorities, quality, and constraints.

A product team building a new claims process can demonstrate one complete, useful step to claims staff before implementing every screen. Staff can reveal that a required document is missing or that the sequence causes confusion. A static progress demo may show activity, but a usable increment or realistic prototype provides stronger evidence about whether the workflow works.

Early feedback does not mean releasing unfinished work to production. The team should meet its definition of done, acceptance criteria, security needs, and applicable regulations. A controlled prototype or pilot can test learning safely. Make clear whether feedback comes from a simulation, a limited user group, or broad production use because each supports different conclusions.

Choose and interpret agile metrics

The outline asks practitioners to select metrics for an audience, radiate them appropriately, review and analyze them, and use insights for decisions. Metrics are useful when they answer a question. Cycle time may help a team understand how long an item takes after work begins. Throughput shows how many items finish in a period. Work in progress indicates active or waiting work. Customer satisfaction or task success can speak to outcomes.

No metric tells the entire story. Velocity can support iteration planning for a stable team, but it is not a universal productivity measure. A rising completion count may reflect smaller work items rather than increased value. A burnup chart can show scope and completion trends, but a late increase in scope may make the original target misleading. Cumulative flow can reveal a growing queue, but the team still has to investigate the cause.

Metrics should not be used to rank individuals or pressure teams to hide difficult work. That distorts the data and discourages transparency. Explain definitions and limits, choose a measure that fits the decision, and review it with people who can act. An executive may need an outcome trend, while a team may need a more detailed flow measure. Share only the detail each audience needs and protect sensitive information.

Manage risks and impediments

A risk is a potential future event or condition that may affect objectives. An impediment is an obstacle already interfering with progress. The tasks often overlap in response: identify issues early, involve the team in choosing what to do, prioritize mitigation or removal, monitor the result, and use lessons to prevent recurrence.

A team may use a risk-adjusted backlog, risk burn-down view, or a technical spike to learn about uncertainty. A spike should have a bounded question and a decision that follows its result. If the risk concerns a legal obligation or patient safety, a small experiment still needs proper safeguards and authority. Agile delivery does not permit bypassing a required control.

Suppose a third-party interface has changed twice without notice and now blocks a release. A useful response is to make the dependency and impact visible, coordinate with the provider or responsible team, and work with the delivery team on a mitigation such as contract testing or a temporary fallback if authorized. Merely asking developers to work overtime does not remove the dependency. A durable improvement should also reduce the chance of the same surprise recurring.

See waste across the whole flow

Waste is work or delay that does not contribute enough value to justify its cost. It may include waiting, unnecessary handoffs, partially finished items, duplicated approvals, unused features, or repeated rework. Value stream mapping can show the steps and queues between a request and a usable result. Use evidence and team feedback to identify where to improve.

A local optimization can worsen end-to-end flow. A development team that starts more work may appear busy but fill the testing queue. A specialist who approves every change may become a bottleneck. Map the path, locate the waiting, and ask which constraint has the greatest effect on completion and quality. Then select an improvement that addresses the system rather than telling people to move faster.

Prioritize waste reduction rather than trying to fix every inefficiency at once. A small policy change or cross-training effort can test whether the bottleneck improves. Review the data after the change. If a new queue appears elsewhere, adjust again. Continuous improvement is iterative and evidence-based.

Optimize flow and work in progress

The outline includes limiting work in progress at all levels, shielding the team from interruptions, and using metrics to analyze and improve flow. Work in progress includes items started but not completed. When many tasks are open at once, attention is divided and queues grow. Limiting WIP encourages finishing and makes bottlenecks easier to see.

A WIP limit is a policy the team uses to manage its actual system. It should reflect capacity and workflow, then be inspected as the system changes. A limit that is too high does little to reduce overload. A limit that is too low without considering blocked work or skill constraints may leave capacity unused. The team should discuss what happens when a limit is reached and how it will swarm on blocked work.

Shielding a team from interruptions does not mean ignoring urgent incidents or stakeholders. It means creating a clear intake or escalation path so random requests do not continually disrupt planned work. An urgent production problem may enter through an agreed policy; a routine request can be evaluated in the backlog. The team and product decision-maker can make trade-offs visible instead of absorbing hidden work.

Perform continuous improvement

Continuous improvement uses metrics and feedback to identify an issue, implement an action, and evaluate whether it helped. A retrospective might produce a proposal to add a review pairing step. The team should test the practice, measure its effect on defects or waiting, and decide whether to retain or adapt it. Recording an action without checking its impact does not close the improvement loop.

A Five Whys discussion, fishbone diagram, control chart, or value stream map can help the team investigate. Choose a tool suited to the question and the evidence. If the data show several contributing factors, resist the urge to announce one root cause prematurely. Improvements can also have side effects: increasing review depth may improve quality but lengthen cycle time, so the team should inspect both.

Actively engage customers

Customer engagement includes identifying and analyzing customers and their needs, validating iteration deliverables against acceptance criteria, and encouraging collaboration between customer and team. The customer may be an end user, buyer, internal department, or a representative who understands the intended outcome. The role and evidence should be clear so the team is not using a convenient proxy who cannot speak for the affected users.

Acceptance criteria state observable conditions for an item. They help the team and customer agree on what a deliverable should do. They are not a complete substitute for conversation. A change may satisfy criteria yet fail to improve the broader outcome, which is why the team also needs feedback and value measures. Conversely, vague acceptance expectations create disputes late in delivery.

Regular contact helps clarify priorities before the team completes a large batch. If a customer is unavailable, the practitioner can identify a suitable representative, schedule a review, and record assumptions so they can be checked. A stakeholder who cannot attend every ceremony can still provide meaningful feedback at planned decision points.

Work through a delivery scenario

A team’s cumulative flow diagram shows a widening testing column. Developers finish work regularly, but completed items wait several days for testing. A manager suggests increasing the sprint commitment so more work is ready. The evidence indicates a test-stage bottleneck. A stronger response is to make the queue visible, inspect why testing is constrained, and work with the team to limit new starts or improve the bottleneck. The team can then track cycle time and quality to see whether the change helps.

Starting more work adds to the queue. Ranking testers by item count could encourage fast but shallow checks. Estimating a more optimistic release date ignores the trend. A cross-skilled team member might help with test work if the person has appropriate competence, but the team should not treat cross-skilling as automatic permission to waive quality standards.

Prepare for Delivery questions

For a delivery scenario, identify where the work sits in the value stream, what the metrics actually measure, and whether the question concerns a future risk or a current impediment. Determine who should be involved in the response. Choose an action that addresses the constraint while preserving quality and feedback. If an exhibit includes data, compare periods and units and avoid assuming a cause the chart does not establish.

Practice explaining what a metric can and cannot tell you. A queue suggests a bottleneck but not necessarily why it formed. Falling throughput may reflect more complex work, a new dependency, or missing capacity. The team should investigate and select a response with the people closest to the work. That reasoning is more useful than memorizing a chart label.