The resourcing spreadsheet is always wrong by Wednesday

Every PMO I have worked with keeps a resourcing spreadsheet, and every one of them knows it is out of date. It gets rebuilt before a portfolio review, circulated, and then quietly diverges from reality until the next review forces another rebuild. Nobody is being careless. The artefact just has no way of staying true.

The question a PMO is asked, and cannot answer

The question is never "show me the plan". It is some version of:

• Can we start this in November, or is everyone already committed?
• Who could take two days a week of SAP work from October?
• We have lost Anna for six weeks. What breaks?

These are all the same question — what is actually available — and a spreadsheet cannot answer it, because it records what someone decided in the week they built it. It does not know about the two people who were pulled onto an incident, the parental leave booked last Tuesday, or the public holiday in the middle of the sprint.

So the PMO answers from memory and instinct, which is often better than the spreadsheet, and is also not a system.

Why it drifts

Three reasons, in order of how much damage they do.

The plan and the actuals live in different places. Allocation sits in a spreadsheet; hours sit in a timesheet tool, if they are recorded at all. Nobody compares them, because comparing them is a manual reconciliation nobody has time for. The single most useful number in resourcing — we planned ten days and booked four — is the one number the setup cannot produce.

Capacity is assumed, not recorded. A spreadsheet row says "2 days a week". Two days of what? A four-day week? A month with two public holidays in it? The denominator is in somebody's head, so the percentages are decorative.

It cannot hold demand that has no name yet. You know the programme needs a senior developer in November. There is nobody to put in the cell, so it goes in a comment, or a separate tab, or nowhere. Then hiring is late, because the demand was never visible as demand.

The fix is not a better spreadsheet

It is making the plan and the actuals the same kind of thing.

In TransformRadar, allocation is stored per person, per project, per day, in hours — the same unit time registration already uses. That sounds like an implementation detail and it is the whole design. It means "planned versus booked" is a subtraction rather than a reconciliation, and it means a day view, a week view and a month view of the same data cannot disagree with each other.

You do not key hours, though. You key days, the way people actually talk: two days a week from October to December. The days spread across that period's working days, skipping the organisation's public holidays and any leave already recorded. A part week at the edge of the band gets its share rather than the whole week's quantity — key four days a week into a band that ends on a Monday and you get four fifths of that Monday, not four days crammed into one.

The useful number is not the plan or the actuals. It is the gap between them.

Because capacity is recorded rather than assumed — a working week per person, effective-dated, plus a holiday calendar and leave — the percentages mean something. And because the system knows them before you save, it can tell you what you are about to do: Anna would be at 130% in week 41 — one day over. It does not block you. Over-allocation is sometimes the right answer and hiding it is worse, so the conflict is put in front of you and the judgement stays yours. It just stops being a thing you discover in November.

Demand before there is a person

Work that nobody holds yet is recorded as an open role: "a senior developer, three days a week, from November". It behaves like any other allocation — it shows in the grid, it counts towards the project's plan, and it appears in a chart of unfilled demand against the people who could actually meet it, by skill.

When you know who it is, you hand the role to them. The planned days move across; nothing is re-keyed. Before you confirm, you are told what it does to that person's weeks — including the days where they would end up over capacity.

This is the part that turns resourcing from bookkeeping into planning. A plan that can only describe people you have already hired is a record of the past.

Who owns it

This is where most resourcing tools quietly make a mess, so it is worth being explicit.

The PMO owns resourcing. Allocation on any project, the working weeks, the holiday calendar, leave, the skills catalogue, the department and team structure. Spotting that someone is booked on two projects at once is a portfolio question, and the PMO is the only role that can see the whole portfolio.

Executives read it. Every grid, every chart, the whole organisation — read-only. Oversight is not administration.

A project lead staffs the projects they lead. The organisation-wide picture is not theirs by default — though there is a setting to widen it, if you would rather leads saw a person's total commitments.

One deliberate detail: the reason for an absence — sick leave, parental leave — is visible only to the person themselves, the PMO and an Org Admin. Everyone else sees that the day is unavailable. Resourcing needs the availability. It does not need the diagnosis.

It scales down

None of this assumes a hundred people. A single project with four people gets the same thing: what you planned, what was booked, and who has room. Resourcing is an optional module, off until an Org Admin turns it on — so an organisation that does not want it never sees it, and one that does can start with a single project and two names.

A PMO's job is not to maintain a spreadsheet. It is to answer, honestly and quickly, whether the organisation can do the thing it has just committed to. That answer needs the plan and the actuals in the same place, capacity written down rather than assumed, and demand visible before it has a name.

See what a live portfolio view actually requires, or how the plans compare.

• PMO
• resourcing
• capacity
• governance