PMI-ACP Recognize and Eliminate Waste: Value Stream Mapping, Flow Efficiency and the Seven Wastes

Recognizing and eliminating waste means finding the effort and the waiting in a delivery process that do not help the customer, and removing them step by step so that value reaches the customer sooner. In lean thinking, waste is anything that consumes time, money or attention without adding something the customer would want to pay for. The PMI-ACP Examination Content Outline makes it Task 4 of the Delivery domain, whose description includes "eliminating waste by focusing on delivering value to the customer". The task has four enablers:

1. Visualize the end-to-end flow of value in the system (e.g., value added, non-value added).
2. Use metrics, tools and feedback loops to identify waste.
3. Prioritize waste reduction activities.
4. Iterate on identification and reduction of waste.

The order matters. You first make the whole flow visible, then use data to find where waste sits, then choose which waste to tackle first, then change one thing, measure, and look again. Removing whatever looks wasteful without that evidence is the habit this task is meant to replace.

Neighbouring tasks cover related ground: root-cause techniques such as Five Whys and fishbone diagrams belong to Facilitate problem resolution in the Leadership domain; retrospectives and the improvement cycle to Perform continuous improvements; WIP limits, task switching and protecting the team's focus to Optimize flow; reading Kanban boards and cumulative flow diagrams to Visualize work; gold plating and maximizing the value of each increment to Manage value delivery; and choosing and radiating metrics to Manage agile metrics.

A value stream map is a picture of every step a piece of work goes through from the moment a customer request arrives to the moment the change is in use, showing for each step how long work is actively done on it (process time) and how long it waits before or after it (wait or queue time). It is the main tool for the first enabler, because it shows the whole system rather than one team's part of it.

Where the map starts and ends

The boundaries follow the customer, not the organization chart: the map starts where the customer's need enters the system and ends where the customer is using the result. Much of the waste hides outside any one team's activities, upstream (intake, funding, waiting to be prioritized) and downstream (release, rollout, acceptance). A map bounded by the team's own activities understates lead time and leaves out the very waits that usually matter most.

How to build the current-state map

• Map what actually happens. Trace real work items through every step and use their real dates. The intended process and the real one almost always differ: the real one has workarounds, rework loops and queues that nobody wrote down.
• Build it with the people who do the work. Each step's owners know where items wait and why. In an insurance claims flow, for example, that means people from claims intake, assessment, fraud checks and payments in the same room. Building the map together also gives them shared ownership of what it reveals.
• Cover the whole flow from the start. When work crosses groups, the delay usually sits between them, in the queues where one group's output waits for the next. A partial map cannot show those queues.
• Record work time and wait time separately for every step, then add them up into total lead time.

Value stream map versus other visual tools

Each step on a value stream map is classified from the customer's point of view: would the customer willingly pay for this step if they could see it? That gives three categories.

Three distinctions matter:

• Required is not the same as value-added. A mandatory step stays non-value-added from the customer's point of view; it is necessary non-value-added. Calling it value-added because it is mandatory hides the waste around it, which is usually its waiting time.
• A document is not automatically waste. Classification depends on value to the customer, not on the form of the artefact. A user guide that a hospital client ordered for its ward staff is value-added; an internal specification nobody opens is not. The agile preference for working software over comprehensive documentation is a preference, not a rule that documents are waste.
• Rework is waste even though it feels productive. Fixing defects after release is real work, but the customer would not pay twice for the same capability, so lean treats it as waste (the defects waste).

Process cycle efficiency (also called flow efficiency) is the share of total lead time in which value is actually being added:

Process cycle efficiency = value-added time ÷ total lead time

Strictly, Lean Six Sigma counts only value-added effort in the numerator, so effort on necessary non-value-added steps would be left out. In agile practice, and in Kanban's flow efficiency, the numerator is usually simply active work time, and that is the convention used here. The denominator is always the whole lead time, work plus wait.

For example, if a change took 60 working days from request to release and people actively worked on it for 12 of them, efficiency is 12 ÷ 60 = 20%.

How changes move the figure

• Cutting wait time shortens lead time while work time stays the same, so efficiency rises. Removing 15 days of waiting from that stream takes it from 12 ÷ 60 (20%) to 12 ÷ 45 (about 27%).
• Cutting work time shortens lead time too, but it also shrinks the numerator, so efficiency usually falls. Removing 6 days of work from the same stream gives 6 ÷ 54, about 11%, even though lead time fell by 6 days.
• When comparing options, compute each one. The option that removes the most waiting usually wins on efficiency, while the option that removes the most total days wins on lead time.

In knowledge work, efficiency figures are often low because most of the lead time is waiting. A low number is not a judgement on the team; it shows where improvement is possible.

In most knowledge-work processes, most of the lead time is waiting: for a decision, an environment, a specialist group's queue or a release. Speeding up the work itself therefore changes lead time very little. If a change takes 50 days and is worked on for 10 of them, making all the work 30% faster saves 3 days, 6% of lead time; the 40 days of waiting are where the time goes.

The practical rule: look for the biggest waits first, and shorten queues before buying faster tools or adding people to the work. A change that shortens a wait while keeping the step's purpose is a gain; a change that saves time by dropping the purpose of a step is not waste reduction.

Shared specialist queues

When a shared group (security, data, architecture, legal) spends a short time on an item that then waits days in its queue, the queue is the waste. Judge every proposal by whether it reduces the total waiting in the system or only moves it. Changes that reorder the queue or change how requests arrive leave the total wait the same, or add to it. Changes that reduce how much work needs the queue at all, such as self-service tooling, pre-approved standard patterns, or cross-skilling team members to handle routine cases within the specialists' rules, shorten it for every team that uses it. The specialists' time then goes to the work that genuinely needs them.

Lean software development (Mary and Tom Poppendieck) translated the lean manufacturing wastes into seven wastes of software development. Recognizing each from its symptoms is what the exam asks, so the table pairs each waste with what it looks like.

The list changed between the Poppendiecks' books. The 2003 version (Lean Software Development: An Agile Toolkit) named extra processes and motion where the 2006 version (Implementing Lean Software Development) has relearning and handoffs, and it called delays "waiting". Extra processes, meaning paperwork, reports and approvals that add nothing, is still treated as a waste in practice.

Real scenarios often show several wastes at once. Name the waste that the described symptom itself shows: an inventory of unfinished work is partially done work whatever caused it, and time spent rediscovering something known is relearning whatever made the rediscovery necessary. Do not name a waste the scenario gives no evidence of.

Handoff waste is reduced by collaboration, not by better handoffs. Every time work passes from one specialist to the next, part of the intent behind it is lost, and the loss shows up later as rework and long clarification threads. Measures that make the handoff more formal or more detailed keep the transfer and usually add effort or delay. What removes the waste is people from the different roles working on each item together, or involving the downstream role while the upstream work is still being shaped. This holds even when specialists must stay in their own department: they can still work alongside the team on each item instead of passing finished work across. Working a stage ahead of the team keeps the complete handoff, so problems still surface only after the upstream work is finished.

Relearning waste is reduced by keeping knowledge where it will be found (for example short decision records kept beside the code, or tests that document behaviour) and by shortening feedback, so people learn the result of their work while it is still fresh.

Extra processes: confirm with the consumers before removing

Reports, approvals, logging and documents that nobody uses are waste, but someone usually created them for a reason, and some still meet a real need. Three principles guide the agile response:

1. Find out who uses the output and for what. Talk to the people who receive it before changing it. The answer often shows that only a small part is used, and that part can be kept.
2. Make the cost and the outcome visible to the owners, and redesign with them. A control was usually created after a real problem. Data on what the control costs (the days it adds) and what it achieves (how often it changes anything) lets its owners decide how to meet the same need more cheaply. Changing someone else's control without them damages trust and may remove a protection that is still needed.
3. Keep the real need at the lightest level that meets it. When a process exists for one consumer with a narrow need, such as a compliance team, an auditor or finance, agree with that consumer the least detailed, least frequent record that still satisfies it, rather than keeping the full process or dropping it.

Metrics and feedback loops identify waste by showing where time is lost and where work has to be redone. The useful ones describe the flow, not the people.

Metrics that expose waste

• Time per state. If the tool records when items enter and leave each column, split cycle time by state and label each state as working or waiting. This shows where items sit without anyone adding value.
• Hidden waiting inside working states. A blocked item still sits in its "in progress" column, so counting all time in working columns as active work overstates flow efficiency. Recording when items are blocked, and making queues explicit on the board (for example a "done, waiting for the next step" sub-column within an activity), turns that hidden wait into measured wait.
• Rework share. The share of completed items that fix escaped defects, and the share of work sent back at review, show how much capacity goes into redoing work. Compare the size of each waste in the data before acting: the largest loss is the first target, not the loudest complaint.
• Usage data, for the extra-features waste (below).

Velocity, estimate accuracy, utilization and per-person output describe throughput, predictability or individuals. They do not show where work waits, and measuring individuals pushes attention away from the flow.

Feedback loops as waste detectors

Every feedback loop (customer review, user testing, automated tests, code review) can expose waste, and the longer the loop, the more work is wasted before it is caught. The ways to shorten one:

• Bring the person who judges the work into the loop while it is still in progress, so a misunderstanding costs hours rather than an iteration. More internal checking or more written detail does not help when the misunderstanding is about what the customer wants.
• Put small working increments in front of real users early and often. Written agreement records assumptions without testing them; feedback that arrives only at the end comes after the waste.
• Split slow automated checks so the fastest, most informative ones run on every change and the slower ones run less often, giving developers a result while they still remember the change.

Sizing the extra-features waste

To know how much effort went into features customers do not use, combine usage analytics (what customers do) with customer conversations (why, and what they depend on). Measures of the team's own effort do not show customer use, and low defect counts are ambiguous because an unused feature also generates few reports. Low usage is not the same as low value: a rarely used capability may be critical to a few important customers or to a contractual or legal obligation, so confirm with the people who use it before removing it.

A mapping session usually finds more waste than a team can remove at once, so the team ranks it by effect on lead time or customer value against the effort and time each fix needs to pay off. Criteria that are easy to rank by but say nothing about the size of the delay or the lost value are not a basis for the order.

Time to benefit matters when the goal has a deadline. A fix that will pay off only after the deadline contributes nothing towards it. Suppose a claims team must cut lead time within six weeks: one option would remove 4 days per claim but needs ten weeks to build, another removes 2 days per claim and is ready in one week. Only the second helps within the window, even though the first is bigger in the long run, so the team may do the second now and start the first in parallel. Estimate the days saved per item, times the items that will flow through before the deadline.

Optimize the whole, not the parts

The Poppendiecks' principle of optimizing the whole means judging every change by end-to-end lead time, not by how efficient one step looks. Local efficiency can create waste elsewhere:

• High utilization builds queues. Queueing theory (Reinertsen) shows that as a step's utilization approaches 100%, the queue in front of it grows sharply. A step that is always busy may well be the constraint. Capacity helps only at the constraint, so the useful move is to bring help to that step (for example people from other steps pitching in) and to stop pushing more work into its queue.
• Batching trades one cost for another. Larger batches lower the effort per item (transaction cost) but make each item wait longer (delay cost). A batching decision that looks efficient for the specialist group can lengthen lead time for everyone. Make both costs visible with flow data and redesign the step together with the group that owns it.
• A faster step does not mean faster delivery. If one step speeds up but end-to-end lead time does not move, that step was not the constraint. Look at the whole flow again to find where the work now waits.

Necessary non-value-added steps

A step required by regulation, audit or contract stays, so the waste to remove is its effort and, above all, its wait. Work with the step's owners on that: for example scheduled review slots, involving the reviewer earlier, smaller and more frequent reviews, or automated evidence gathering. Its purpose is kept and its delay shrinks.

Waste reduction is a loop, not a project. After the current-state map, the team draws a future-state map showing how the flow should look, and treats it as a direction rather than a plan to execute all at once:

1. Pick the change with the best expected effect for its cost.
2. Make one change at a time and measure lead time, so cause and effect stay visible and the team learns quickly what works.
3. Update the map with new data. Removing one wait often moves the queue to the next constraint.
4. Examine the new constraint with the people who own it, then repeat.

A gain that seems to vanish usually has not. If lead time barely moves after a wait is removed, check where work now waits: the constraint has moved, and the earlier gain is what exposed the next queue. Inspect that queue with its owners before deciding on a fix. The map is a living tool: it is updated whenever the flow changes, not drawn once and filed. The broader cycle of retrospectives and improvement experiments is covered in Perform continuous improvements.