You send the same brief to three engineering firms. One comes back with five months, one with eight, one with fourteen, and nothing in the proposals explains the spread. The five-month schedule is the cheapest and the most exciting, and it is also, more often than not, the one that ends up costing the most — because a schedule that omits work does not remove the work, it just moves it past the point where you have already spent your budget.
Clients scrutinize the price line by line and read the schedule as a single number. Here is how to read it properly.
A real schedule shows the work, not the phases
The first test is granularity. A proposal that says "Phase 2: Detailed Design — 10 weeks" cannot be checked. One you can evaluate breaks that into tasks with durations: enclosure CAD, DFM review, PCB schematic, layout, firmware architecture, bring-up, EMC pre-scan. If the firm cannot decompose the work, they are quoting from a feeling.
The second test is whether the schedule distinguishes engineering time from calendar time. These are wildly different numbers. Two weeks of PCB layout effort can occupy six weeks of calendar because of a component lead time, a fabrication queue, and a holiday. A firm that presents only effort hours has given you a budget, not a date.
The line items amateurs leave out
Most schedule overruns are not caused by tasks running long. They are caused by tasks that were never in the plan. Scan any proposal for these:
- Fabrication and shipping lead times. A prototype PCB from a domestic quick-turn house is days; from an overseas fab with assembly it is weeks. Machined parts, castings, and especially tooling have their own clocks — an injection mold alone typically runs 6 to 14 weeks, as covered in how long it takes to build an injection mold.
- Component procurement. Long-lead parts still exist. A connector or power module on 20-week allocation can dominate the entire schedule, and nobody discovers this until the BOM is priced.
- Your own review time. If the plan assumes you approve concepts in 48 hours and you take two weeks, the schedule slips by the difference. Good proposals name the review windows and say what happens when they are missed.
- Design iterations. Ask how many prototype rounds are in the plan. Hardware almost never converges in one. Two to three build-test-revise cycles is normal for a moderately complex product; a plan with one is a plan that assumes nothing goes wrong.
- Certification and test lab scheduling. Booking an accredited EMC chamber can take four to eight weeks, and a failed scan means a redesign plus a rebooking. This is a schedule item, not a footnote.
- Documentation and release. Producing a manufacturing data package that a factory can actually build from takes real weeks.
Sanity-check the shape against known stages
You do not need to be an engineer to know whether the proportions are plausible. For a connected consumer product, a rough distribution looks like this:
| Stage | Share of schedule | Typical calendar |
|---|---|---|
| Requirements and concept | 10–15% | 3–6 weeks |
| Industrial design and architecture | 15% | 4–8 weeks |
| Detailed design (mechanical, electronics, firmware) | 30–35% | 10–20 weeks |
| Prototype builds and iteration | 20–25% | 8–16 weeks |
| Verification, certification, production readiness | 15–20% | 8–16 weeks |
If a proposal spends 70% of its duration on detailed design and three weeks on everything after, it has priced the fun part and ignored the part that decides whether you ship. Compare the overall figure with the ranges in how long product development takes and how to build a realistic hardware development timeline — if a firm is quoting half the industry norm for a comparable product, the burden of explanation is on them.
Questions that expose an optimistic plan
- "What is on the critical path, and what happens if it slips a week?" A firm running a real schedule knows which two or three items drive the end date. A firm without one will say "everything is important."
- "How many prototype iterations does this assume, and what does an extra one cost in time and money?" The answer should be a number and a rate, not reassurance.
- "Which tasks depend on me, and by when?" Forces the client-side dependencies onto paper.
- "What did the last three projects of this type actually take versus the estimate?" Firms that track this will tell you, sometimes ruefully. Firms that do not track it have no basis for the estimate they just gave you.
- "Is this schedule based on full-time allocation, and who else is on that engineer's plate?" A common cause of drift is a lead engineer split across three projects.
- "Where are the decision gates?" A schedule organized around stage gates with real decision points is one where slippage becomes visible early instead of at the end.
Red flags
Some signals reliably predict a schedule that will not hold. A single duration with no task breakdown. No buffer anywhere — real schedules carry 15–25% somewhere. A start date contingent on a signature this week, which is a sales tactic. Certification treated as a line at the end with no lab named. A promise to overlap tooling with design validation without discussing the risk of a tool change, which is precisely what the EVT, DVT, PVT build stages exist to prevent. And the biggest one: a firm that accepts your desired date without pushing back on anything. If your trade show is in seven months and every firm says nine except one, the one is not faster, it is agreeing.
Buffers, and the honest conversation about them
The right answer to schedule risk is not padding every task, which makes the quote uncompetitive. It is a named contingency reserve at the project level. Ask the firm to state which assumptions the schedule rests on — component availability, number of iterations, your review turnaround, no scope additions — and the impact if each breaks. That page is worth more than the Gantt chart, and it is the discipline that keeps costs in line too, as described in why engineering project budgets overrun.
Then bring the timeline question into the kickoff meeting rather than leaving it in the proposal, and revisit it at every gate. A schedule that is never revised was never being used.
Projects House builds schedules that separate engineering effort from lead times, name the critical path, and state the assumptions in writing. Send us your target date and what you are building through the contact form, and we will tell you honestly whether it is reachable.