Utilisation Rate Is a Bad Target: Three Better Numbers

Utilisation rate is fine as an observation and bad as a target. The moment you set a high utilisation number as a goal, you remove the slack that absorbs illness, handovers and the work nobody scheduled, and you teach people to record their time so the number looks right. Better questions to ask: how much unplanned work arrives, how long things wait between hands, and how much of the team's committed work depends on one person.

Those three tell you about headroom. Utilisation tells you about bookkeeping.

What goes wrong when utilisation becomes a target

A team at very high utilisation has no capacity to absorb anything. That sounds efficient right up until the first surprise. Someone is off sick. A client escalates. A dependency arrives late and needs rework. With no slack, every one of those pushes a date, and the pushes compound because the recovery work has nowhere to go either. Sick days cluster as well, and reading those spikes without guessing about people is a skill of its own.

The second problem is measurement pressure. When people know utilisation is watched, the number stops describing reality. Time gets recorded against whatever keeps the figure healthy. Nobody is being dishonest; they are answering the question they were asked.

The third problem is that utilisation counts hours, not outcomes. A person who spends a day rebuilding context after a bad handoff shows up as fully utilised. So does a person shipping the most valuable thing on the roadmap. If your measure cannot tell those apart, it cannot guide a decision.

Number one: unplanned work as a share of the total

Count the work that arrived after the plan was set. Support escalations, urgent fixes, requests that jumped the queue.

If that share is small and steady, you can plan tightly. If it is large or swings a lot, you need slack, and the amount of slack you need is roughly the amount of unplanned work you keep receiving. This gives you a defensible answer when someone asks why the team is not fully booked. You are not idle. You are covering the work that always arrives and never appears on a roadmap.

Track it for a quarter before drawing conclusions. One bad month proves nothing.

Number two: wait time between hands

Take a piece of work and split its life into time being worked on and time waiting. Waiting for review, waiting for an approval, waiting for information, waiting for the next person to be free.

In most teams the waiting is the larger half, and it is invisible on a utilisation report because everyone is busy with something else while it waits. Cutting wait time speeds up delivery without asking anyone to work harder, which is the rarest kind of improvement there is.

You do not need a tool to start. Pick five recently finished items and reconstruct their timeline by hand. The pattern usually shows up immediately, and it is usually one specific queue.

Number three: single person dependency

For the work committed this quarter, how much of it can only be done by one named person?

This is a headroom measure and a risk measure at once. A team can look healthy on every other metric and still be one person's holiday away from missing a date. Count the items where the answer to "who else could pick this up" is nobody. That count is one way of spotting the person holding three projects together.

The fix is slow and normal: pairing, documentation, deliberately assigning the second person occasionally even though it is faster to give it to the expert. It costs time now and buys you the ability to have people take leave.

Reading these together

The three numbers work as a set. High unplanned work plus long wait times plus heavy single person dependency is a team that will miss dates no matter how hard people push, and pushing harder makes the third one worse because the expert absorbs everything. It is also the shape that shows up in ticket data before any survey.

Getting these numbers usually means looking at data spread across a project tool and a leave system that do not agree, which is part of why teams fall back on utilisation: it comes out of one place. SicherOne exists to remove that split, putting project management and HR on one set of records so availability and workload are the same picture rather than two.

Whatever you use, change the question. Ask how much the team could absorb tomorrow if something went wrong, not how full the calendar looks today.