Skip to content
allanninal.dev/build
Collaborate

Part 1 of 7 · Capacity forecaster series ~6 min read

A capacity forecaster on AWS for a few dollars a month

In November somebody notices that January is going to be difficult. The busy period runs from the middle of January, hiring and training a fitter takes ten weeks, and November plus ten weeks is the end of January. The problem was visible in the order book in August. This post walks through a small system that would have said so then.

a building that has a bunch of windows on the side of it
Photo by Ethan Olarte on Unsplash

Key takeaways

  • Measure the capacity you have, not the one on the org chart.
  • Forecast the peak, not the average. You do not run out on an average week.
  • The horizon must exceed the lead time to add capacity, or nothing can change.
  • Record every forecast so it can be scored against what happened.
  • Designed on AWS for about $2 a month.

The whole system on one page

Before any code, here is the shape of what we are designing.

System: capacity measured, demand forecast, the gap reportedThree boxes across the top sit outside the AWS account. On the left, What we can do: hours actually available. In the middle, What is coming: orders, bookings and seasonality. On the right, Whoever can act, with enough notice. Each connects by an arrow to the AWS account container below. Actual output flows down into the account. The pipeline feeds in. A dated warning goes back out. Inside the AWS account are three components in a row. On the left, Capacity, measured rather than assumed. In the middle, Demand, expressed as a range rather than a number. On the right, The gap: when, how big and how confident. A note at the bottom says the output is a date and a size, and anything vaguer than that cannot be acted on.AWS ACCOUNTWhat we can dohours actuallyavailableWhat is comingorders, bookings,seasonalityWhoever can actwith enough noticeCapacitymeasured, notassumedDemandwith a range,not a numberThe gapwhen, how big,how confidentactual outputthe pipelinea dated warningThe output is a date and a size. Anything vaguer than that cannot be acted on.
Fig 1. Three things outside the account, three pieces inside it. The output on the right is deliberately narrow: a week, a shortfall, and a confidence.
  • Compute
  • Analytics
  • Front-end & mobile
  • People

Two things most forecasts get wrong

The first is using paper capacity. Six fitters at forty hours is two hundred and forty hours, and the real figure after holiday, sickness, training, setup, rework and the meeting on Thursday is a good deal lower. Forecasting demand against a number that has never been achieved produces a forecast that says everything is fine right up until it is not.

The second is forecasting the average. An average week has enough capacity in almost every business that is still trading. The weeks that matter are the busy ones, and a forecast of the mean says nothing about them.

What runs (the inside)

  • Capacity. Measures what was actually produced or delivered per period, rather than what should have been. Part 2.
  • Demand. Projects the pipeline forward with a range, including the seasonality that is usually the whole story. Part 3.
  • The gap. Where the two cross, how far ahead, and whether that is enough notice. Parts 4 and 5.

One shortfall, end to end

One capacity shortfall detected twenty-two weeks aheadA horizontal row of five boxes joined by arrows. Real capacity: one hundred and eighty-two hours a week, measured. Demand rising, from the order book. Crosses in week four of January. Flagged in August, twenty-two weeks ahead. Lead time ten weeks: still actionable. A note says the fifth box is the test, and a warning inside the lead time is just bad news.ONE SHORTFALL, END TO ENDReal capacity182 hrs/week, measuredDemand risingfrom the order bookCrosses in week 4of JanuaryFlagged in August22 weeks aheadLead time 10 weeksstill actionableThe fifth box is the test. A warning inside the lead time is just bad news.
Fig 2. The same system as one line. The comparison in the last box is what distinguishes a forecast from a report.
  • Compute
  • Machine learning
  • Management
  • Analytics

In plain words

The workshop’s paper capacity is two hundred and forty hours a week. Measured over a year, actual productive output averages a hundred and eighty-two, and the difference is holiday, sickness, setup between jobs, and rework. A hundred and eighty-two is the number to forecast against.

The order book, projected forward with the seasonal pattern from the last three years, crosses that line in the fourth week of January and stays above it for six weeks. The shortfall peaks at about forty hours a week.

That finding lands in August, twenty-two weeks ahead. Hiring and training a fitter takes ten weeks, so there is time to hire, or to book contract capacity, or to talk to two customers about moving delivery dates. Any of those is a decision; the forecast just makes sure it is a decision rather than a discovery.

Design rules that shaped every decision

  • Capacity is measured from output, not calculated from headcount.
  • Demand is a range, and the range widens with distance.
  • The horizon is set by the longest lead time to add capacity.
  • Every forecast is stored so it can be scored against what happened.
  • Never propose the action. Report the gap and the date.
  • Say the confidence, and say what would change the answer.

Why this shape

Capacity forecasting has a reputation for being either trivial or impossible, and both reputations come from the same source: a forecast that is not tied to a decision. A chart of projected utilisation with no date, no lead time and no confidence is a thing people look at and nod about.

The version that works answers one question with three numbers: which week, how short, and how sure. Everything in this design is oriented at producing those three, early enough for them to matter.

The next four posts walk through each piece: how real capacity gets measured, why the peak matters more than the average, how far ahead is worth forecasting, and how a forecast gets scored afterwards. One diagram per post, a cost breakdown, and an engineering reference at the end.

All posts