BrightPay: reading the flow data before adding anyone
BrightPay's digital operations team - six engineers and one tester - supports an online payments product. Work flows across a Kanban board with columns Ready, Develop, Test and Deploy, and no column has a work-in-progress limit. Over one quarter, average cycle time has risen from 4 days to 13 days. At the last count there were 9 items in Develop, 27 in Test and 2 in Deploy. Roughly 35% of newly arrived items are labelled 'urgent' by the head of sales, who argues that customers cannot wait. The team reports that it is at 100% utilisation and cannot go any faster. The board has frozen headcount and the cost tolerance is tight, but it wants lead times down within the quarter.
1. Using the numbers given, diagnose where the problem actually lies. What would you tell the team about its '100% utilisation' claim?
Read the worked answer
- Little's Law: average cycle time ≈ average WIP ÷ average throughput. Throughput here is capped by one tester and six engineers; WIP has been allowed to grow without limit; 13 days is the arithmetic consequence, not a mystery or a motivation problem.
- Test is the constraint. 27 items queued at test against 2 at deploy means everything upstream is being pushed into a bottleneck. The queue in front of the constraint is the queue that sets delivery time, and finishing more development work upstream only makes it longer.
- 35% 'urgent' means the priority system has collapsed. If a third of the work is expedited, nothing is prioritised, everything is interrupted, and each interruption costs a context switch that pushes standard items further back. Sales is not getting a fast service; it is degrading everyone's.
- 100% utilisation is the problem, not the achievement. With no slack, any variation becomes a queue. The goal is flow and predictability, not keeping every person busy; resource efficiency has been bought at the price of lead time.
- Check the data quality before acting: confirm how cycle time is measured and whether ageing WIP (items stuck for weeks) is inflating the average - the fix may be to unblock old items first.
2. What changes would you make to the board and its policies, and what effect should be expected first?
Read the worked answer
- Set WIP limits, starting at the constraint. Limit Test to what the tester can genuinely finish in the team's cadence, then limit Develop. Enforce the rule: when Test is full, engineers swarm on testing or on unblocking rather than pulling new work. 'Stop starting, start finishing.'
- Make policies explicit. Entry criteria per column (definition of ready), exit criteria (definition of done), and a stated behaviour for when a limit is hit. Without explicit policies, the limits are just numbers on a wall.
- Introduce classes of service with a reservation, not an exemption. Expedite gets a small fixed capacity slot (for example one item at a time, 10–15% of capacity) with a named approver; fixed-date items are planned; standard work is pulled in order. Publish what an urgent request displaces so the trade-off is visible to sales.
- Raise capacity at the constraint, nowhere else. Automate regression testing, move testing left, or pair engineers with the tester. Adding capacity upstream or downstream of the bottleneck only lengthens queues.
- Expected sequence: cycle time and WIP fall fairly quickly; throughput may dip briefly before recovering. Report cycle time and cumulative flow, not busy-ness.
3. The board has fixed cost and headcount. How do you present this plan within PRINCE2's progress and tolerance arrangements, and what happens if sales refuses to give up unlimited 'urgent'?
Read the worked answer
- Frame it in the language the board already uses. The improvement comes from policy, not spend, so it fits inside the frozen cost tolerance. Show it does not threaten the stage plan, and report cycle time and queue size in the highlight report as progress information - they are leading indicators of whether the release date holds.
- Make the pain concrete. In the last quarter, half the items took under five days and half took over twenty. That unpredictability, not average speed, is what the business actually feels.
- Treat unlimited expedite as a decision above the project manager's authority. If sales insists, that is an exception: state the consequence precisely - standard-work cycle time rises to a forecast figure and the committed release moves by a stated amount - and let the board choose. Do not quietly absorb it and then miss the date.
- Keep the constraint honest in governance terms: the board owns the tolerance, the product owner owns priority, and the team owns flow. Blurring those three is what produced 27 items in Test.