A supplier writes on a Tuesday to say the valves will be two weeks late. On most projects that sentence reaches the people who can do something about it in the next monthly report, is discussed in the review after that, and turns into a decision a week or two later. By then the site has worked for seven weeks on a plan that was wrong on the Tuesday.
This post is about that wait. Not about how to remove it, yet, but about how to measure it on your own project, because almost nobody does, and the number is usually larger than anyone in the room would guess.
The monthly cycle hides the age of its inputs
A monthly report is a snapshot taken on a data date, written over the following week, reviewed the week after, and acted on after that. The report itself is dated, so everyone knows how old it is. What nobody tracks is how old the facts inside it were on the data date. A delivery slip that landed three weeks before the cut-off is already three weeks old when the snapshot is taken, and seven or eight weeks old when the decision is finally made.
The decision is not slow because the people are slow. It is slow because the fact spent most of its life waiting for a container to travel in.
Measure it: three dates per fact
You do not need software for the first measurement. Take the last review's minutes, pick ten decisions, and for each one write down three dates:
- When it happened. The date of the letter, the site diary entry, the revised delivery note. Not the date someone noticed it.
- When it was first written down somewhere the project could see it. A register, a report, an email to the project manager.
- When it was decided. The date of the instruction, the change, or the explicit decision to do nothing.
The gap between the first and the third date is the age of the news you decided on. On the projects we have looked at while building Verian, that number is measured in weeks, and the first gap, from happening to being written down, is usually the larger of the two.
Where the weeks go
| Stage | Typical holder | What the wait looks like |
|---|---|---|
| Happening → written down | An inbox, a site diary, a phone | The fact exists but only one person knows it |
| Written down → in the report | The planner, the cost engineer | Waiting for the cut-off, then for the write-up |
| Report → review | The calendar | A fixed meeting date |
| Review → decision | The decision-maker | Questions nobody in the room can answer on the spot |
The last wait is the one people notice, because it happens in a room with everybody watching. The first wait is invisible: a letter sitting in a procurement inbox is not late by anyone's measure, until you count from the day it arrived.
What to do with the number
Once you have the age of ten decisions, you have a baseline, and you can ask a better question than “how do we report faster”. The better question is “which facts should not have to wait for the report at all”. A delivery slip on the critical path is one. A progress update that contradicts the schedule is another. A clause deadline is a third.
That is the question the second part of this series takes up: what it looks like when those facts reach the record the day they happen, are tied to the work they affect, and wait for a person's decision instead of a meeting date.
- Count from the day a fact happened, not the day the report was dated.
- Measure ten decisions before you change anything.
- Expect the first wait, from happening to being written down, to be the largest.
- Pick the three kinds of fact that should never wait for a report.