Everything is urgent: designing classes of service for an internal ops team
A six-person internal IT operations team supports 1,400 staff. A three-month demand sample shows 42% incidents, 23% service requests, 18% change tasks and 17% project work. Four stakeholder groups - Finance, Sales, HR and Engineering - each have a route into the team; two of them label essentially everything 'urgent'. Service levels are agreed as four hours for P1 and two business days for P2. Last quarter 31% of P2s missed the two-day target, while no P1 was missed. The board is a single 'Doing' column holding 19 items for six people, plus a backlog nobody grooms. Staff describe the week as 'firefighting then catching up', and the last two improvement initiatives died because 'we had no time'.
1. Which analysis would you do before redesigning the board, and what specifically would you look for in this data?
Read the worked answer
Redesign without analysis will simply produce a tidier version of the same dysfunction. The priority analyses:
Purpose and sources of dissatisfaction. The team exists to keep services running and to deliver agreed changes. The dissatisfaction signal is concrete: 31% of P2s missed while P1s were met, and improvement work never survives contact with the week. That tells you the current system trades the important for the immediate, not that people are careless.
Demand analysis by type, size and arrival pattern. You already know the 42/23/18/17 split; the next question is variability. Incidents arrive randomly - chart arrivals by day and hour. If incident arrivals are unpredictable, no amount of planning will schedule them, and capacity must be reserved for them rather than booked against project work.
Capability analysis. How many items of each type can six people actually finish per week, and where does the time go? Compare that with the arrival rate per type. If incidents plus requests already consume most of the week, the project work is being funded with overtime rather than planned capacity, which explains the dead improvement initiatives.
Current concurrency. Nineteen items in a single column for six people is over three each, and none of them shows age, size or type. Check how much of the 31% P2 miss is actually queue time rather than work time; my expectation is that most of it is waiting.
Only after those four analyses can you set limits, classes and capacity allocations that reflect the real demand mix.
2. Design the classes of service and capacity allocation, including the numbers you would start with.
Read the worked answer
Anchor the design in the demand mix rather than in an ideal model.
Reserve capacity for the unplanned. 42% of demand is incidents, so treat roughly 40–50% of the week as unavailable for planned work. Publishing that number is itself an intervention: it stops stakeholders assuming six full-time people are theirs to book.
Classes of service:
- Expedite - P1 incidents. One concurrent item, whole team may drop other work, daily review of how much it cost. Cap the number per week and count it.
- Fixed date - changes tied to a regulatory or release deadline. Entered early, risk-reviewed two weeks ahead; if the review says it will miss, renegotiate then rather than on the day.
- Standard - P2 and routine requests. FIFO by age, with an SLE derived from the promise: measure the current p85 of P2 cycle time. If p85 is three days against a two-day target, either the promise or the reserved capacity must change - a promise the system cannot meet 85% of the time is a policy defect, not an execution failure.
- Intangible - improvement work, which needs its own protected limit so that it is not simply the thing that yields first. One or two items in flight, owned at the operations review.
Implement as swimlanes with per-class limits, not one Doing column with 19 items. Total working WIP should drop to roughly six to eight, with each class visible. Write the reclassification rule and name who may invoke it, then track how often 'urgent' survives a day of scrutiny - that number usually changes the stakeholders' behaviour faster than any argument.
3. Two stakeholder groups insist everything they raise is urgent. How do you handle this without becoming a negotiation each time?
Read the worked answer
Make it a policy question with visible evidence, not a case-by-case argument.
Publish the demand and capability data. Show Finance and Sales the arrival mix and what six people can finish; show the 31% P2 miss against the two-day promise. Frame the conversation as a choice about which classes get which capacity, not as a complaint about volume.
Give them ordering, not promises. Each request gets a visible position, its class and its SLE. A stakeholder who can see that a standard request takes a median of two days and that three fixed-date items are ahead of it is usually less inclined to escalate than one who is told 'we will try'.
Put the classification in the policy. Urgency is defined by impact and time sensitivity with named criteria, the right to reclassify sits with a named role, and every reclassification is recorded. Reporting reclassifications monthly changes behaviour, because 'we marked 40 items urgent and 6 met the criteria' is hard to argue with.
Run a monthly service delivery review with the four groups. Its agenda is: what did we deliver against the classes, where did we miss, and do the classes still match your needs? That forum is where capacity is renegotiated - once a month, with data - instead of at every request.
Protect improvement capacity explicitly. Reserve it as a class with its own limit and report it at the same review. If it is silently consumed, the meeting sees it immediately and the trade-off becomes the stakeholders' decision rather than the team's failure.