What is a connected planning implementation?

It is the work of moving a commercial workflow off manual handoffs and onto one shared record, one transfer at a time. It is not a software installation: the hard parts are agreeing definitions across two teams and deciding who owns the number once the handoff disappears. The software is the easy half.

How long does a connected planning implementation take?

The honest answer is that it is measured in planning cycles, not calendar blocks, because the unit of proof is a season doing what a season does. One seam can be named, cleaned, parallel-run, and cut over inside a single planning cycle — that is the shape to aim for. Any implementation plan that promises a fixed number of weeks without seeing your data is quoting a configuration timeline, not an adoption one.

Who should own a connected planning implementation?

One person on the business side. The title matters less than the test: pick whoever already gets asked to explain the outcome when that transfer produces a bad number — usually a merchandising or planning leader. That accountability exists before the project does, and ownership should follow it rather than be invented alongside it. IT or a PMO can run the build, but neither can settle the commercial trade-offs the work surfaces, and those are what stall it. A senior sponsor is a separate, narrower job: protect the work through its first bad week.

Do we have to clean all our data before we start?

No — only the data the first seam carries. Cleaning everything is how implementations stall before they produce anything. Scope the cleaning to the fields that actually move across the transfer you picked, and let each subsequent seam pay for its own cleaning when its turn comes.

When in the season should we start?

Time the start against the seam rather than the calendar — apparel seasons overlap, so no month is quiet for every team at once. The window opens just after the transfer you picked has happened and closes when it comes round again: a full cycle to name the seam, settle the definitions, and be ready to run the parallel the next time the transfer occurs. Post-season is the other natural entry point, with the reconciliation pain fresh and real numbers to test against. Starting in the week a buy is being finalized does not work — it puts the parallel run on the person already under the deadline, which is how the parallel quietly gets skipped.

// Resources · Playbook

A connected planning implementation playbook for apparel brands

A connected planning implementation succeeds or fails on sequence and ownership, not on software. Run it as six phases against a single seam, with one named owner per phase and a definition of done that somebody can hold up — rather than as a program against the whole workflow.

This is the execution half of the argument. The operating model assessment tells you which seam to connect; the ROI of connected apparel workflows tells you what closing it is worth. This page tells you how to run it.

How to run it

Run a connected planning implementation against one seam at a time, in six phases. Name the seam and give it a single owner. Clean only the data that seam carries. Run the connected seam in parallel with the file it replaces for one full cycle, reconciling every variance. Cut over on one real, consequential decision. Retire the parallel file on a date, with an owner. Then extend to the adjacent seam. The first planning cycle buys you one connected seam and a team that trusts it; the compounding starts in the second, once two connected seams touch.

Definition — Connected planning implementation: A connected planning implementation is the sequenced work of moving each handoff in an apparel brand’s commercial workflow — plan into buy, product into plan, buy into PO, production back into plan — from a manual transfer between files onto one shared record. It is scoped by seam rather than by department, and its unit of progress is a transfer that no longer needs a person to carry it.; Used by: Planning, merchandising, and buying leaders sponsoring or running the work; Related: Operating model assessment, workflow seams, apparel operating system

// The governing rule

One seam, not a program

The single decision that determines how this goes is scope, and it is made before phase one. A seam is one transfer between two teams — the OTB the buy is sized against, the size curve that carries from the assortment into the PO, the confirmed delivery date that has to reach the plan. A program is “connected planning,” which nobody can finish, nobody can own, and nobody can prove. Scope by seam and the work becomes falsifiable: either the transfer still needs a person to carry it, or it does not.

// The six phases

Six phases, run against one seam

Each phase has a goal, one owner, and a condition that says it is finished. Every phase but the last is part of one complete pass over a single seam; the last one starts the pass on the seam beside it. Do not run two phases concurrently to save time — the parallel run is worthless if the data underneath it is still being cleaned, and the cut-over means nothing if the parallel never reconciled.

Name the seam and give it one owner

Reduce the whole idea of connected planning to one named transfer between two teams, so there is something specific enough to finish. "Connect planning and buying" is not a seam; the OTB that the buy is sized against is.

Who owns it: The planning or merchandising leader who owns the number on the downstream side of the seam. One named person, not a steering committee.
Done when: The seam is written down in a sentence, one person owns it, and the teams on both sides agree that is the transfer that hurts.

Clean what the seam carries

Fix the inputs before you connect them. A connected seam propagates whatever it is given, at speed, including the defects — so the definitions have to be settled first, for this seam and no others.

Who owns it: The data owner upstream, with the downstream team defining what correct means. The downstream team gets the veto, because they are the ones who will act on it.
Done when: Every field the seam carries has a named owner and one agreed definition, and both sides roll to the same totals without a translation file in between.

Run it in parallel for one full cycle

Produce the number twice — once through the connected seam, once through the file it will replace — and reconcile every variance. Parallel running is not caution; it is how the seam earns the right to be believed.

Who owns it: The planner or buyer who does the work today. If an implementation team runs the parallel instead of the operator, you have tested the software and learned nothing about the workflow.
Done when: The two agree, or every difference has an explanation — and in the explained cases the connected version is the one you would rather have acted on.

Cut over on one real decision

Make a consequential decision on the connected record only. A pilot that never commits anything proves nothing; nothing validates a seam like putting money through it. Pick a decision that matters but is survivable — one class, one channel, one drop.

Who owns it: The seam owner, with explicit air cover from the executive who sponsored the work, so a first-cycle wobble does not end the program.
Done when: A real buy, reforecast, or allocation was committed off the connected record, and nobody rebuilt the old workbook afterwards to check it.

Retire the parallel file on purpose

Retire the file the seam replaced, on a date, rather than letting it fade. This is a decision somebody makes and announces; it does not happen by attrition.

Who owns it: The seam owner, who has to be willing to say the file is gone and mean it.
Done when: The file is archived read-only, its scheduled updates are cancelled, and every report that pulled from it now pulls from the connected record.

Extend to the adjacent seam

Take the next transfer immediately upstream or downstream of the one you closed, and repeat the five phases. Adjacency is the whole point: two connected seams that touch compound, while two connected seams with a manual gap between them are just two islands.

Who owns it: The same owner where the seams share a team; a new named owner where they do not, with the first owner running the handover rather than a document.
Done when: The two seams share one record end to end, with no export, no re-key, and no reconciliation step surviving in the middle.

// Data prerequisites

What each seam needs before you connect it

Cleaning what the seam carries is scoped to one row of this table, not the whole table. Clean the seam you picked; leave the rest until its turn.

Data prerequisites, common defects, and the test for each workflow seam
Seam	What it carries	The defect that shows up	How you know it is clean
Product into the plan	Style-color list, size range, target cost, target retail, delivery month	Styles in the workbook that no longer exist in the product system, and colorways dropped weeks ago	Every planned style resolves to a live product record, and the counts match with no manual exceptions list
OTB into the buy	Season calendar, class hierarchy, opening inventory, planned receipts by month	The class hierarchy in the plan does not match the one on the buy sheet	Both sides roll to the same class totals with no mapping file in between
Size curve into the buy	Curves by class, by channel, and by region	One house curve copied across classes that do not sell alike, or a wholesale curve applied to DTC	Every class-and-channel pair names its curve, its source, and its owner
Buy into the PO	Vendor master, cost basis, terms, delivery window, ship-to	Vendor names spelled three ways, and two cost bases in play — landed on one side, FOB on the other	One vendor master and one agreed cost definition, signed off with finance
Production back into the plan	PO milestones, confirmed dates, revisions, cancellations	A delivery change lives in an email thread and never reaches the plan that assumed the old date	A confirmed date change updates the plan without anyone retyping it

Product into the plan

What it carries: Style-color list, size range, target cost, target retail, delivery month
The defect that shows up: Styles in the workbook that no longer exist in the product system, and colorways dropped weeks ago
How you know it is clean: Every planned style resolves to a live product record, and the counts match with no manual exceptions list

OTB into the buy

What it carries: Season calendar, class hierarchy, opening inventory, planned receipts by month
The defect that shows up: The class hierarchy in the plan does not match the one on the buy sheet
How you know it is clean: Both sides roll to the same class totals with no mapping file in between

Size curve into the buy

What it carries: Curves by class, by channel, and by region
The defect that shows up: One house curve copied across classes that do not sell alike, or a wholesale curve applied to DTC
How you know it is clean: Every class-and-channel pair names its curve, its source, and its owner

Buy into the PO

What it carries: Vendor master, cost basis, terms, delivery window, ship-to
The defect that shows up: Vendor names spelled three ways, and two cost bases in play — landed on one side, FOB on the other
How you know it is clean: One vendor master and one agreed cost definition, signed off with finance

Production back into the plan

What it carries: PO milestones, confirmed dates, revisions, cancellations
The defect that shows up: A delivery change lives in an email thread and never reaches the plan that assumed the old date
How you know it is clean: A confirmed date change updates the plan without anyone retyping it

// The two-season split

What the first season gets you, and what the second one does

The first cycle through a connected seam is mostly about trust, and that is the correct use of it. The team is still checking the connected number against the file it replaced, which looks like duplicated effort and is actually how the seam becomes believable to the people who commit money through it. The first-season return is narrow and real: the reconciliation work at that one transfer stops, and decisions that used to wait for someone to refresh a file get made when they arise. What the first season cannot deliver is compounding — one connected seam still sits between two manual ones, so the connected middle can only be as current as its inputs.

The second season is where the shape changes. With two or three adjacent seams on one record, a change stops being routed and starts propagating: a cost move reaches the margin, a delivery slip reaches the plan, a curve revision reaches the PO, and nobody carries any of it. Plan the first cycle for proof and the second for reach — reversing those is the most common way a technically successful implementation fails to change anything.

// Failure modes

Five ways this goes wrong

None of these are software problems, which is why buying differently does not prevent any of them. Each is a scoping or ownership decision made before the first phase, and each is cheap to correct if it is named early and expensive once a season has been run on it.

The big-bang rollout

Connecting every seam at once puts every team on a new way of working in the same season, and no single result comes out clean enough to point at. When something goes wrong — and something does — nobody can attribute it, so the whole program gets slowed instead of the one seam that needed rework.

The program with no single owner

A steering committee owns a connected seam the way three people own a dog. The decisions this work forces are commercial — whose class hierarchy wins, which curve is right, who signs off on the cost basis — and a committee escalates those while a named owner settles them in the meeting.

Migrating dirty size curves

Connect a curve that was never really decided and you have automated a bad assumption at speed, then blamed the result on the system. Curves get decided by class and channel before they get connected, not after.

Connecting the seam nobody complained about

The loudest seam and the most expensive seam are frequently different. The loud one is where somebody visibly does painful work every week; the expensive one is where a decision gets made on stale data and the cost surfaces a season later as markdown. Complaint volume is a poor proxy for cost — score the seams before picking one.

The parallel file that never dies

A workbook kept just in case does not stay a backup. Within a cycle it is a competing version of the season, the team is quietly reconciling against it again, and the connected record never becomes the one people act on.

// What done looks like

How to tell the implementation is actually finished

Done is not go-live, and it is not a training completion rate. The checklist is already above: the done-when conditions on phase 04, “Cut over on one real decision”, and phase 05, “Retire the parallel file on purpose”. The test underneath them is behavioural. If a planner still exports to verify, the seam is not done — it is running in parallel with a shadow owner, and it will drift back the first time the season gets busy. That test matters more than the technical one, because the technical part was finished at cut-over and the behavioural part is what determines whether the margin and the time actually come back.

// How RetailNorthstar fits

How RetailNorthstar fits

RetailNorthstar is built to be adopted seam by seam rather than all at once: line plan, open-to-buy, assortment, buy plan, size curves, purchase orders, production visibility, and allocation on one shared data model, with AI-assisted planning working on that record instead of a copy of it. Because the model is shared rather than integrated, closing one transfer does not require closing the next — which is what makes the phase sequence above runnable without a rip-and-replace. To see which stack you are starting from, compare the Apparel OS with PLM and spreadsheets together, or read the full Apparel OS overview.

// Summary

Scope a connected planning implementation by seam, not by department — one transfer between two teams, with a definition of done somebody can hold up.
Each phase ends on a stated condition rather than a date, and the final test is behavioural: a seam whose numbers people still check by hand has not been adopted, whatever go-live said.
Every seam has its own tell for clean data — matching class totals on both sides of an OTB, a named curve and owner for each class-and-channel pair, one agreed cost basis before a PO goes out.
Parallel running is where the trust is earned — every variance between the connected seam and the file it replaces gets reconciled rather than waved through, for one full cycle before anything is cut over.
The failure modes are organizational, not technical — big-bang scope, no single owner, dirty size curves migrated forward, the wrong seam picked, and a parallel file that never dies.

// Related resources

See it in RetailNorthstar →

// FAQ

Frequently asked questions

What is a connected planning implementation?: It is the work of moving a commercial workflow off manual handoffs and onto one shared record, one transfer at a time. It is not a software installation: the hard parts are agreeing definitions across two teams and deciding who owns the number once the handoff disappears. The software is the easy half.
How long does a connected planning implementation take?: The honest answer is that it is measured in planning cycles, not calendar blocks, because the unit of proof is a season doing what a season does. One seam can be named, cleaned, parallel-run, and cut over inside a single planning cycle — that is the shape to aim for. Any implementation plan that promises a fixed number of weeks without seeing your data is quoting a configuration timeline, not an adoption one.
Who should own a connected planning implementation?: One person on the business side. The title matters less than the test: pick whoever already gets asked to explain the outcome when that transfer produces a bad number — usually a merchandising or planning leader. That accountability exists before the project does, and ownership should follow it rather than be invented alongside it. IT or a PMO can run the build, but neither can settle the commercial trade-offs the work surfaces, and those are what stall it. A senior sponsor is a separate, narrower job: protect the work through its first bad week.
Do we have to clean all our data before we start?: No — only the data the first seam carries. Cleaning everything is how implementations stall before they produce anything. Scope the cleaning to the fields that actually move across the transfer you picked, and let each subsequent seam pay for its own cleaning when its turn comes.
When in the season should we start?: Time the start against the seam rather than the calendar — apparel seasons overlap, so no month is quiet for every team at once. The window opens just after the transfer you picked has happened and closes when it comes round again: a full cycle to name the seam, settle the definitions, and be ready to run the parallel the next time the transfer occurs. Post-season is the other natural entry point, with the reconciliation pain fresh and real numbers to test against. Starting in the week a buy is being finalized does not work — it puts the parallel run on the person already under the deadline, which is how the parallel quietly gets skipped.

// The cost of disconnected work

Disconnected workflows do not just slow teams down — they create planning risk, margin leakage, and late decisions.

See the connected operating model →Build the business case →