Recording the Adjustment Separately
The three columns that make judgement assessable, what goes in the reason field, and what a year of the record lets you answer.
One year of one team's forecast, published figures against what happened
System said 118; raised for the release on the 14th.
No adjustment made.
System said 127; raised, then automation cut less than expected.
System said 133; raised on "feels low", no fact cited.
Two adjustments carried a dated fact, one carried no reason at all, and one period was left alone. Published error averaged 3.0% against 6.1% for the system output: the override helped, and the record is the only reason anybody can say so. One employer's own record, not a benchmark.
Three columns make human judgement assessable: what the method produced, what was published, and why they differ. Without them the forecast is one number with an unknown amount of judgement inside it, and nobody can ever say whether the judgement helped.
The adjustment process in “Recording the Adjustment Separately” should preserve the unaltered model result, the human change and the reason for it. A team considering see the provider’s implementation notes for recording freelancer billable hours can add operational time and project context, while the forecast owner remains responsible for documenting the override and reviewing its effect.
The change costs ten minutes to introduce and it is the most valuable piece of record-keeping in the discipline.
As a separate benchmark for “Recording the Adjustment Separately”, see Looker business-intelligence resources. Keep source data, model, override and resulting decision visible as distinct steps.
The three columns
System. Published. Reason. Plus the periods the adjustment applied to, which is a fourth and is worth having.
That is the whole structure. It sits in the same file as the forecast and the error record.
What goes in the reason field
A fact and a date where there is one: "release on 14th", "contract C starts 1 June", "supplier outage expected week 23". A statement of the basis where there is not: "judgement, no specific information".
The second kind is not forbidden. It is labelled, which is the entire point.
Why the honest blank reason matters
Because an adjustment with no stated fact is a hypothesis about the forecaster's intuition, and after thirty of them there is enough data to test it.
In some operations intuition tests well. In others it does not. Neither can be known without the label.
The periods column
An adjustment applied to the whole horizon and one applied to a single week are different acts. Recording which periods were touched is what lets the subsequent error be attributed.
It also discourages the habit of adjusting everything, which is almost never what the information supports.
What a year of the record answers
Whether judgement improved accuracy overall. Which kinds of adjustment helped. Whether adjustments chase the last error. Whether there is a standing direction nobody intended. And which recurring adjustments should become model terms.
Five questions, none answerable today in most organisations.
The comparison to run
Mean absolute error of the published series against mean absolute error of the system series, over the same periods and the same horizons. Then the same split by reason type.
Two subtractions. The answer is usually surprising in one direction or the other.
Attributing a miss correctly
With the columns in place, a bad period can be attributed: the system was close and the adjustment moved it away, or the system was wrong and the adjustment did not go far enough.
Those are different problems with different owners, and without the columns both are recorded as "the forecast was wrong".
The recurring adjustment
Where the reason field shows the same fact every month — a billing run, a standing displacement — the adjustment is a missing model term.
Scanning the reason column once a quarter and promoting the repeats is how the model gets better without a project.
Who writes the reason
The person making the adjustment, at the time. Not reconstructed later, which produces reasons that are explanations rather than records.
This is the only part of the discipline that requires anybody to do something they were not doing already, and it takes a sentence.
Keeping it published
In the forecast document, visible. A private record gets curated, honestly and unconsciously, and a published one does not.
It also signals that adjustment is legitimate, which prevents the worse outcome where people adjust and do not say.
What it is not for
Catching anybody. If the record becomes an appraisal input, the reasons get written for the reader and the information is lost within two cycles.
Saying this out loud when it is introduced is worth the thirty seconds.
The adjustment to an input
Harder to record and worth the trouble: where the override happens by changing a driver value or excluding a period rather than by editing the output.
Versioning the inputs as used, not just the output, is what makes those visible. Without it the system column is itself adjusted and the comparison is meaningless.
Reading the reason column sideways
Once a year, read the reasons on their own, ignoring the numbers. They are a list of everything the model did not know, in the organisation's own words.
That list is the best available specification for what to build next, and it was assembled free.
Starting it
Next cycle. Add two columns to the file that already exists. Write one sentence per adjustment.
Three months later there is something to look at; a year later there is an answer to a question that has been argued about, in most organisations, for as long as anybody can remember.