Collection calendar

What is Collection calendar?

A collection calendar is a sequence of product decisions tied to dates, not a simple deadline list. For each milestone, record the scope being decided, the owner, the predecessor, the planned date, the expected evidence and the acceptance rule. This separates direction, development, fit, production and launch without collapsing the calendar into a line plan, collection planning or collection map.

In a fashion supply chain, the calendar makes readiness before each handoff explicit. Skills England describes the product technologist as a technical-support role in development, involving approved samples, specifications, production instructions and patterns before manufacturing. That framing gives the calendar a useful boundary: a sample date is not automatically a production date.

How should milestones and gates be structured?

Start with the collection brief and direction, then arrange design, materials and trims, sampling, review, approval and handoff. Skills England includes evaluating new designs, supporting sewn-product samples, and analysing fabric and trims against function, performance and aesthetics. In a fashion calendar, each passage can become a milestone only when it has a verifiable output and a person who can accept or return it.

A working record can use these fields: style or object, version, owner, predecessor, planned date, actual date, evidence, acceptance rule and decision. Product development and engineering should appear as a chain rather than one undifferentiated block: the production process described by Skills England runs through pattern production, cutting, manufacturing, quality checking, packing and distribution. The supplier handoff therefore does not erase what was decided at sample review.

Write the acceptance rule before the review. For a prototype, it might mean checking construction, measurements, material and finish against the approved specification; for a production handoff, it might mean checking that the instruction and pattern match the accepted version. These are governance conventions, not universal guarantees: the team must define the suitable test for the product.

How should changes, data and returns be handled?

A change to colour, material, supplier or date should open an exception decision, preserve the previous version and show the impact on later milestones. The tech pack and specification version control help keep the object, instruction and evidence connected; the calendar shows when the change must be reviewed. Do not treat an altered date as if it had been the original plan.

NIST describes PLM systems as managing product and process data throughout the life cycle so that the right information reaches the right systems at the right time. That does not make PLM an automatic authority: define which field is authoritative, who may approve it and which record prevails when systems conflict. NIST also links contextualizing manufacturing data across life-cycle phases with understanding system behaviour and satisfying traceability requirements.

Returns belong in the design. The Design Council describes the Double Diamond as testing solutions at small scale, rejecting those that do not work and improving those that do; it also stresses that the process is not linear and may return to the beginning when new learning appears. In a collection calendar, that becomes an explicit review, replan and reason-for-return route instead of a deviation silently moving to the next team.

What does the calendar not replace?

The calendar does not replace prototyping, a tech pack, sample approval, a line plan or a production plan. It organizes the order and dependencies among those artefacts; it does not decide by itself whether fit is acceptable, whether a material meets the brief or whether a supplier has the required capacity. A date without evidence is an intention; evidence without an owner does not close a gate.

A responsible implementation starts with a defined collection, line or workflow. List a small number of critical milestones, test whether each function understands the same fields, and observe where a decision returns, stalls or loses context. Then adjust the convention: simplify fields no one can interpret, and give recurring exceptions a clear rule. The useful outcome is a readable decision trail between design, development, buying, production and launch — not a fuller calendar.