When something goes wrong in a project, we tend to look for the function in which the problem became visible. Was it Engineering? Quality? Operations? Project Management? Procurement? That makes sense because organisations are structured into functions, responsibilities and reporting lines, and we naturally look for the place where ownership sits.
Over the years, though, I have become increasingly interested in another place: the space between those functions.
A project can have excellent engineers, a competent Quality organisation, experienced operators and strong project management, and still produce a weak overall system. Not because any of those functions is failing, but because each is doing good work from its own perspective while the flow between them has never been designed with the same care.
That is the cross-functional friction zone.
When everybody is doing their job
This is what makes cross-functional problems difficult to see. Engineering is designing. Quality is reviewing. Operations is preparing. Procurement is negotiating. Project Management is moving the schedule forward. Everybody is active, everybody has deliverables and everybody can demonstrate progress.
Yet underneath that visible progress there may be a chain of perfectly reasonable assumptions. Engineering assumes Quality has already reviewed a particular decision. Quality assumes Operations has been involved. Operations assumes the documentation represents how the process will actually work. Management assumes the difficult discussion has already happened because the milestone is being presented for approval.
None of those assumptions is irrational. That is precisely why they survive.
The connection between functions is rarely owned in the same way that an individual activity is owned. There may be a RACI, a project plan and a governance structure, but the actual question — has the meaning transferred with the information? — is much harder to see on a tracker.
A handover can therefore be completed without the next person understanding what the previous person assumed.
Information can move while understanding does not
I think this distinction matters. We are very good at moving documents, decisions, drawings, action lists and specifications through organisations. We are less consistent at checking whether the context travelled with them.
A requirement may reach Engineering without the operational reason behind it. A design decision may reach Quality without the alternatives that were considered. A supplier may answer the URS exactly as written while the future operator assumes a capability that was never actually specified. A project team may close an action because the required document exists, while the underlying interface remains unclear.
Technically, something has been handed over. Operationally, the connection may still be missing.
That is often where friction starts: not with one dramatic mistake, but with small clarification loops, repeated questions, parallel trackers, late changes and people compensating for information that should have been available earlier.
Good people can protect weak interfaces
This connects strongly to something I wrote about in WAMI Reflection 002: good people can unintentionally protect weak systems.
When an interface is unclear, competent people compensate. They clarify, remind, chase, call somebody they know, translate between departments and quietly make the process work. From the outside the system can therefore look remarkably stable.
Until one of those people is unavailable, the workload increases, the project changes phase or the number of interfaces simply becomes too large to manage informally.
Then what looked like poor communication suddenly becomes a delay, a deviation, a design change or a missed commitment.
The visible event may be new. The friction often is not.
Functional excellence can create local optimisation
There is another element that I think is important here. Every function has a legitimate objective to protect.
Engineering wants a technically coherent solution. Quality needs compliance and control. Operations needs something that can actually be run. Procurement has commercial and contractual constraints. Radiation Protection may be protecting exposure. Project Management has timing and dependencies to manage.
The problem is not that one of those perspectives is wrong. The problem begins when each function optimises its own part without seeing what that optimisation creates for the wider process.
A technically elegant solution may be awkward to clean. A very conservative quality control may create operational delay without materially reducing risk. A cost-saving purchasing decision may shift complexity into qualification or maintenance. An operational shortcut may solve today’s timing problem while creating tomorrow’s compliance issue.
The system outcome sits between the functions.
We need to design the connections as deliberately as the components
For me, this is where multidisciplinary review becomes valuable, but only if it is more than having several departments attend the same meeting.
The purpose is not simply to collect approvals. It is to expose the assumptions at the interfaces.
What does Engineering believe Operations will do? What does Quality believe the supplier has demonstrated? What does Procurement believe is included in the contract? What does the supplier believe is the user’s responsibility? What will Maintenance need that the URS never mentioned? What decision does somebody later need to make, and will they have the information required to make it?
Those questions often reveal more than another round of functional review.
The friction itself is information
I have become much less interested in treating recurring cross-functional friction as a personality problem or as evidence that people simply need to communicate better.
Sometimes people do need to communicate better, of course. But if intelligent, competent people repeatedly struggle at the same interface, I want to understand what the system is asking them to compensate for.
Maybe ownership is unclear. Maybe information arrives too late. Maybe two functions use the same word to mean different things. Maybe a decision rightfully belongs to one group but depends on knowledge held somewhere else. Maybe the process was designed function by function when the real work flows horizontally through all of them.
The friction is telling us something.
And if we listen early enough, it is often cheaper than waiting for the formal failure that comes later.
Because strong functions do not automatically create a strong system. The system becomes strong when the connections between them work as reliably as the functions themselves.
