Stalled Looks Different From Late

Late is normal. A schedule that moves a few weeks after a failed test is a project working correctly. Stalled is something else, and it has a distinct signature: activity continues, invoices continue, and the answer to "what changed since last month" gets harder to give each time you ask.

The reason this matters is that the cost of a stalled project is not the money already spent. It is the money you will spend continuing on the same path, plus the market window closing while you do. Founders routinely spend another $80,000 avoiding a $6,000 conversation, because commissioning a review feels like an accusation against a team they like.

Seven Signs It Is Time

  • The completion date moves by the same amount every review. Three months out, forever. This usually means nobody has a real model of what is left, only a list of open items.
  • You cannot get a straight answer about a specific technical risk. You ask whether the thermal problem is solved and get a description of activity rather than a measurement.
  • The same failure keeps recurring in different forms. Fix, retest, fail somewhere adjacent. That pattern usually means the root cause was never identified and the team is treating symptoms.
  • Spend has passed the original estimate by more than half with no revised plan. Overrun happens; overrun without a rebaselined plan is the warning. The mechanisms are dissected in engineering project budget overruns.
  • Deliverables are demos rather than documents. A working demo is encouraging, but if there is no drawing package, no BOM, no test data, the project may have less real progress than it appears.
  • The prototype works and the manufacturing quote is triple the target. This is not a schedule problem, it is a design problem, and it is the specific situation described in a prototype that costs too much to manufacture.
  • Key personnel changed and nobody flagged it. The engineer who architected the system left and the project is being carried by people reading their notes.

One of these is a question to raise at the next review. Three or more is a reason to bring in an outside reviewer.

What an Independent Review Actually Examines

A competent technical review is not somebody looking at your prototype and offering opinions. It works from artifacts, and the absence of an artifact is itself a finding. Expect the reviewer to ask for:

  • The requirements document and evidence, with data, of which requirements have been verified.
  • Current CAD, schematics, layout, and firmware repository access including commit history, which tells an experienced reader how work has actually proceeded.
  • The bill of materials with quoted prices at real volumes, and sourcing status of every long-lead or single-source part.
  • Test reports, including the failures. A file with only successful tests is a red flag.
  • The risk register, if one exists, and the regulatory plan with any pre-scan results.

From that, the review answers four questions: is the architecture capable of meeting the requirements at all, what is genuinely finished versus reported as finished, what does it realistically cost and take to reach production, and what are the three risks most likely to sink the program. This is the same exercise investors commission before writing a check, described in technical due diligence.

A review of a moderately complex electromechanical product typically takes one to three weeks and costs $5,000 to $20,000. Against a program that has already consumed several hundred thousand dollars, that is rounding error.

Doing It Without Detonating the Relationship

Tell the incumbent team. A covert review poisons the relationship and produces worse findings anyway, because the reviewer gets no context. Frame it accurately: an independent check before a major spending commitment is standard practice, and many engineers welcome it, particularly if they have been raising a concern nobody acted on.

Pick a reviewer with no stake in the outcome. A firm that reviews your project and then bids to take it over has an obvious incentive problem, so agree the terms up front: either they are barred from bidding, or you accept the conflict knowingly. Insist on written findings with evidence, not a verbal summary. Prioritized recommendations with cost and schedule impact are the deliverable; a list of criticisms is not.

When You Do Not Need One

A second opinion is the wrong tool in three cases. If the project is early enough that there are no artifacts to review, you need a requirements phase instead. If you already know the problem and do not want to pay to fix it, a reviewer will only tell you what you know. And if the real issue is that you have changed the requirements four times, the finding will be about you, and the fix is oversight discipline of the kind described in product development project management.

What Happens After the Report

Findings usually fall into three buckets. Most common is that the approach is sound and the problem is process: no baselined requirements, no gate criteria, no risk tracking. That is fixable with the existing team in a few weeks.

Second is a specific technical dead end, such as an architecture that cannot hit the cost target or a component choice that cannot pass emissions. Here the fix is a scoped redesign of one subsystem, often done by a specialist while the incumbent continues everything else. Formalizing risk tracking from that point forward, as described in risk management in product development, keeps the same thing from recurring.

Least common, and the one everybody fears, is that the team is not capable of finishing. If it comes to that, the transition is survivable but only if you secure the deliverables first: native CAD files, source code, test data, vendor contacts, and tooling ownership. Get the full handover list assembled before you announce anything, using the manufacturing data package as the checklist, and read switching engineering firms mid-project before you make a move.

Get an Honest Read on Your Program

Projects House performs independent technical reviews of stalled hardware programs, delivering written findings with evidence, a realistic cost and schedule to completion, and a prioritized recovery plan. Describe where your project is stuck through our contact form.