Capacity plans need leave in them

The two-system problem

Most teams run scheduling in one tool and leave in another. The scheduling tool holds the plan. The HR system holds who will actually be there.

Keeping them in step is somebody's manual job, and it is the job that gets skipped in a busy week. A leave request approved on Friday reaches the plan on Wednesday, if at all.

Agency scheduling products are open about this. Several handle capacity and time off but hold no real employee record, and integrate out to an HR system for it. The integration is the seam, and seams leak.

What the grid shows when it shares a record

The capacity plan is a grid of people against days, with planned hours in each cell and a monthly total per person.

Cells carry bands rather than only numbers: under, partial, full and over. Scanning a month for somebody over-allocated is faster than reading the figures.

And two overlays come from elsewhere in the same product. A cell marked as a holiday comes from the company calendar. A cell marked as leave comes from an approved request.

So approving leave changes the plan. No export, no sync, no second person to remember.

• People against days, with planned hours per cell.
• Bands for under, partial, full and over allocation.
• Holiday cells from the company calendar.
• Leave cells from approved requests in the same product.
• A billable filter, and grouping by person or project.

Reading the plan against the record

Planned hours are an intention. Logged hours are what happened. The utilisation report holds the second, from the same database, so the two can be read for the same person and week.

The billable filter works on both. Switch the plan to billable work only and the client load stands apart from internal time.

And the grid can be read from either side: grouped by people to see who is stretched, or by projects to see which job is absorbing the team.

The habit that makes it work

Plan the next month before the leave requests for it arrive, then let approvals amend it rather than replanning from scratch.

Check the over-allocated band weekly. Over-allocation is the failure that gets discovered latest, usually by the person carrying it.

And treat a person with an empty week as a question, not a spare resource. Empty often means the work was never planned, not that there is none.

Why the seam is where plans break

Two-system setups do not fail because the integration is bad. They fail on timing and on scope.

Timing, because a sync runs on a schedule and a decision does not. Leave approved at four o'clock reaches the plan overnight, and the conversation that needed it happened at half past four.

Scope, because a connection carries the fields somebody chose to map. A leave request that arrives as a date range, with no type and no half-day, is a smaller fact than the one that was approved.

Sharing a record removes both problems at once, which is a duller sentence than integration and a better property.

The three questions the plan should answer

A capacity plan that answers these is doing its job. One that does not is a spreadsheet with better colours.

Who is over-allocated in the next month, and by how much. That is the question with a deadline attached, and it is the one people discover last.

What happens if this project starts two weeks late. Moving a start date should be a visible change, not a mental exercise.

And who is on nothing. An empty row is either a planning gap or a person waiting, and both need someone to look.

Notice that none of the three needs a rate. They are all questions about people and days, which is exactly the layer the grid holds.

Planning far enough ahead to be useful

A plan that only covers the next fortnight tells you what you already know. A plan that covers six months is mostly fiction. The useful window sits between.

Six to eight weeks is where most teams find it. Long enough that leave, holidays and a project ending are all visible. Short enough that the names in the cells still mean something.

Past that, plan shapes rather than people. Two engineers from March, not these two engineers from the ninth.

And replan on a rhythm rather than on events. A fortnightly pass keeps the plan roughly true. Replanning only when something goes wrong means the plan is always describing the last crisis.

The failure mode to watch for is a plan nobody reads. If the grid is only opened when a new project appears, it has stopped being a plan and become a record.