Engineering communication breaks when important decisions travel through conversations but the requirements, interfaces and evidence affected by those decisions live in separate files. As a hardware team grows, the number of relationships grows much faster than headcount. Excel, Word, email and chat can carry messages, but they do not by themselves keep ownership, rationale, configuration, approval and verification evidence aligned with the controlled programme baseline.
A useful operating assumption is that many complex hardware problems emerge between disciplines, tools and programme layers rather than within one isolated task. A propulsion assumption changes, a mass budget moves, a test procedure stays the same and a mission requirement quietly loses its evidence.
Calling this a communication problem is accurate, but incomplete. The team is usually communicating all day. The real problem is whether those communications update a shared engineering record. If the answer is no, the programme depends on memory and manual reconstruction.
Why does engineering communication get harder as teams grow?
Each new engineer does not create one new communication line. They can create a relationship with every person already involved. Ten people have 45 possible pairwise connections. Twenty people have 190. Thirty people have 435. Not every pair needs to speak directly, but the pattern explains why informal coordination stops scaling.
The counts are the combinations of each person with every other person: n(n−1)/2. They illustrate possible communication paths, not a measured productivity law. A small change in an Excel power budget can alter a design, simulation conditions and a mission-critical requirement. The message might reach each individual while the connected records still drift.
The challenge grows across disciplines because every team uses a tool shaped around its work. Mechanical engineers live in CAD and PLM. Analysts use simulation tools and scripts. Electronics teams use ECAD and component databases. Systems engineers often rely on requirements tools or spreadsheets. Test engineers work with procedures, station software and result repositories.
Those tools are not the enemy. Domain-specific tools are necessary. The missing layer is a shared model of the decisions and dependencies that cross them.
Why are Excel and Word not enough for requirements management?
Excel is flexible, familiar and fast to start. Word is excellent for narrative, context and formal documents. Used alone, neither maintains a live network of requirements, interfaces, tests, evidence, owners and changes across a moving programme.
A spreadsheet can include an owner column and a verification column, but those cells do not by themselves show that a proposed mass increase changes a launch interface, invalidates an analysis report or affects several test limits. Someone must model and maintain the relationships or add controlled automation around them. A Word paragraph likewise does not by itself notify downstream owners when one value changes.
File links help until a document moves, a copy is emailed or a supplier works from an exported baseline. Teams then have several internally consistent files that disagree with one another. The work becomes a comparison exercise: which version is current, which comments were accepted and which changes reached the test team?
The problem is not that spreadsheets are primitive. It is that they treat the programme as tables and pages when the engineering reality is a graph.
What gets lost between the files?
The first loss is rationale. A requirement may keep its number and wording while the reason behind it remains in meeting notes or someone’s memory. When a new engineer challenges the value, the team cannot tell whether it reflects physics, a customer obligation or an old design choice.
The second loss is relationship context. A spreadsheet may show parent and child identifiers, but interface dependencies often cross the hierarchy. A thermal limit can affect power, structure, operations and test. Those links are difficult to express and maintain in a flat table.
The third loss is decision state. An engineer may believe a change was approved because it was accepted in a meeting. Another person may believe the baseline remains unchanged because no controlled document was released. Both are acting reasonably from different records.
The fourth loss is verification continuity. A requirement changes, but its existing test case remains attached to the old limit. The programme reports coverage, yet the evidence no longer proves the current statement.
Why do meetings and chat not solve the problem?
Meetings are useful for negotiation, ambiguity and judgement. Chat is useful for quick clarification. They are poor long-term systems of record because they organise information by conversation rather than by engineering object.
A six-month-old message can contain the exact reasoning behind an interface change, but finding it requires knowing who said it, where they said it and roughly when. A new team member is unlikely to discover it while reviewing the requirement. The decision becomes invisible at the moment it is most useful.
Adding more meetings can increase awareness, but it also increases coordination load. Every participant spends time hearing changes that may not affect them because the programme cannot target information through explicit relationships.
A better system keeps the conversation beside the requirement, interface, test or proposed change. People can still speak directly, while the outcome is captured where future work will encounter it.
What is a single source of truth in engineering?
A single source of truth is not one enormous file and it is not a ban on domain tools. It is an authoritative programme model that identifies the current requirements, owners, relationships, review state and verification evidence.
An organisation may designate a CAD or PDM system as its authority for geometry and a simulation environment or repository as its authority for a model run. The programme model can then record which requirement the geometry or analysis supports, which configuration produced the result and how a proposed change affects the rest of the system.
The word single can be misleading. Engineering truth is distributed across specialised systems. What matters is that each type of truth has a clear authority and that the relationships between those authorities are maintained.
| Record | Typical authority | Cross-domain context to preserve |
|---|---|---|
| Programme requirements and decisions | Controlled requirements or programme system | Source, rationale, owner, links, review state and applicable baseline |
| Product definition | The designated CAD, ECAD, PDM or PLM system | Stable identifier, revision, configuration and relationship to the decision |
| Quality or manufacturing evidence | The designated QMS or manufacturing record system | Nonconformance or build reference, disposition and affected requirement |
| Test execution and evidence | The approved test or evidence system | Procedure, article, configuration, result, anomaly and closure status |
| Generated specification or report | The controlled source records | Baseline, generation date and template revision |
NASA's configuration-management guidance describes control of product characteristics and consistency between products and their information. The authority map above is Arc's implementation guidance, not a prescribed NASA system architecture.
How should requirements communication work?
NASA's requirements-management guidance calls for responsible individuals, bidirectional traceability and formal evaluation, approval, implementation and communication of requirement changes. In practical use, every important requirement needs a responsible person who understands its intent, can coordinate affected teams and knows what evidence will close it. That person should not be the only person allowed to comment or propose a change.
As Arc's editorial recommendation, changes should be communicated as visible deltas rather than vague announcements. A reviewer needs to see what moved, why it moved, which relationships are affected and what verification work may need updating. The programme should preserve comments, decisions and approvals with that delta.
Notifications should follow dependencies and roles. A test owner should hear about a requirement change that affects their procedure. A structural engineer should not receive every software wording update. Explicit relationships allow the system to be selective without relying on a coordinator to remember the audience.
Finally, communication should have closure. A message that says “please update this” is not complete until the affected record changes, the right owner reviews it and the baseline reflects the decision.
NASA's decision-analysis guidance describes evaluating alternatives against criteria and capturing work products. For a practical field structure that also preserves assumptions, dissent and consequences, use Arc's engineering decision record template.
What does change impact analysis add?
NASA's change-management process evaluates requirement changes before approval and identifies affected system products and processes. This guide recommends inspecting upstream obligations, downstream requirements, design elements, interfaces, tests and evidence connected to the proposed change.
This does not mean every relationship is equally affected. Some items need a new value. Some only need review. Others remain valid but should be acknowledged. The analysis gives responsible engineers a starting map, then engineering judgement determines the action.
Without that map, teams search manually. They filter spreadsheets, ask colleagues and inspect file links. The result depends on who is available and what they remember. With a connected graph, the search becomes repeatable and reviewable.
How does traceability improve communication?
NASA's requirements-management guidance calls for bidirectional traceability between requirements and other product and process information. In a programme model, a mission objective can connect to system requirements, subsystem criteria, interfaces, test cases and evidence so a change review can identify the people and records along that route.
It also improves the quality of conversations. Instead of asking whether a change is risky in the abstract, engineers can discuss the exact affected items. Instead of saying verification is nearly complete, the team can inspect current evidence against current requirements.
Traceability should not become a separate clerical project. If engineers need to maintain duplicate link registers after doing the real work, the links will drift. Relationships should be created and reviewed within the same workflow used to propose requirements and attach evidence.
What changes when the programme uses a connected workspace?
The biggest change is that coordination becomes part of the engineering object. A requirement holds its owner, rationale, relationships, comments, change history and verification state. Engineers do not need to reconstruct that context from five applications before making a decision.
Arc's controlled-change workflow lets teams explore a proposal in a branch and review its diff without changing the approved baseline. Arc's traceability and impact views show the connected context that may be affected, while linked verification records and evidence help reviewers assess whether the proof path still matches the current requirement and configuration.
Within Arc's documented AI-governance boundary, a configured agent can suggest missing relationships, flag evidence that appears stale or summarise the likely effects of a change. Engineers remain responsible for accepting those suggestions because the model does not own the hardware or its consequences.
Arc's capability reference documents the connected programme model and its boundary: Arc manages typed programme records and explicit relationships, while each organisation configures the record types, fields and lifecycle states for its process.
How can a team improve communication without a large migration?
Start with one active change that already crosses several files. Identify the requirement being changed, its owner, the upstream reason, the downstream interfaces and the verification evidence. Put those relationships into one connected record and run the review there.
Then compare the effort with the existing process. Count the files searched, people asked and updates required. The purpose is not to prove every spreadsheet is bad. It is to find where manual synchronisation consumes engineering time or creates review risk.
Expand around the next recurring workflow, such as PDR preparation, interface change or verification closure. A programme becomes connected through useful decisions, not through a long migration that tries to model everything before anyone benefits.
Related reading
Use the engineering decision record template to preserve rationale and accountability, the requirements change-impact guide to map a decision's consequences, and the requirements traceability matrix guide to keep the resulting path reviewable.
Frequently asked questions
What is the biggest communication problem in hardware development?
The biggest problem is keeping decisions, requirements, interfaces and evidence aligned across disciplines and tools. Teams may communicate frequently while the underlying engineering records still drift.
Can Excel manage requirements?
Excel can manage a small requirements list, but it becomes difficult to maintain ownership, branching, complex relationships, change history and verification evidence as a programme scales.
What is requirements traceability?
Requirements traceability connects stakeholder needs to system and subsystem requirements, design elements, tests and evidence so the team can understand coverage and change impact.
Does a single source of truth replace CAD, PLM or test tools?
No. Domain tools remain authoritative for their specialist data. The connected programme model maintains the cross-domain requirements, decisions and relationships between them.
How can AI help engineering communication?
AI can suggest relationships, identify gaps, summarise change impact and flag stale evidence. Engineers should review and approve any meaningful change.
Evaluate Arc
Try Arc on a representative engineering workflow
Start with one requirement set and test traceability, change control, review and verification in a private Arc workspace.