How Do You Build a Bag Production Schedule With Milestones You Can Audit?

There is a difference between a schedule and a promise, and it is visible in the number of columns. A promise has one date and an implied assurance. A schedule has a row per milestone, and each row names who owes what and what the evidence is. This piece is about building the second kind from scratch, using a 500-piece bag programme as the worked case, and about the three mistakes that turn a schedule back into a promise.

What Is a Milestone, as Opposed to a Stage?

A stage is work. A milestone is a decision about work, and the distinction matters because only milestones can be late in a way anybody can argue about. "Sewing" is a stage: it takes as long as it takes and nobody can say precisely when it finished. "First-off check signed" is a milestone: it has a date, a document and a person, and it either happened or it did not.

This is why a schedule built from stages is unenforceable and a schedule built from milestones is not. When a buyer asks why the goods are late, the answer from a stage-based schedule is that sewing took longer, which cannot be checked. The answer from a milestone-based schedule is that the first-off check signed four days late, which can.

Who Owns Each Milestone, and Why Does That Matter?

Two owners, and the split is not the obvious one. The programme desk owns everything that happens inside the run: material release, first articles, gates, inspection and booking. The buyer owns the three decisions that gate the run: sample approval, shade approval and any change after approval. Every schedule that goes wrong does so at an owner boundary, because each side assumes the other has acted.

The three buyer-owned milestones are the ones to put a calendar reminder on. A shade approval left unanswered for four days is four days on the critical path, and it is the single most common avoidable delay in a custom programme. Naming the owner in the schedule converts that from a delay into a missed commitment, which is a different conversation.

There is a fourth column most schedules omit and which turns out to matter more than the date: the dependency. Every milestone except the first waits on something, and naming the dependency is what makes a schedule computable. A buyer who knows that the pre-production sample depends on bulk material being in the store can tell, from a single late mill confirmation, which three milestones downstream have already moved.

How Much Float Should Each Milestone Carry?

Float is the number of days a milestone can slip without moving the final date, and most schedules have either none or an imaginary amount. Three of the nine milestones above carry no float at all: sample approval, shade approval and the final inspection report. Those three are on the critical path by definition, and a day lost on any of them is a day lost on the shipment.

The others carry between one and four days, and the honest way to use float is to spend it deliberately rather than to discover it was spent. A buyer who knows the hardware first article has four days of float can accept a small delay there without conceding anything. A buyer who does not know will either panic or concede a week for nothing.

How Do the Two Owners Divide the Work?

The split determines who has to chase whom, and it is worth writing down because it is counter-intuitive. The party promising the date owns most of the rows, but the party holding the date owns the three that carry no float. In practice that means the buyer is the critical path on a custom programme for roughly the first three weeks, and then the production side is for the remainder.

The practical reading of that table is uncomfortable and useful: on a custom programme the buyer is the critical path at the start. A tech pack sent complete, a sample approved within two days of receipt and a dip answered the day it arrives are worth more than any amount of pressure applied in week five, and they cost nothing but attention.

What Is the Consequence Column For?

It is the column that turns a schedule into an agreement. Every row needs an answer to the question: if this slips by a week, what happens. For most rows the answer is a revised date. For three of them — material release, shade approval and the inspection report — the answer should be a named remedy, because those are the rows where a slip costs more than the slip.

The remedy does not have to be financial to work. A per-week remedy on a named milestone, a re-planned schedule issued within a stated number of days, or a written escalation to a named person are all sufficient. What does not work is a consequence that only attaches to the final date, because by the time the final date is missed nothing can be done about it and the clause has no force.

What Are the Three Mistakes That Turn a Schedule Back Into a Promise?

1. Writing stages instead of milestones. "Sewing: days 22 to 38" cannot be late in a checkable way. "First-off checked: day 25" can.
2. Leaving the buyer-owned milestones undated. Approval, shade sign-off and change decisions are the three rows most often left open, and they are three of the four with no float.
3. Omitting the artefact column. A milestone with no document is an assurance. Ask what you will receive, and put it in the row before the order is placed rather than after.

The third mistake is the one that costs the most, because it is invisible until it is needed. A schedule with eight milestones and no artefacts reads perfectly well for six weeks and then produces nothing to argue with in week seven. Writing the artefact into the row costs nothing at the point the schedule is built and is the only thing that makes the row worth having later.

How Do You Build One for Your Own Order?

Start from the end and work backwards, in five steps. Fix the date the goods have to be on board. Subtract the transit your Incoterm leaves with you. Subtract the booking leg and the inspection window including its re-check branch. Subtract the production block. Whatever remains is the last date the sample can be approved, and everything before that is sampling and tech pack.

Then forward-fill the milestones into that space with their artefacts and their owners, and check the float. If a milestone you care about has no float and a milestone you do not care about has five days, the schedule is wrong rather than unlucky, and the fix is to re-sequence before the order is placed rather than to negotiate after.

How Does a Schedule Behave When It Is Working?

Quiet, and that is worth saying because buyers often read silence as neglect. A schedule that is working produces its artefacts on their dates and nothing else needs to be said about it. The mid-run tally arrives on day 32 with four minor defects and one major, the report arrives on day 38 with an accept decision, and the booking note arrives on day 41 with a cut-off on day 44.

The signal that a schedule is failing is not a missed date. It is a change in the character of the updates: dates replaced by assurances, artefacts replaced by photographs that prove nothing, and the phrase "on track" appearing where a number used to be. Those three appearing together in week four predict a late shipment better than any single missed milestone.

What Does the Float Tell You About Compression?

That it is finite and it is spent in a specific order. A schedule has sixteen days of float across its rows, and compression consumes the float on the easy rows first and then starts removing stages. Once the float is gone, a further request for speed is not a request for the same schedule run faster; it is a request for a different specification, and it should be answered as one.

This is the honest way to handle a buyer who needs a date the schedule cannot reach. The answer is not to agree and hope. It is to show which rows have float, spend them explicitly, and then state which stage would have to come out to go further — with what that stage was there to prevent. Buyers accept that answer far more readily than a promise that quietly removes a control.

Finally, the schedule needs a home and an owner on the buyer side as well. Somebody in the buying organisation has to hold the current version, read the weekly artefact against it and escalate when float runs out. A schedule nobody on the buyer side owns is a document the production side updates, which is a polite way of describing a promise.

How Should the Schedule Be Kept Alive During the Run?

Version the schedule

Every revision carries a number and a date, and the current one is the only one anybody quotes

Re-issue after every slip

A slip produces a new schedule within a stated number of days, not a verbal assurance

Report by artefact

Weekly updates name the document produced, not the percentage complete

Escalate at the float boundary

When float on a milestone is exhausted, the escalation is automatic rather than requested

Record changes in writing

Any change to artwork, material or hardware restarts the clock from the date of the change

The fifth rule is the one that gets tested, because a change request rarely arrives at a convenient moment. It arrives in week four, when the run is half sewn and the buyer has seen a competitor product. The rule does not say the change cannot be made; it says the change restarts the clock from its own date, in writing, which is the only version of the conversation in which both sides know what was agreed.

Five rules and the schedule survives contact with a real order. We do not promise the fastest 20 days. We promise a delivery date you can calculate. A schedule built this way is the calculation, and the five rules are what keep the calculation true after week one.

Frequently Asked Questions

People Also Ask