Managing a hardware development project comes down to four habits: define milestones as inspectable deliverables rather than percentages, know which items are genuinely on the critical path (usually lead times, not engineering), plan for multiple design iterations instead of one, and price every change request in time, money, and what it displaces. Do those four things and schedules become predictable. Skip them and the project slips in a way that surprises nobody except the people paying for it.

Why hardware schedules slip

Almost never because someone worked slowly. Nearly always one of three causes: requirements kept moving, supplier lead times were assumed at best case, or an unplanned design iteration was needed. Hardware differs from software precisely here — you cannot compress it by adding engineers. A mold takes as long as a mold takes, boards arrive when they arrive, and a test lab has a queue.

Gates that mean something

Break the program into milestones that each end in an artifact you can look at:

  • Requirements frozen — a signed specification. The single highest-return milestone in the whole program; see how to write a product requirements document.
  • Architecture and make-vs-buy — module breakdown, key component selections, and what gets developed versus bought off the shelf.
  • Proof-of-concept build — proves feasibility, not appearance. See proof of concept vs prototype.
  • Full functional prototype — every function working in near-final housing.
  • Design validation — environmental, drop, and pre-compliance testing against the specification.
  • Production release — a complete manufacturing data package plus tooling ordered.
  • Pilot run and first-article inspection before volume is authorized.

These map onto the industry's EVT, DVT, and PVT vocabulary, which is worth adopting because suppliers and investors already speak it.

The critical path is mostly waiting

On most hardware programs the critical path is not engineering labor, it is queue time: injection mold fabrication, long-lead semiconductor delivery, a slot at a certification lab, ocean freight. Ordering a long-lead component is often the decision that fixes your launch date, which is why it gets made as early as defensibly possible — sometimes before the surrounding circuit is final. Two schedule traps worth naming explicitly: certification lab capacity, and the annual Lunar New Year shutdown at Asian factories, which swallows weeks of calendar every cycle (see Chinese New Year production shutdown and injection mold lead time).

How many iterations to plan

The honest number from experience is three. A first PCB revision that works perfectly is rare; a mold that needs no correction is unusual. A plan built around one iteration will slip with certainty. A plan built around three finishes in two and looks like a success. Say this out loud at kickoff, alongside the budget picture in what it costs to develop a new product, and nobody feels misled later.

Where to put the buffer

The common mistake is sprinkling a twenty percent pad on every task. It does not survive contact with reality, because each task quietly expands to fill whatever time it was given. What works is estimating each task honestly and pooling all the contingency into a single buffer at the end of the phase. Then you can watch how much buffer has been consumed against how much scope remains — a far better health indicator than a percent-complete number, which is unfalsifiable and therefore useless.

Change control in three numbers

Change is legitimate. Unpriced change is destructive. The rule is simple: every change request gets answered with three numbers — how much time it adds, how much it costs, and what it pushes out. The formal mechanism is the engineering change order process. Clients who see all three numbers make better decisions, and in our experience voluntarily drop about half their requests.

Reporting that builds trust

A half-page weekly note beats a monthly slide deck: what closed, what is in progress, what is blocked and on whom, and the forecast for the next gate. Early transparency about a delay is the single strongest trust-building act available to a project manager. Clients forgive a slip they were warned about and do not forgive a surprise. Related expectations are set in product development contract terms and fixed price vs time and materials.

Three questions before committing to a date

  • What is still unknown? If an open technical question remains, the date is a guess wearing a suit.
  • Who else has to approve? Test labs, regulators, and customer sign-offs add weeks you do not control.
  • What happens if the next iteration fails? If the answer is "we lose two months," that belongs in the schedule as a line item, not in a risk register as a scenario.

Programs that begin with those three answers on the table generally land where they promised. Programs that treat them as pessimism generally do not. The systematic version of question three is risk management in a product development project, and the aggregate picture is in how long product development takes.

Run your project this way

Projects House manages US client programs on exactly this structure: deliverable-based gates, a lead-time-aware critical path, pooled buffer, priced change orders, and a short weekly report. If you want a schedule you can plan a launch around, describe your project through the contact form, or start with our product development services overview.