On very large projects, I’ve watched this play out more than once: individual pieces of equipment may meet their specifications, yet the overall process doesn’t perform as expected.
The first response is usually technical. Teams troubleshoot equipment, adjust controls, and challenge the vendors. Sometimes that is exactly what the situation requires.
But sometimes the investigation leads back to something that happened long before startup. An operating assumption wasn’t examined. Critical information never reached the right people. Responsibility for confirming how the pieces would work together wasn’t clear.
The technical problem is real. Understanding why it happened requires looking beyond the equipment.
In a process plant, each unit operation performs a particular function. Its requirements can be specified, its equipment built, and its performance tested. Yet the plant ultimately has to work as an integrated system.
I’ve seen projects struggle because the effect of variations leaving one unit on the next hadn’t been fully worked through. The design hadn’t adequately accounted for how the plant would actually be operated.
That distinction matters. A condition that appears acceptable when evaluating one unit can create difficulties for the equipment downstream. An assumption that seems reasonable within one scope can become a problem at the boundary with another.
This is part of the engineering work, too: understanding interfaces, examining realistic operating conditions, and confirming that individual requirements support the performance of the whole.
When those questions remain unresolved, the gap may become visible only after the equipment is installed and the process is running.
In another case, critical information never made it from one organization to the other.
The customer assumed the provider understood their operation. The provider assumed the customer had shared everything that mattered. Ownership for confirming how the solution would fit the actual operating environment wasn’t clear.
Both sides could move forward believing they had supplied or received enough information. The missing question sat between their respective responsibilities.
That is one reason “the customer didn’t tell us” and “the provider should have known” are incomplete explanations. They describe the disagreement after the gap becomes visible. Preventing a recurrence requires examining how important information was supposed to be identified, requested, communicated, and confirmed.
Who needed to ask? Who could provide the answer? Who was responsible for making sure the answer influenced the solution?
I’ve seen similar gaps in software rollouts where the people developing or implementing the solution hadn’t fully understood how users actually did their work. I’ve also seen a business build a product that missed a key customer need.
The settings differ, but the underlying questions are familiar:
A solution can look sound within the boundaries of its development process and still fall short in use.
The same perspective is useful when examining missed deadlines, repeated rework, or stalled initiatives. Before assuming that more effort will resolve the problem, consider whether expectations, priorities, or decision authority need clarification.
Each side tends to answer the questions in front of it. The expensive questions are the ones neither side thought to raise.
No team can anticipate every scenario. The goal is to deliberately examine the areas where separate responsibilities depend on one another, especially where an incorrect assumption would have significant consequences.
Here are five questions I would bring into that discussion.
Examine what one team delivers and what the next team needs to receive. That may involve operating conditions, information, approvals, timing, or acceptance criteria. Confirm that the two sides are working from compatible expectations.
Walk through realistic conditions with the people who will operate the equipment, use the software, or rely on the product. Ask where the planned approach differs from their actual work and what happens when conditions change.
The person purchasing a solution may have a different view from the person using or maintaining it. Identify whose knowledge could reveal a requirement or constraint that the current conversation has overlooked.
An interface problem can involve competing priorities and tradeoffs. Establish who can make the decision, who needs to contribute, and what information they need. An unresolved decision needs a clear path to resolution.
Asking a useful question is only the beginning. Give consequential open questions an owner and a point by which they need to be resolved. Make sure the answer reaches the people whose work depends on it.
When a failure occurs, the immediate issue deserves attention. Equipment may need modification. Software may need adjustment. A product or process may need to change.
It also helps to examine why the missing information, assumption, or decision wasn’t addressed earlier. Otherwise, the conditions that contributed to the problem can remain in place for the next project.
Before the next review, try one practical exercise: choose an important handoff between teams, organizations, or steps. Have each side describe what it expects from the other. Compare those expectations and assign responsibility for resolving any gaps.
The parts deserve careful attention. So do the questions between them.
What question do you now ask at the start of a project because you learned it the hard way?
If you’re working through a complex project or business challenge, I help organizations clarify the issues, evaluate tradeoffs, and develop practical paths forward. To discuss your situation, visit Achieve Coaching & Consulting.
