Forecasting what an automation saves

Take ten lab sites where staff type incoming test request forms into the laboratory system by hand. An automation will read the forms and enter most of them, once it has been validated at each site. The business case counts the hours this frees, 8,000 a year, and prices them at $50 an hour, which gives $400k.

Only part of that $400k is money. Freed hours turn into money when someone decides in advance what happens to them, and here there are two such decisions. A temporary staffing contract at two sites will end. And this year's growth in test volumes will be absorbed without the two hires already in the budget. Together they're worth $250k, and that's what counts towards our target.

The other $150k is time spread thinly across many people. We track it as capacity, but it does not count towards the target.

The $250k is the target. It's agreed when the project is approved, and Finance builds it into the year's plan. After that it should hardly move. Next to it we keep a forecast: our estimate, updated every month, of how much will arrive this year.

Each month the forecast is the savings Finance has already confirmed, plus our estimate for the months left. Finance often calls this the full-year outturn, or latest estimate. In January it is all estimate. Month by month the confirmed part grows, and by the end of December nothing is left to estimate.

We keep the two apart. When the estimate is also the target, people pad it before they're held to it and inflate it when they need funding. Then it stops telling you anything about the year ahead.

We build the forecast from its drivers: when each site goes live, and how quickly the tool takes over the work once it does. Those two decide when the staffing contract can end and whether the hires will be needed. When the forecast moves, we can say which driver moved it.

The starting values come from the process as it runs today: how many forms each site receives and how long each one takes. The laboratory system's timestamps give most of that.

A driver model is not the only way to forecast a saving. Which method we use depends on what data exists. The time-series methods have their own walkthrough.

In January we would report the forecast as a range, $200k to $260k, with $250k as the most likely point. The low end assumes the tool needs twice as long to take over the work, and the portfolio can plan around it.

We put the forecast together with the site managers who will run the tool, since they'll have to explain it when it misses. They also know which assumptions are weakest. Every manual change to a forecast gets a written reason, and we check those reasons later against what happened.

The initiatives, their owners, targets and approvals live in a work management platform, and the forecast lives there too. Each forecast change is logged against its initiative, with who made it and why, so the history is there when someone asks what moved.

Python pulls the driver data from the systems that hold it, here the laboratory system and the staffing records, and recalculates the forecast on a schedule. Power BI then shows the forecast next to the actuals, built on the same data, so the forecast and the report share one definition. An LLM workflow can draft the monthly commentary from the same numbers, for someone to check before it goes out.

Everything above tracks one initiative. The target, though, is set for the whole portfolio, here $125M for the year, and adding up each project's forecast overstates what the portfolio will deliver. A business case that is only an idea counts as much as one already in the ledger, and most portfolios carry more early ideas than late ones.

So at portfolio level each initiative is counted by stage, with a weight for how likely its forecast is to arrive. The stages and weights below are a starting point; the weights should come from how past initiatives at each stage actually did.

Summed as reported, the forecasts come to $175M, comfortably over the $125M target. Weighted by stage they come to exactly $125M: the target is covered, with nothing to spare if one more initiative slips the way this automation did.

The savings forecast answers one question about an initiative: will it return what it promised? Earned Value Management answers the other: is it being delivered for the money and in the time we planned? The two meet in the drivers. If the automation's rollout runs late, Earned Value Management shows it first, as a schedule index below 1, and the savings forecast follows once the go-live dates move. Both roll up to the portfolio: one on what the initiatives cost to deliver, the other on what they return. The Earned Value Management walkthrough shows the delivery side on one programme, played out in three scenarios.