Workload Balancing: Size the Gain Before You Commit to the Change

Workload Balancing does one thing. It redistributes work across resources to balance utilisation and eliminate over and under loading. You enter what each role carries today, you enter what each role can carry, and the tool recalculates utilisation from those two numbers.

It belongs in the Improve phase of RDMAICS. By the time you open it, you have already recognised a problem, defined its boundary, measured the process, and analysed the cause. Improve is where a cause becomes a change. Workload Balancing is the step between the diagnosis and the pilot.

Reach for it when your analysis points at distribution rather than volume. If one role is pinned at the ceiling while another sits well below it, the total work may be fine. The spread is the problem. That is a different fix from adding people, and a cheaper one to test.

Use it before you commit. The point is to size the gain on paper, see whether the redistribution clears the overload, and only then decide whether a pilot is worth running.

The worked example in this article is the sample data that ships with the tool. It is fictional. It is used here because it is small enough to follow line by line and realistic enough to recognise.

The case is an accounts payable function with five resources. Three clerks, one approving manager, and a vendor query lead. Each has a capacity of 7.5 hours per day. The team suspects that automation and triage changes will shift work around, and they want to see the shape of the team before and after.

The diagnosed cause sits upstream. Manual entry absorbs the front of the process. Filing absorbs the back. Exceptions bunch in the middle. The proposed change is a set of rebalance actions, one per role, written against each line.

Nothing has been implemented yet. That is the correct state for this tool. You are modelling, not reporting.

The worksheet takes one row per resource. You name the role, enter current load in hours per day, enter capacity in hours per day, and record the rebalance action you intend to apply. Utilisation is not something you type. The tool calculates it.

Here is the sample data as loaded.

Write the rebalance action in plain words. It is the bridge between the analysis and the pilot, and it is the column people argue about in the room. Keep it short enough to read at a glance.

The quality of the output rests entirely on these two columns. Current load should be observed, not estimated from a position description. If your Measure phase produced cycle times and volumes, derive load from those. If it did not, go back and get the data before you model.

Capacity is the harder number. In this case every role carries 7.5 hours per day. That is a deliberate simplification. It assumes a full day is available for process work. In most real teams it is not, because meetings, training and recovery time eat into it. If you set capacity at the contracted hours, you will understate utilisation across the board.

Use the same basis for every row. Hours per day for one role and hours per week for another will produce a utilisation figure that looks fine and means nothing. Consistency matters more than precision here.

Record the assumption somewhere visible. When someone challenges the result three weeks later, the assumption is what you will need to defend.

The tool recalculates utilisation from current load divided by available capacity and returns two headline figures. Overloaded resources comes back as 0. Average utilisation comes back as 81.3 per cent.

Read those two together. Zero overloaded resources means no role in this set is carrying more than its capacity. AP Clerk 1 sits at 100 per cent, which is at the ceiling but not over it. That is the warning line rather than the breach line. A role at exactly capacity has no absorption left. Any variation in volume pushes it into backlog.

Average utilisation of 81.3 per cent tells you the team as a whole has headroom. But an average hides the spread. The range here runs from 60 per cent at the approver to 100 per cent at the entry clerk. That gap of 40 points is the actual finding. It is the reason a redistribution is worth considering at all.

The chart plots current load and capacity as bars against a utilisation percentage line. Scan it for shape. You are looking for bars that touch the capacity line and bars that fall well short. The tool also offers an AI review that explains the result in context.

First decision: whether the problem is capacity or distribution. With zero overloaded resources and 81.3 per cent average utilisation, this team does not have a headcount case. It has a spread case. That saves you from proposing the expensive answer to the cheap question.

Second decision: where the slack sits. The approver at 60 per cent and the vendor query lead at 73 per cent are the two lowest. If you intend to move exception handling somewhere, those rows are where it can land. The rebalance actions reflect that. The approver keeps the role but focuses on exceptions.

Third decision: what to pilot. AP Clerk 1 at 100 per cent is the pressure point, and the action against that row is to reduce load because OCR takes volume. That is the single change most likely to move the headline figures. Pilot it on its own and you will be able to attribute the effect.

Fourth decision: what to measure during the pilot. The same two columns. Load and capacity. If you re-enter the worksheet after the pilot with new load figures, the tool gives you a directly comparable utilisation picture.

The most common mistake is treating 100 per cent as the target. A role at full capacity cannot absorb variation. In this data AP Clerk 1 is at 100 per cent and the action against that row is to reduce, not to celebrate.

The second mistake is chasing the average. You could raise average utilisation by loading the approver and still leave the entry clerk at the ceiling. The average would improve. The process would not.

The third mistake is modelling the post-change state and the current state in the same worksheet. Keep them separate. The result shown here is built from current load, and the rebalance actions are intentions, not applied changes.

The fourth mistake is skipping Measure. If the load figures came from a conversation rather than observation, the tool will still return a clean number. A clean number from poor input is the most dangerous output in improvement work.

It will not tell you whether the work can actually move. Utilisation treats hours as interchangeable. They are not. Matching exceptions may need judgement that the filing clerk does not have, and no percentage on the screen will surface that. Skills, authority and system access all sit outside the model.

It will not validate the rebalance actions. The column holds whatever you type. The tool does not assess whether OCR will take the volume you expect, or whether a vendor portal will reduce query load. Those are assumptions you carry into the pilot and test there.

It will not forecast the result of the change. The 81.3 per cent figure describes the current state. There is no projected utilisation in this output. If you want the after picture, you run the pilot, collect new load data, and enter it again.

It will not account for variation over time. One row per resource gives you one snapshot. Month end, quarter end and invoice spikes are invisible here. A role at 93 per cent on an average day may be well past capacity in the last week of the month.

Used within those limits, the tool does what it says. It shows load against capacity, flags over and under loading, and gives you a defensible basis for deciding whether a redistribution is worth piloting. That is enough to move from a diagnosed cause to a change you can test.