Why Hard and Deep Tech Programs Keep Failing (It's Not the Engineering)

I usually find these kinds of articles by big consulting companies distracting/inaccurate (WAGs), but this one by Bain on why programs in hard/deep tech (aerospace, maritime, nuclear, robotics, etc.) keep blowing schedules and budgets is pretty darn good. Their main point is basically, “it’s a coordination problem, not an engineering problem.” After ~10 years bouncing around places like SpaceX, Northrop, ABL, etc., that’s pretty much what I saw too.

Some patterns I personally ran into:

1. The most chaotic part of any hardware program is the few months before there are real procedures. You’re trying to outline a test campaign, or an I&T flow, or some intense multi-org field op, while requirements and configs are still shifting every week. The "plan" ends up being slides, spreadsheets, random trackers, emails, and whatever a couple people keep in their heads. Everyone thinks they have the latest version, but no one actually does.

2. Everything becomes the “source of truth,” just not at the same time. Test leads update a spreadsheet. PMs update a slide deck. Engineering updates Jira. Ops has a readiness checklist. Leadership looks at some dashboard. These drift out-of-sync fast. Most “surprises” are just stale artifacts.

3. Hardware programs have real temporal/resource/personnel/location couplings that normal PM tools can't handle. For things like a ten day test campaign or integrated field op with three other companies out in the middle of nowhere, good luck using Asana, smartsheets, or ppt. Hardware stuff is tied to tings like facility windows, equipment readiness, partner dependencies, safety constraints, sequence logic, etc. If one thing moves, every other thing needs to reflow too. Most orgs are doing this manually, which means the plan is obsolete the moment it’s written since plans change all the time in our world.

4. The moment multiple orgs are involved, everything breaks faster. Spacecraft <> LV; Prime <> suppliers; Customer <> integrator; Engineering <> test houses; etc. Everyone uses their own tool stack, their own cadence/workflows, their own naming conventions. Nothing interoperates in a meaningful way, so schedule drift and misalignments accumulate at the boundaries.

5. People outside these industries say “just use ERP/MRP/CRM/etc.” Those tools have their place, but they're optimized mostly for orgs creating highly repeatable and mass manufacturable products with very little differentiation. Space, nuclear, robotics, energy, a lot of deep-tech.. none of them are well suited for these tools. They're low-volume, high-variability, tons of uncertainty, long lead items, complex sequencing, one-off integrations, etc. You’re basically inventing a new process every cycle. The modern enterprise stack isn’t designed for that topology of work.

6. Most PMs/engineers/ops people aren’t failing. They’re just stuck in workflows that don’t match the complexity of what they’re doing. In other words, their workflows are majorly constrained by the limited tools available to them. In practice the “workflow” is realistically like... update the slide -> export PDF -> update spreadsheet -> copy things into Jira -> paste into Confluence -> send update email -> update IMS/Gantt -> track all upstream/downstream effects -> sync with partners -> redo everything when a date or other detail slips -> repeat weekly. No one is set up to win under that overhead.

The root cause to all of these issues is that there’s no shared environment where teams can plan + adjust + sync on things like complex ops (and overall programs) before formal procedures and documentation exist, especially when multiple orgs are involved.

Curious how others here have seen this. If you’ve worked in aerospace/maritime/defense/robotics/energy/etc., what did your team actually do to survive the early-phase chaos between requirements and procedures? Did anything actually work?