The Widening In Progress Band

A widening In Progress band with a flat Resolved band means work is entering and accumulating in process faster than it is being completed. Before changing limits, the manager should investigate where the accumulation is: aging of in-progress tickets, time in Waiting on Customer, rework, handoffs, and the effect of urgent tickets jumping the queue. The diagram alone does not prove agents are slow; it may show hidden work such as the monthly release checklist, blocked tickets or multitasking. The proposal of a single WIP limit of 160 is not a real improvement because it sets the limit at the current average WIP, ratifying the problem rather than reducing it. A better first step is to visualise the workflow by work type and state, add explicit policies for ready, blocked and done, measure queue time and touch time, and then set a limit below current WIP and observe the effect. Use the cumulative flow diagram together with a control chart of cycle time and an aging chart. A weekly prioritisation meeting may help, but it will not fix flow if work is not pulled.

Start from customer and service impact, not from who asks. Define a small set of classes, for example expedite, fixed-date, standard and intangible, each with explicit entry criteria and a policy. Expedite should be reserved for genuine service outages, security incidents or contractual breaches, with a named authoriser and a cap, such as one or two expedite items in the system at a time, counted in WIP. Urgent cannot be 10% of all tickets and still be an exception; if account managers can mark tickets urgent without a trade-off, the class loses meaning and standard work starves. Fixed-date tickets need a date and a policy for when to start. Standard tickets are pulled in order, with an SLA for first response and resolution that reflects the class. Publish the policies and review them at a service delivery review. Also measure expedite frequency and the impact on standard lead time. If expedite demand is genuinely high, address capacity or intake rather than let every urgent ticket bypass the queue.

It matters because the checklist consumes real capacity that is invisible to the board and to the WIP limits. If agents do three days of release work while their ticket WIP stays unchanged, actual WIP is higher than measured, lead time is understated, and the team will be blamed for low throughput caused by hidden work. Hidden work also undermines improvement because the cumulative flow diagram and control chart cannot explain the delay. The fix is to make the checklist a visible work item type on the board, with its own policy, estimate and place in the workflow, and to include it in WIP accounting. If it is a recurring batch, plan it as a cadence item with reserved capacity, or break it into smaller routine checks that flow with releases. Do not treat it as overhead exempt from limits. Review whether the checklist can be reduced or automated. The test is whether a new agent can see all the work that consumes the team's time, not just customer tickets.