ENGINEERING PRACTICE
Why Technically Strong Projects Still Lose Momentum
The overlooked role of alignment, communication and practical engineering in moving innovation forward.
26 August 2026 · 9 min read
Some projects struggle because the technology is immature, the funding is inadequate or the technical challenge is simply harder than expected.
Others are more difficult to explain.
The people are capable. The science is sound. The engineering expertise exists. The organisation has invested time, money and effort into making the project succeed.
And yet momentum begins to disappear.
Meetings multiply. Requirements shift. Decisions are revisited. Designs move backwards and forwards. Work reaches manufacture or integration before somebody raises a question that suddenly matters. Different teams appear to be working hard towards the same objective, but not always from the same understanding of it.
In multidisciplinary technical work, I think one reason for this is what I describe as translation loss: the gradual weakening or alteration of technical meaning, context and intent as information moves between people, disciplines and stages of delivery.
A project might travel through something like:
RESEARCH → DESIGN → ENGINEERING → MANUFACTURE → INTEGRATION → DELIVERY
At every transition, knowledge has to move with it.
The difficulty is that different disciplines do not necessarily need, notice or communicate the same information. An assumption in one discipline can become an apparent requirement in another. A provisional figure can gradually acquire the authority of a specification. Design rationale can disappear while the geometry survives. A practical constraint that is obvious to the person assembling the system may never have existed in the information available to the person who designed it.
Nothing dramatic has to fail.
The project can simply become progressively harder to deliver.
The problem often lives at the interfaces
Technical capability is necessary. It isn’t sufficient.
Complex research and engineering programmes bring together people who understand different parts of the problem: researchers, scientists, designers, engineers, technicians, manufacturers, suppliers, project managers and decision-makers.
Each brings legitimate expertise, but each also sees the project through a different professional frame.
A researcher may be primarily concerned with whether a particular scientific effect can be produced or measured. Engineering eventually has to translate that into requirements, interfaces, tolerances, materials, services, safety and physical constraints. Neither perspective is wrong, but they are not interchangeable.
The same happens between design and manufacture.
A designer may understand exactly what a component is intended to achieve. The person manufacturing it sees the same geometry through tooling access, workholding, material behaviour, tolerance accumulation, inspection and process capability. A feature that appears straightforward in CAD can carry a completely different implication once somebody has to make it.
Technicians often encounter another version of the same interface. By the time equipment reaches assembly, installation, commissioning or maintenance, questions become very physical. Can it actually be assembled in that sequence? Is there room to reach the fixing? Where do the services enter? What happens when something has to be removed? Has the design assumed access that will no longer exist once surrounding equipment is installed?
Then technical information has to move again when decisions reach project leadership.
Senior decision-makers cannot reasonably absorb every technical detail of a complex programme. Information has to be compressed. But compression is itself a form of translation, and deciding what to remove without removing the meaning is difficult.
A risk can become a status.
An uncertainty can become a date.
A technical trade-off can become a cost.
By the time the information reaches the person making the decision, the detail may be gone while the consequences remain.
This is why I don’t think multidisciplinary engineering problems can always be reduced to “better communication.” Communication is part of it, but the harder question is whether the meaning survived the interface.
Technical knowledge only creates project value if enough of it reaches the person who needs it, at the point when they can still do something with it.
Research ↔ Engineering
Research and engineering are closely related, but they are not trying to answer exactly the same question.
Research
Can this work?
Engineering
Can we make this work reliably, repeatedly and within real-world constraints?
Translation loss
Technical meaning, context or intent can weaken as information moves between disciplines, roles or organisational levels.
RESEARCH → DESIGN → ENGINEERING → MANUFACTURE → INTEGRATION → DELIVERY
Alignment Is Not Agreement
This distinction matters because good engineering should contain disagreement.
Researchers should challenge assumptions.
Engineers should question requirements.
Manufacturing specialists should challenge features that are unnecessarily difficult to produce.
Technicians should raise problems with assembly, access or maintainability.
Project leaders should question cost, risk and timescale.
A team in which nobody disagrees is not necessarily aligned. It may simply be avoiding difficult conversations.
Alignment doesn’t require everyone to agree. It requires everyone to understand the same problem, constraints and intended outcome.
That creates a very different kind of disagreement.
If everyone understands what the project is trying to achieve and why, different disciplines can challenge the proposed solution from their own perspective without inadvertently changing the underlying problem.
A manufacturing engineer might propose a different feature because the existing design is unnecessarily expensive to produce. A researcher can then explain whether that feature affects the scientific requirement. A technician might identify an installation problem. A designer can reconsider the arrangement while preserving the functional intent.
The disciplines remain different.
That is useful.
The objective is not to eliminate those differences but to give them a sufficiently shared understanding that they can improve the same solution.
Translation loss describes what can happen as knowledge crosses those boundaries. Alignment is one of the conditions that helps resist it.
When Communication Problems Become Engineering Problems
There is good evidence for the broader importance of the human side of project delivery.
Research commissioned by the Association for Project Management examined a range of dynamic conditions associated with project success. Of the conditions studied, interpersonal skills were rated most highly: more than 97% of survey respondents considered them important or very important. Communication, leadership and listening were among the prominent themes.
The UK’s Employer Skills Survey provides a different but complementary picture. In the 2024 survey, team-working skills were lacking in 47% of reported skills gaps, while management and leadership skills were lacking in 49%. Around two-thirds (65%) of employers experiencing skills gaps said those gaps had at least some impact on business performance.
The human side of technical delivery
65%
of employers experiencing skills gaps said they affected business performance
These figures demonstrate the wider importance of interpersonal, team-working and management capability. They do not establish a direct causal relationship between communication and engineering-project failure.
What they do support is the broader point that technical organisations do not succeed through technical competence alone. People also need to communicate, collaborate, interpret information and work effectively across organisational boundaries.
In engineering environments, failures in those processes can eventually become physical.
A component is remade.
A test is repeated.
An interface doesn’t fit.
Equipment arrives before the necessary infrastructure is ready.
A requirement is interpreted differently by two teams.
A decision is revisited because the people affected by it were not part of the earlier conversation.
A problem that could have been resolved during concept development reaches manufacture, installation or commissioning instead.
The communication may be interpersonal.
The consequences are engineering consequences.
And the later a misunderstanding travels through the project, the more expensive it can become to resolve.
This is why practical engineering knowledge matters early. It is also why researchers, engineers, technicians and decision-makers need enough access to one another to test what information actually means before assumptions become hardware, procurement commitments or programme dates.
A Practical Check for Technical Alignment
The response to all of this does not need to be another layer of process.
Sometimes a relatively simple conversation can reveal whether a multidisciplinary team is actually working from the same understanding.
At an appropriate point in a project, ask the people representing the relevant disciplines to answer five questions:
01
Are we actually solving the same problem?
Not what equipment are we building, but what underlying problem or requirement justifies it?
02
What does success look like?
What outcome must the system, component, experiment or project actually achieve?
03
Which assumptions are we relying on?
Which parts of the current solution are genuine requirements, and which have simply become embedded because nobody has revisited them?
04
What matters most from your perspective?
The researcher, designer, manufacturer, technician and project lead may give different answers. That is useful information, particularly where one constraint has consequences for another discipline.
05
What is the next decision that actually needs to be made?
Projects can generate enormous amounts of activity without resolving the decision preventing meaningful progress.
The value comes from comparing the answers.
The objective is not identical wording. Different disciplines should see different aspects of the problem.
The warning sign is when those differences reveal that people are not offering different perspectives on the same problem at all.
They are working on different versions of it.
TRY THIS IN YOUR NEXT PROJECT MEETING
Ask several people independently to write down:
Then compare the answers.
Significant differences don’t necessarily mean somebody is wrong. They may reveal where assumptions, intent or technical meaning are being interpreted differently.
Better innovation needs better interfaces
Technically ambitious organisations need specialists.
Research needs deep scientific expertise. Engineering needs people capable of analysing, designing and integrating complex systems. Manufacturing needs process knowledge. Technical delivery needs people who understand how equipment behaves when it becomes physical. Leadership needs people capable of making decisions across all of those constraints.
The challenge is not to make those disciplines think alike.
It is to prevent the important knowledge held within one discipline from becoming invisible to another.
That requires more than moving information around an organisation. It requires enough shared context to understand what that information means, which assumptions sit behind it and what consequences follow when it changes.
When that happens well, disagreement becomes useful. Problems are challenged while they are still cheap to change. Practical knowledge enters before designs become fixed. Decision-makers receive enough technical context to understand the trade-offs they are being asked to make.
When it does not, highly capable people can spend considerable time solving slightly different versions of the same problem.
Strong technical projects do not require perfect communication.
They do require important technical meaning to survive the journey from idea to delivery.
Sometimes the obstacle to progress isn’t the engineering itself.
It’s the space between the engineers.
Sources
Association for Project Management — Dynamic Conditions for Project Success (2021)
Research examining nine dynamic conditions associated with project success. More than 97% of survey respondents considered interpersonal skills important or very important, making them the highest-rated dynamic condition examined in the study.
UK Government — Employer Skills Survey 2024: UK Findings
The Employer Skills Survey 2024 provides UK-wide evidence on employers’ skills needs, skills gaps and training. The findings used in this Insight include reported gaps in team-working and management and leadership skills, together with the impact of skills gaps on business performance.
ABOUT THE AUTHOR
James Carter
Founder, Copper Hive
James founded Copper Hive following more than two decades working across applied engineering, manufacturing, research and advanced technology environments. His experience spans design, machining, prototyping, installation, troubleshooting and R&D, providing a practical perspective on how technical ideas move between research, engineering and real-world delivery.
RELATED SERVICE
Project Alignment
Technical projects rarely struggle because nobody has expertise.
More often, the difficulty is making sure the right expertise, assumptions and constraints are visible at the point where important decisions are made.
Copper Hive helps technical teams clarify complex problems, expose assumptions, connect perspectives and improve alignment between research, engineering and practical delivery.

Make the Interfaces Visible
If a technically capable project is losing momentum, the problem may not sit within any individual discipline.
It may sit between them.
Copper Hive provides independent technical insight to help organisations clarify problems, connect engineering perspectives and turn complex technical discussions into practical decisions.
