The calendar nobody argues with

Forty orders and one calendar

Course 7.1 builds a critical path for one order. A critical path is the chain of steps that decides when the order ships. That course finds two days of float in the chain. Float is spare time: days you can lose without shipping late.

This course is about what happens to that calendar afterwards. Now there are forty of them. They all live in one system. Eleven people type into them for four months. A calendar built once is a document. A calendar that is kept up to date is a working instrument. Almost nothing in this course is about building one.

Thelawatte Knitwear runs three knit plants. It has about forty live export orders at any moment. Every order is built from the same template of 34 milestones: dips, strike-offs, yarn, fabric ex-mill, fabric in-house, trims, size set, pre-production sample, cut, load, inline, sewing complete, packing, inspection, clearance, gate-in, on board. Forty orders times 34 milestones is 1,360 live rows. Ruwanthi Devanayake, the group's planning manager, owns all of them.

On the first Monday in July she does something nobody had done before. Instead of reading the calendar, she measures it.

Read the last two rows first. Just over 31% of orders missed their ship date. That is not unusual for a knit programme with imported trims. Now read the two rows above them. In thirteen weeks, across forty orders, 89 dates moved in the system. 613 moved in a spreadsheet on one person's laptop. The ratio is close to 6.9 to one.

And 34 of the 89 were not forecasts at all. They were the plan being rewritten to match something that had already happened. A fabric date was changed on 4 June to say 2 June, five days after the rolls arrived. Strip those out and the whole group revised its forward view 55 times in a quarter. That is 1.4 revisions per order over thirteen weeks, on orders with a hundred-day chain.

A calendar that is never wrong

Seeing 89 changes against 1,360 rows, you might think the plans were good. They were not. Nothing in that system was ever wrong, because nothing in it could become wrong.

Look at what the two date fields mean. The plan date is a promise. It is entered when the order is created. Changing it feels like moving the goalposts, and most people will not do it without permission. The actual date is a fact. It is written once, on the day the thing happens, and nobody disputes it. Between those two sits the only thing that really changes every week: what we now believe will happen. It has nowhere to live.

So a person who learns on 12 June that fabric will be six days late has exactly three moves. The system offers only the worst two.

Everybody chose the third move, and everybody was right to. The spreadsheet is not the villain here. It is the symptom. A factory that deletes it without adding the missing field has not fixed the calendar. It has deleted the calendar and kept the filing cabinet. Course 10.5 prices that trade properly.

Two measurements that tell you whether anyone is using it

Counting changes is a crude instrument. Course 27.3 looks at date movement from the buying office and finds the same thing from the other chair: a supplier whose milestones never move is the highest-risk order on the board, not the safest. What it could not see, standing outside the factory, is why. These two measures are the inside view. Both can be computed from a log the system already keeps.

Edit latency is the number of days between the moment somebody knew a date had moved and the moment the system was told. It needs a reference event, and there is always one: the mill's email, the forwarder's booking amendment, the lab report. Ruwanthi sampled thirty of the 89 edits and traced each back to the message that triggered it. The median gap was 19 days.

A date that is wrong for nineteen days is worse than no date at all. A blank field asks a question. A wrong field answers one. Everybody downstream planned against it, and every plan they made was silently void.

Staleness is the share of open rows whose date is in the past with nothing recorded against them. On the Monday snapshot, of the 1,360 rows, 1,006 carried an actual date and 354 were still open. Of those 354, 214 had a plan date already in the past. That is 60.5% of everything not yet done. Of the 214, 168 had been in that state for more than five days and 61 for more than thirty.

A row in the past with no actual is the system saying I do not know, in a font that looks exactly like every other row. One hundred and sixty-eight of them is not a data-quality problem. It is a calendar that has stopped being a calendar. It is now a list of dates somebody typed in April.

The third field

The repair is one column, and it is boring. That is why it takes three years to get made. Every milestone carries three dates, not two. Each one belongs to a different person and answers a different question.

Only the middle row is new, and it changes what the whole thing is for. A baseline and an actual, together, record intentions and outcomes with the entire middle of the order missing. That is perfect for arguing about afterwards and useless for running anything. The forecast is the working number. It is allowed to be wrong. It is expected to move. Moving it is the sound of somebody looking at the floor.

Thelawatte added the column in the second week of July. Over the following quarter, forecast edits went from 89 to 641. Median edit latency went from 19 days to 3. Rows sitting in the past with nothing against them went from 214 to 47.

The late-ship rate went from 31.1% to 26.7%. One quarter of one factory group is not evidence of anything. Say that out loud when you present it, because somebody will otherwise quote it back to you as a result. What the third column reliably bought was not fewer late orders. It was knowing about them earlier, which is the subject of the fourth lesson.

Act as a planning manager auditing a factory's critical-path system rather than its orders. Here is what I can extract from the system. Live orders: [NUMBER]. Milestones per order template: [NUMBER]. Period audited: [START DATE] to [END DATE]. Milestones marked complete in the period: [NUMBER]. Date changes recorded in the system in the period: [NUMBER]. Of those, how many were entered after the event had already happened: [NUMBER OR UNKNOWN]. Date changes recorded outside the system, in spreadsheets or messages, as far as I can tell: [NUMBER OR ESTIMATE]. Open milestone rows whose date is already in the past with no actual recorded: [NUMBER]. Of those, how many have been in that state more than five days: [NUMBER]. Orders shipped in the period: [NUMBER]. Orders that missed the on-board date: [NUMBER]. The date fields the system actually has, per milestone: [LIST THEM, for example plan and actual, or baseline, forecast and actual]. Work out, showing the arithmetic: the ratio of movements recorded outside the system to movements recorded inside it; the share of open rows that are stale; and how many forward-looking revisions were genuinely made once backfilled dates are stripped out. Then tell me which of these three the evidence supports: the calendar is maintained; the calendar is maintained somewhere else; the calendar is not maintained at all. If the system has only two date fields, say what a person who learns bad news is forced to do, and what the missing field would let them do instead. Do not recommend training, discipline or an instruction to use the system until you have named what the system cannot express.

What you own at the end of this lesson

Two numbers about your own calendar that you probably do not have: the median gap between knowing and recording, and the share of open rows already in the past. Neither is a number about your orders. Both are numbers about whether the instrument is switched on.

Next: what happens the moment somebody actually moves one of those dates. Who is entitled to, what the move has to carry with it, and where the six days go.