Straight Answers
How Do You Rescue a Slipping Hardware Project?
Bring in one senior specialist to diagnose before you add more hands: a one-to-two-week assessment that finds the real critical path, the root cause of the slip, and the smallest scope that still ships. Then put that person on the critical path with clear authority and a written plan. Adding several people at once usually makes a late project later.
Why adding people usually backfires
- Fred Brooks observed in The Mythical Man-Month that adding people to a late software project makes it later. Hardware carries the same onboarding and communication cost, plus fab and part lead times no headcount can compress.
- Most slips trace back to a few unanswered technical questions, not a shortage of hands.
- Every new person needs time from the people who know the design best, who are usually the ones you can least spare.
The first two weeks
- Read everything: schematics, layout, repositories, open issues, test logs and the latest supplier threads.
- Reproduce the failing behavior on the bench before proposing a fix.
- List each open issue with an owner, a next action and its effect on the ship date.
- Propose a re-plan: what ships, what moves to a later revision, and the dates that follow from that.
Common root causes
- Nobody owns integration, so each discipline is 'done' and the product still doesn't work.
- Firmware was written against a dev kit and never fully run on the real board.
- Bring-up problems (power sequencing, clocks, a footprint error) were patched around rather than fixed.
- Requirements kept moving after layout or tooling had started.
- A key contractor left and took undocumented knowledge with them.
Making the rescue stick
- Give the specialist decision authority on the critical path, not just an advisory role.
- Keep one source of truth for the pin map, the BOM revision and the firmware release.
- Hold short check-ins two or three times a week until the plan is back on track.
- Plan the handoff from day one: notes, build instructions and test procedures your team can keep using.
Common questions
Secure access before anything else: source repositories, toolchain versions, build scripts, signing keys, programming procedures and any test fixtures. Then have the new engineer build the firmware from source and flash a board. Until that works, you don't know what you have.