Lesson 2: Sequencing the First Three Actions
Lesson 2: Sequencing the First Three Actions
Module 6, Lesson 2 of 3. About 12 minutes.
Orientation
A readiness position tells you where you stand. It does not tell you what to do on Monday morning. The gap between the two is where most organisations lose momentum: they produce an honest, detailed assessment, present it once, and then default back to whichever action feels most familiar, which is usually a technology conversation, because that is the layer with visible things to show for effort.
This lesson is about closing that gap by sequencing. Not a full programme plan: three actions, ordered, with a reason for the order that would survive a challenge.
Learning Objectives
By the end of this lesson you should be able to:
- M6-O2Sequence your first three actions and justify the order.
- M6-O4State what you would need from suppliers, and when to ask for it.
Why Order Is the Whole Argument
The nine stage roadmap set out in the canonical article for this lesson exists because each stage consumes the output of the one before it. Governance written before anyone has assessed the data governs data that turns out not to exist in the form assumed. An architecture chosen before ownership is settled encodes decisions nobody actually made, because no one was accountable for making them. Building before validating means finding your errors in production instead of in review. The stages are not bureaucracy for its own sake; they are gates that stop wasted effort from compounding.
For a first three actions, you do not need all nine stages. You need to identify which stage your readiness position from Lesson 1 says you are actually at, and act there, not one stage ahead of it. If your data assessment is incomplete, the correct next action is more data assessment, not a governance policy and certainly not a technology evaluation, however urgent either of those feels.
Sequencing also has to include suppliers, because supplier engagement has the longest lead time of anything in a passport programme and is the most reliably under-resourced. The question is not only what to ask for, it is when. Asking a supplier for composition data before you know which attributes you actually need produces a generic data request that gets a generic, unusable answer. Asking after you have completed your own data assessment, with a specific list, produces something that can be checked and used. The order matters as much for a supplier request as it does for internal work.
The common misreading is to treat sequencing as a scheduling exercise, something a project manager does after the real decisions are made. It is the opposite: the order is itself the technical judgement. Two organisations with an identical readiness position can be given the same three candidate actions and only one of them will have put them in an order that actually works, because the wrong order means the first action has to be redone once the second one reveals what it should have assumed.
A tieback framework setting out nine gated stages, from regulatory and product scope through information requirements, data and source assessment, governance, target architecture, build, validation, pilot and operation, each with an explicit exit gate, plus feedback loops back to earlier stages when later work exposes what earlier work missed.
Use it when you have more than one plausible next action and need to justify which one comes first, or when a stakeholder wants to skip ahead to build before an earlier gate has been passed.
Where it fails: it is not a waterfall promise. Real programmes revisit earlier stages repeatedly, and the framework says so explicitly. Do not use it to argue that a stage, once passed, can never be reopened; use it to argue that skipping a gate without evidence is the actual risk.
Read the first two phases in full, covering scope, information requirements, data and source assessment, governance and target architecture. These four stages are where a first three actions should almost always be drawn from.
Read: How to Build a Digital Product Passport Implementation Roadmap (15 min read)
Sections that carry this lesson:
- Phase 1: Define
- Phase 2: Prepare
The article is the source of record. Where this lesson and the article differ, the article is correct.
The Lesson 1 position found: three conflicting identifiers across three systems, unrequested composition data at the contract manufacturer, and a QR pilot that resolves only to a marketing page.
Action one: reconcile the three identifiers to a single agreed model level identifier, with a named owner. This is prerequisite to everything else. No later action means anything if the systems cannot agree what product they are even describing.
Action two: complete the attribute inventory for the S2, marking each attribute’s source, owner and confidence, including the battery pack and the textile strap separately, since they may carry different requirements. This has to follow identifier reconciliation, because an inventory built against three different identifiers cannot be reconciled itself.
Action three: only once the inventory names the specific gaps, approach the contract manufacturer with a specific, bounded request for battery composition data, rather than an open-ended one. Asking this before the inventory exists would produce a request nobody could act on and would spend the relationship’s goodwill on the wrong question.
The QR pilot is left alone. It is proven, it is cheap to leave as is, and rebuilding it now would be effort spent one stage ahead of where the S2 actually stands.
Using the readiness position you wrote in Lesson 1, list three candidate actions. Order them, and write one sentence for each transition explaining why it could not usefully come earlier. Then write the one sentence you would send to a supplier, and state at which of the three actions you would send it, not before.
Knowledge Check
4 questions. Feedback is immediate, nothing is graded, and this does not gate your progress.
Takeaways
- Sequencing is not administration: the order is itself the technical judgement, because doing a stage out of order forces it to be redone.
- Act at the stage your readiness position says you are actually at, not one stage ahead of it.
- Supplier requests should follow your own inventory, not precede it, so they are specific and checkable.
- Leaving a proven, low-value component such as a working carrier alone is a legitimate sequencing decision, not neglect.
If you remember one thing: the wrong order does not just slow a programme down, it makes the first action worthless once the second one runs.
Sources
How to Build a Digital Product Passport Implementation Roadmap, sections Phase 1: Define and Phase 2: Prepare, and How Should Organisations Prepare for Digital Product Passports?, section Preparing Supplier Collaboration.
Module 6 · Lesson 2 of 3
Checking this device for saved progress.
Previous: Taking a Readiness Position
Progress is saved on this device.