TNA Tracking Best Practices: From Spreadsheet to Platform

A Time and Action calendar works when it tracks dependencies rather than dates. Most spreadsheet TNAs fail because they list milestones in isolation, so when fabric arrives four days late nobody recalculates the downstream dates — and the slip is only discovered at the ex-factory deadline. The fix is to define which milestones block which, assign a single owner to each, and make the plan visible to the people who cause the delays.

What a TNA is actually for

A Time and Action calendar works backwards from a delivery date through every milestone required to hit it. Its purpose is not documentation. It is early warning — knowing in week three that a week-eleven date is at risk, while there is still time to act.

Judged against that purpose, most TNAs fail. They record what was planned and, later, what happened. They do not tell anyone in week three that week eleven is in trouble.

Why the spreadsheet version breaks

Dates are static, reality is not

A spreadsheet TNA has a planned date and an actual date. When fabric lands four days late, someone types the actual date. Nothing else moves. Every downstream date still shows its original plan, so the calendar now displays a schedule that cannot happen — and it looks fine.

This is the core defect. Without dependencies, a slip is recorded but not propagated.

Nobody owns a milestone

"Fabric in-house" sits in a row with no name against it. When it slips, the merchandiser chases the supplier, the supplier says it shipped, and three days pass before anyone establishes what actually happened.

The factory cannot see it

The TNA lives on the brand's drive. The factory has its own plan. When the two diverge — and they always do — nobody notices until a status call.

It only updates when someone remembers

A TNA updated weekly gives you a warning that is up to seven days stale. On a compressed timeline that is the entire buffer.

Six practices that actually work

1. Model dependencies, not dates

Each milestone should record what must finish before it can start, and how many working days it needs. Then a slip recalculates everything downstream automatically, and the question becomes "which milestones just went critical?" rather than "is anything late?"

2. One named owner per milestone

Not a department. A person, on one side or the other, who is accountable for that date and who gets the alert when it is at risk.

3. Alert before the deadline, not after

An alert on the day a milestone is missed is a status report. An alert three days before, triggered because the preceding task has not started, is a chance to act. Set thresholds by milestone criticality.

4. Share the same plan with the factory

One calendar, both parties, same view. Most TNA disputes are not disagreements about what happened — they are two teams working from different plans and discovering it late.

5. Track the critical path explicitly

Not every milestone matters equally. Fabric in-house, sample approval and production start usually sit on the critical path; a slip there moves delivery one-for-one. Label them and treat them differently.

6. Record why, not just when

A reason code on every delay turns a season of order histories into a diagnosis. If 40% of your delays trace to sample approval, the problem is in your own approval process, not the factory's.

A workable milestone set

Moving off the spreadsheet

1. Take your last three completed orders and note where each actually slipped.
2. Build a milestone template from what those orders really required — not a generic list.
3. Add dependencies and durations from the same historical data, so estimates are grounded.
4. Assign an owner to every milestone, on both sides.
5. Run one live order in parallel — old spreadsheet and new plan — for a single season.
6. Add reason codes, and review them at season end.

A TNA that tells you a date has been missed has already failed. Its job was to tell you the date was at risk.