Go/No-Go Checklist for New PMs Running Hardware Projects
When forecasts on a hardware project are wrong in the same direction every time, a structured go/no-go checklist exposes the bias before sign-off. A moderate-rigor list for new project managers.
When every estimate skews the same way, your gate is the corrective
Hardware projects don't fail because forecasts are wrong. They fail because forecasts are wrong in the same direction, every time, and the gate doesn't catch it.
New project managers running hardware or construction projects in mid-size companies inherit a problem they didn't create: estimates from the project team almost always skew optimistic in the same way. Lead times are underestimated, integration effort is underestimated, regulatory cycles are assumed to start later than they should. The estimation pattern is consistent enough that you can build a checklist around it.
This go/no-go checklist is not a generic gate. It's structured to expose the specific places where hardware estimates are systematically biased. Walk through it before sign-off. If three or more boxes are unchecked, the project isn't ready to start — regardless of how committed the team feels.
Hardware go/no-go checklist
0 / 10- Lead times stated as ranges, not points. Every component lead time is a range with explicit best/worst case. If any are point estimates, send them back.
- Long-lead items have dual sourcing or documented single-source risk. Single-source items are flagged with mitigation cost.
- Integration effort estimated separately from build effort. Integration is the most consistently underestimated phase.
- Regulatory and inspection cycles in calendar weeks, not project weeks. Calendar weeks include inspector availability, not just submission dates.
- Site readiness tied to a calendar date, not a project milestone. If site readiness is 'when the team is ready,' the schedule is fictional.
- Contingency calculated as a percentage of cost AND of schedule. Both. Schedule contingency is more often missing than cost contingency.
- Risk register includes at least one risk that, if realized, would justify going no-go. If every risk is mitigatable, the register is too soft.
- Sponsor has signed an explicit acknowledgement of the worst-case schedule. The worst case, signed, in writing.
- Resource availability is tied to specific named individuals for the first 60 days. Not 'we have the resources.' Names with date ranges.
- A no-go threshold is documented. What single condition would cause this project to be paused? If you can't answer, the gate isn't real.
- T-30 days from gateRun the checklist as a draftPM walks through items with the project team. Capture the unchecked items as questions to resolve, not as blocks.
- T-14 daysResolve the unchecked itemsEach unchecked item has a named owner and a target date. Sponsor sees the list with progress.
- T-7 daysGate dry runSteering pre-read includes the completed checklist. Items still unchecked are flagged with cost-of-not-resolving.
- Gate dayDecisionSteering decides go, conditional go, or no-go. Conditional gos have a named date for the next checklist review.
“First time I walked a steering committee through this checklist, three boxes were red. The committee approved anyway, and all three issues hit us by month four. Second project, same checklist, same three red boxes — committee actually paused the project. That was the gate working.”
| Criterion | Green (go) | Yellow (conditions) | Red (no-go) |
|---|---|---|---|
| Long-lead components | Ordered with margin | Ordered, no margin | Not yet ordered |
| Permitting status | Issued | In review | Not filed |
| Lead specialist booked | Confirmed for full window | Confirmed for partial window | Tentative or unconfirmed |
| Estimation pad | ≥20% on schedule | 10–20% | <10% |
| Dependent contractor lock-in | Signed | LoI only | Verbal only |
The point of a structured checklist is not to make the gate harder. It's to make the gate honest. Optimism in hardware estimation is rational at the individual level — engineers want to build things, sponsors want to fund them — and disastrous at the portfolio level when it's the same optimism every time. The checklist lets the gate hold the line that no individual on the project can hold alone.
For the same pattern in different settings, see the retrospective version on creative work and the executive software view.