The short answer
Track each long-lead part as its own work item in Jira with three dates: when the build needs it, the latest date to order it (needed-by minus the quoted lead time), and the supplier's committed date. Link it with "Blocks" to the build and the work that waits for it. When an order-by date passes or a committed date moves, the builds and sprints that depend on it show the risk straight away.
Why do long-lead parts get lost?
Parts usually live in a purchasing spreadsheet or a PLM, while the work that depends on them lives in Jira. When a supplier moves a date, the person who hears about it updates the spreadsheet, and the firmware team finds out when the boards don’t arrive.
The second way they get lost is quieter: a design change. If a footprint or a part number changes after the order went out, the lead time can start again, and nobody connects the change request to the build date.
How do you set it up in Jira?
- A Part work type for anything with a lead time that can move a build: its name, supplier, quoted lead time, a link to the PLM or ERP record, and the revision the supplier has confirmed.
- Three dates on every part. Needed-by (from the build), order-by (needed-by minus lead time) and the supplier’s committed date.
- “Blocks” links from the part to the build milestone and to the work that can’t start without it.
- Two automation rules. A Jira Automation rule flags the part and notifies the build owner when the order-by date passes with no purchase order, and another when the committed date moves past the needed-by date.
- A link to design freeze. Tie the parts for each build to that build’s freeze point, so a change request after freeze shows which orders it touches.
- One view per build: parts still open, their dates, and what they block.
| Field | Example | Why it matters |
|---|---|---|
| Needed-by | 3 Mar, DVT build | Set by the build plan |
| Lead time | 16 weeks | From the supplier’s quote |
| Order-by | 11 Nov | Latest date the PO can go out |
| Committed date | 24 Feb | What the supplier promised |
| Status | PO sent / confirmed / shipped | Shows where it is |
What changes for the team?
Sprint planning starts with the parts view: what’s arriving, what’s late, what to pull forward. A slip is visible on the day it happens, when there’s still time to re-plan, swap a part or move scope to the next build.
If disciplines plan in separate spaces, the basic timeline won’t draw the links between them. Jira Plans (Premium and Enterprise) or Gatecast for Jira, our app, puts parts, builds and sprints on one timeline.
The Hardware Stage-Gate Readiness Check: 18 questions, about six minutes, your score right away.
Questions people ask
Should parts live in Jira or in our PLM?
The part record belongs in your PLM or ERP. Jira holds what the delivery teams need to plan: the part, its dates and what it blocks. Link to the PLM record rather than copying it.
How do you calculate an order-by date?
Start from the date the build needs the part on site, subtract the supplier's quoted lead time and any buffer for shipping and incoming inspection. The result is the latest date a purchase order can go out without moving the build.
Can Jira show parts across several team spaces?
The basic Jira timeline only shows "Blocks" dependencies within a single space. For a view of parts, builds and sprints across several spaces, use Jira Plans (in Premium and Enterprise), a dashboard built on a filter, or an app.