By Matei Kevenaar, founder of Buro Matei
1. When adapting becomes the problem
In EPC, being reasonable usually means adapting.
We adapt to the client’s reporting format, the project manager’s spreadsheet, the planner’s version of progress, the engineering team’s tracker, the procurement file, the construction update and the way the last project did it. That flexibility keeps projects moving. Large industrial projects rarely give us perfect conditions.
The trouble starts when every workaround becomes normal. A spreadsheet created for one problem stays for the next project. A weekly report becomes a permanent ritual. One team keeps its own status because another system cannot provide what it needs.
That is how weak systems survive. Skilled people carry the missing connections in their heads, inboxes, trackers and meetings. Engineers spend time collecting status, checking versions, chasing inputs and explaining progress. The project keeps moving, so the process appears to work.
At some point, adaptability starts protecting the problems it was meant to solve.
That is where the unreasonable engineer becomes useful. This person understands risk, contracts, deadlines and practical reality. They keep asking a question that EPC too often stops asking: why does this work still need to happen this way?
2. How we got here
EPC is genuinely complex. Engineering, procurement and construction move at different speeds. Thousands of technical decisions are connected. Vendors change dates. Information develops over time. Contracts create boundaries. Safety, quality and approvals matter.
Most of the tools we complain about today started with a sensible purpose. A spreadsheet helped a discipline organise its work. A report gave management a view of progress. An extra check reduced a risk. A meeting helped two teams coordinate.
Each local fix can be perfectly reasonable. Together, they can create an unreasonable system.
The result is familiar. One status exists in engineering, another in planning, another in procurement. People copy information between systems. Reports explain data that already exists somewhere else. Meetings reconstruct what happened during the week. Project knowledge lives in the people who know which file to open, who to call and which number to trust.
Complexity is part of EPC. Fragmentation is something we create around it.
A complex project needs clear connections between work, information and decisions. When those connections stay hidden, people compensate with more coordination. Their competence can hide the weakness of the system.
And once that way of working becomes familiar, it starts to look like control.
3. Stop confusing adaptation with control
This is where I think we need to ask harder questions.
Why does a project worth hundreds of millions still depend on people chasing status through email and spreadsheets? Why do we discover missing inputs after someone has already started the work? Why does leadership receive a polished report several days after the reality behind it has changed?
These questions go straight to what project control is supposed to achieve.
If several disciplines need a meeting to agree on the current status, the meeting is doing the job the project information should already be doing. If an engineer updates the same status in several places, the process is creating work around the work. If a delay becomes visible only after a milestone slips, the project has learned about the problem too late.
Familiar processes can still feel safe. Someone understands the spreadsheet. Everyone knows the weekly report. The approval has always been there. Familiarity can easily be mistaken for control.
I have seen what changes when a team starts questioning that. On one chemical project I worked on, repeated revisions of piping drawings had become accepted as part of the job. We changed the focus. Before work moved forward, we checked whether the required inputs were actually ready. We made prerequisites visible and used current information to coordinate the work every day.
The revision rate fell below one per cent. Engineering finished three months ahead of schedule. During the final part of the work, the team was smaller as well.
The most useful lesson was the question behind the result: why allow incomplete work to move forward in the first place?
That question changes the role of project data. Status helps decide what should happen next. Dependencies become visible while there is still time to act. The project spends less effort explaining problems and more effort preventing them.
The same test should apply to digital transformation. Smacking AI onto existing methods and calling it a day leaves the underlying way of working untouched. A modern tool creates value when the work around it changes as well.
The unreasonable engineer respects experience, risk and procedure, then asks whether each habit still earns its place.
4. The gap will widen
Over the next few years, I expect the difference between connected and fragmented EPC projects to become much easier to see.
Some organisations will continue using people as the bridge between systems. Engineers will collect status, planners will reconcile it, project controls will combine it, and management will receive the answer later in a report. Better software may speed up parts of that process, yet the daily work will remain familiar.
Other organisations will redesign the flow of information around the work itself. Project data will be more structured. Dependencies will be visible. Routine checks will happen automatically. Teams will see what is ready, what is blocked and what is moving out of sequence without first chasing several people for an answer.
Less time will go into copying, collecting, checking and reconciling. More time will go into engineering judgement, solving technical problems, making decisions and improving the work. Project controls can spend more time looking forward instead of rebuilding the past.
Both types of organisation may own modern software. The difference will show in how much human effort is still required to understand the project.
I think that difference will become a competitive one. Teams that need less manual coordination can react sooner and use skilled people where they add more value. Projects will remain complex. The stronger organisations will make that complexity visible enough to manage.
The future of EPC will be shaped by companies that remove avoidable coordination work and give engineers more room to engineer.
5. Be difficult for the right reasons
EPC needs reasonable people. Projects depend on engineers, planners, buyers, project managers and construction teams who can adapt when reality changes. I have spent much of my own career doing exactly that.
The danger comes when adaptation becomes permanent.
Every tracker that bridges the same old gap, every report that explains stale information and every meeting that mainly reconciles status makes today’s project easier to survive. It also makes the same way of working easier to carry into the next project.
So choose one thing your project treats as normal and ask why it exists.
Why does someone copy that status? Why do we need that meeting? Why does work start before the inputs are ready? Why do three teams maintain three versions of the same truth? Why do skilled engineers spend time on coordination that a better system could remove?
If the answer is “because we always have”, keep asking.
Change can start with one person refusing to accept avoidable work as a permanent feature of EPC.
Be difficult for the right reasons.
Being reasonable keeps the machine running.
Being a little unreasonable is how we build a better one.
References
- Data-Driven EPC success in a major industrial project
https://buromatei.com/data-driven-epc-success-in-a-major-industrial-project/ - EPC Project Dashboards
https://buromatei.com/epc-project-dashboards/ - How Buro Matei uses Automation to deliver Reliable and Predictable EPC projects
https://buromatei.com/how-buro-matei-uses-automation-to-deliver-reliable-and-predictable-epc-projects/