Reduce Delays in an Existing Service by Making the Work Visible

## Start from How the Service Works Today, from Request to Delivery Treat flow management as an improvement layer for an existing service, not as a reason to replace every role, process, or tool. Begin with what people actually do today, including informal handoffs and exceptions. Define the service from request to accepted delivery. Identify its customers, the outcomes they expect, the people who provide the service, and the work that contributes to delivery. Describe current sources of dissatisfaction without assigning blame. Look for delayed requests, unpredictable completion, rework, conflicting priorities, overloaded stages, and unmet expectations. Agree to improve through small changes that can be observed and revised. Encourage leadership from anyone who can expose a problem, coordinate help, or test a better policy. Before redesigning the service, confirm: - Which customer request starts the service. - What event counts as accepted delivery. - Which activities and dependencies belong inside the boundary. - Which existing practices should remain until evidence supports a change. ## Study Incoming Requests, Past Delivery Times, and Where Work Waits Study incoming demand before designing controls. Group requests that behave similarly, record their frequency and urgency, and distinguish valuable demand from avoidable work caused by defects, unclear inputs, or previous failures. Use historical evidence to understand capability. Examine how much work completes, how long requests take, where work waits, and how much work remains active at each stage. Map the workflow as it operates, including queues, reviews, dependencies, parallel activities, commitment, and delivery. Do not substitute the official procedure for observed reality when the two differ. Bring representatives from the relevant roles into the design. A workflow model built by one role alone is likely to omit constraints, customer expectations, or operational knowledge. The initial model should answer: - What kinds of requests enter the service? - Where is each request evaluated and committed? - Which activities change or validate the work? - Where can work become blocked or delayed? - What evidence describes present performance? ## Show Active Work and the Rules for Moving It in One Shared View Create a shared view that represents the current workflow from request to delivery. Show each active item, its type, current activity, important risks, and whether it is blocked. Represent sequential activities as ordered stages. Show parallel work, special handling, or separate work types only when the distinction helps people make a decision. Place operating rules near the point where they apply. Include entry and completion criteria, priority rules, capacity limits, commitment rules, and the conditions for moving work. Keep policies few, clear, and testable. Everyone affected should be able to explain what a rule means, apply it consistently, and propose a change when it no longer improves outcomes. Review the visual model when: - Work regularly follows a path that is not represented. - People interpret the same status or policy differently. - Hidden queues or dependencies appear. - A visual detail adds maintenance cost without aiding decisions. ## Limit Work in Progress and Start New Work Only When There Is Room Set explicit limits on active work for the whole service or for constrained stages. A limit should protect flow and focus; it is not a target that must always be filled. Start new work only when demand exists and downstream capacity is available. The available space is the signal to select the next eligible item. When a limit is reached, stop adding work to that area. Help complete or unblock existing items, investigate the constraint, or revise the policy using evidence. Preserve some capacity for variability, coordination, learning, and recovery. Optimizing every person for full utilization usually increases queues, task switching, and delivery uncertainty. During replenishment: - Verify that candidate work meets the readiness criteria. - Compare urgency, value, risk, dependencies, and cost of delay. - Select only as much work as current capacity can support. - Record why exceptional treatment is justified. - Reject or defer options that should not enter delivery. ## Mark Blocked Work Quickly and Keep Rush Requests Rare Focus daily coordination on the movement of work rather than on individual activity reports. Ask what is preventing completion, what assistance is needed, and which item should move next. Mark blockers as soon as they are known. Record the blocked duration, cause, owner for resolution, and next action so recurring constraints can be analyzed instead of repeatedly rediscovered. Use distinct service classes only when different delay risks require different handling. Define eligibility, priority, capacity impact, and exit conditions for each class. Make exceptional acceleration rare and explicit. Advancing one item changes the delivery prospects of other items, so the tradeoff must be visible and accepted by the people responsible for the service. When flow degrades: - Check whether arrivals exceed delivery capacity. - Look for growing queues and aging items. - Identify bottlenecks, dependencies, rework, and switching. - Finish or unblock work before starting more. - Change a limit or policy only with a stated reason. ## Measure Delivery Time and Completed Work Without Encouraging Gaming Use a small set of measures that supports service decisions. Begin with elapsed delivery time, completed items per period, active work, blockers, and avoidable demand where relevant. Define each measure precisely, including its start point, end point, unit, population, exclusions, and review period. Do not combine unlike work types or service classes when the mixture hides meaningful differences. Examine distributions and trends rather than relying only on averages. Historical ranges help estimate future delivery expectations, but they do not remove uncertainty. Use flow views to detect accumulating work, unstable arrivals and departures, and constrained stages. Investigate changes in the pattern before treating them as improvement or decline. Protect the measurement system from gaming: - Measure the service, not individual busyness. - Pair speed measures with quality and rework signals. - Keep definitions stable during a comparison period. - Record policy or demand changes that affect the data. - Retire measures that no longer support a decision. ## Use Existing Meetings to Remove Blockers and Review Results Use meetings and reviews as feedback loops only when observations lead to decisions or action. Status information without a response mechanism does not improve the system. Reuse existing meetings when they can serve the required purpose. Adjust participants, frequency, duration, and agenda to the service context instead of creating a full new meeting structure by default. Separate immediate flow coordination from deeper improvement and risk review. Daily or frequent coordination should remove obstacles and select work; periodic reviews should examine performance, demand, risks, policies, and experiments. Keep each cadence focused on the work and service outcome. Invite only the people needed to understand the evidence, make a decision, or carry out the resulting action. For every cadence, define: - Its decision purpose and evidence inputs. - The accountable participants. - The expected actions or outputs. - The review frequency and time limit. - How unresolved actions are tracked. ## Test Small Changes That Can Be Undone and Keep What Works Turn an observed service problem into a testable hypothesis. State the expected effect, the evidence that would support or reject it, and the time or sample needed for evaluation. Prefer small changes with limited downside. Define how to reverse or revise the change if it harms delivery, quality, customer outcomes, or another connected service. Collect data during the experiment and compare it with an appropriate baseline. Record contextual changes so an apparent improvement is not credited to the wrong cause. Accept, reject, or refine the hypothesis based on evidence. Preserve useful learning even when the experiment fails, and avoid keeping a change merely because effort was spent implementing it. Repeat the cycle: - Observe demand, flow, capability, and customer outcomes. - Identify the most consequential constraint or uncertainty. - Propose a minimal policy or workflow change. - Run the change within a defined boundary. - Review results with the service participants. - Keep, revise, or reverse the change.