Construction Prone to Digitising the Problems It Should Be Eliminating

Construction Prone to Digitising the Problems It Should Be Eliminating

Construction companies are spending heavily on digital transformation, replacing spreadsheets, disconnected databases and ageing management systems with cloud platforms, integrated data environments, automation and, increasingly, artificial intelligence. Installing modern technology does not automatically create a modern business, and there is a surprisingly reliable way to spend a large transformation budget and emerge with many of the same problems that existed at the outset. The organisation rebuilds them.

The danger surfaces during one of the most ordinary parts of any technology implementation, which is establishing requirements. Project teams ask departments what the new system needs to do, users describe how they currently work, consultants document those processes and developers work out how to reproduce them inside the new platform. Everything about that sequence sounds sensible, yet it rests on a quiet assumption that rarely survives scrutiny. Many existing processes were never deliberately designed at all, because they accumulated over years, one workaround at a time.

A spreadsheet may exist because two older systems could not exchange information. An approval stage may have appeared because managers stopped trusting the underlying data. Someone may reconcile two reports by hand because different departments keep their own records, and a weekly management report may exist only because decision-makers cannot reach operational information directly. Over time these fixes harden into normal business practice, and eventually they acquire a more dangerous label. They become requirements.

Move them unquestioned into a new platform and a company can spend millions digitising the limitations of the very systems it has just paid to replace. The most important question in a transformation programme is therefore not whether the new system can perform a given task. It is why the organisation performs that task at all.

Briefing

• Digital transformation can preserve inefficiency when organisations reproduce existing workflows without examining why those workflows developed in the first place.
• Construction is especially exposed, because fragmented project, commercial, accounting, plant, workforce and document systems have historically demanded heavy manual reconciliation and duplicated information handling.
• Custom software can be strategically valuable, but recreating legacy processes through bespoke development introduces fresh maintenance, integration, testing and upgrade costs that persist for years.
• Technical debt already consumes a meaningful share of technology budgets, with McKinsey estimating that companies pay an additional 10 to 20 per cent on projects simply to work around existing debt.
• Artificial intelligence raises the stakes, because automating an inefficient workflow does not remove the inefficiency; it allows an organisation to execute the wrong process faster and at greater scale.

When Workarounds Become Business Processes

Every established organisation carries a history inside its processes. Some workflows exist because of regulation, others to protect safety, commercial control or quality, and some represent hard-earned operational knowledge that contributes directly to competitive advantage. Others exist simply because somebody solved a problem fifteen years ago and nobody has revisited the solution since.

Consider a contractor whose project teams record progress in one system while commercial teams work in another. Because those systems cannot communicate reliably, someone exports the information into Excel every Friday, another employee checks the spreadsheet against invoices, and a manager reviews the reconciled figures before somebody keys the approved numbers into a third application. Nobody set out to design that process, and each individual step probably made sense when it was introduced, yet collectively they represent an integration problem being solved by people rather than software.

Construction contains countless variations on this pattern. Estimating, procurement, accounting, plant management, workforce systems, project controls, BIM, document management, quality inspections and asset information have frequently grown up as separate technology environments. Where the software could not talk to itself, people connected it, exporting CSV files, copying numbers between systems, emailing spreadsheets, reconciling reports, renaming documents and building increasingly elaborate Excel models in the gaps between applications. Those employees effectively became human APIs, and the danger arrives when a transformation team encounters their work and assumes it represents a requirement rather than a symptom.

Requirements Gathering Can Become Process Archaeology

Traditional requirements gathering usually begins with a reasonable enquiry into what the business needs. The difficulty lies in separating what the business genuinely needs from what it currently happens to do, because the two are not always the same thing. A project manager might insist that a particular report is essential, only for further investigation to reveal that the report was introduced years earlier because management lacked real-time visibility of project performance. If the replacement platform now provides that visibility directly, reproducing the report adds little beyond cost.

The same logic applies to approvals. A five-stage approval workflow can look like careful governance, when in reality stages three and four were introduced because different departments did not trust the information produced by stages one and two. Fix the underlying data problem and several of those controls may no longer be necessary. Duplicated data entry deserves the same scrutiny, because if site personnel enter equipment information into a project system and head office later enters the same information into an enterprise system, the requirement is not to make the second screen easier to use. The better requirement is to remove the second entry altogether.

This is why effective transformation depends on a form of process archaeology. Teams need to understand not only what people do, but when a process first appeared, why it appeared, which problem it originally solved and whether that problem will still exist in the proposed environment. Without that investigation, requirements gathering collapses into process transcription, in which the organisation describes yesterday’s business and the implementation team faithfully rebuilds it for tomorrow.

Construction Is Particularly Vulnerable to Digital Inheritance

The problem intensifies in construction because projects assemble temporary organisations around long-lived corporate systems. A major contractor may need to connect information from clients, consultants, subcontractors, suppliers and its own operational departments, each of which uses different software, naming conventions, data structures and approval processes.

The workflows that emerge from that environment are full of compromises. Documents are downloaded because external users cannot reach the internal system, information is reformatted because one platform cannot consume another’s output, duplicate registers appear because two parties need different views of the same data, and additional approvals are inserted because accountability blurs whenever information crosses an organisational boundary.

Those processes can survive long after the original technical limitation has disappeared. The risk grows when organisations undertake large ERP, construction management or common data environment implementations and try to accommodate every established practice. Modern platforms are often extremely configurable, and while that flexibility is genuinely useful, it also allows a business to preserve enormous quantities of historical complexity.

Every department has a reason why its workflow is different, every regional business has an exception, every project type has a special case, and every long-serving employee remembers why something has always been done a particular way. Taken individually the arguments are persuasive, but taken together they can turn an ostensibly standard implementation into an intricate recreation of the organisation’s existing operating model. The business has bought a new system without having transformed anything.

Customisation Has a Lifecycle Cost

Custom development is where the problem becomes genuinely expensive. There are legitimate reasons to customise software, since a contractor may operate proprietary processes that truly differentiate its business, and specialist engineering, unusual contractual structures, complex plant operations or distinctive delivery models can all justify capabilities that standard software does not provide. The important distinction is between customising around competitive advantage and customising around inherited inefficiency.

When users report that a new platform does not work the way they do, the instinctive response is to ask whether it can be modified. Technically, the answer is usually yes; commercially, it is only the start of the conversation. A bespoke feature has to be designed, tested, documented, supported by training, and secured, other integrations may come to depend on it, and when the platform is later upgraded a routine update can demand fresh testing to establish whether the customisation still works. The initial development invoice therefore represents only a fraction of the true cost, because customisation creates a lifecycle obligation, a decision made today that hands costs and constraints to every project that follows.

The scale of that liability is well documented. McKinsey estimates that companies pay an additional 10 to 20 per cent on projects to address existing technical debt, and that around 30 per cent of the chief information officers it surveyed believed more than a fifth of their new-product technology budget was in fact being diverted to resolve it. The lesson is not that customisation should be avoided, but that whether a business can build something and whether it should own it for the next decade are entirely different questions.

Complexity Compounds

Technology complexity rarely arrives as a single, obviously bad decision. It accumulates through hundreds of individually defensible choices, as a temporary integration becomes permanent, a project-specific database becomes business-critical, and a workaround acquires a workaround of its own because changing the original system would be too disruptive. Eventually, future transformation projects must work around the architecture created by earlier ones.

McKinsey describes this as a vicious cycle, in which temporary fixes, outdated solutions and one-off developments progressively make each subsequent modernisation harder. The firm cites one large business-to-business company whose leadership identified a potential $2 billion margin opportunity across dozens of modernisation initiatives, only to discover that most of them depended on technology carrying a price tag of around $400 million, far higher than expected, because years of quick workarounds had left the technology estate massively complex. The company cut its investment back to roughly $300 million, walked away from a quarter of the margin opportunity, and, two and a half years later, had completed only half of the planned work because the unresolved issues continued to undermine every subsequent project. That is what inherited complexity costs in practice.

There is further evidence that large technology projects carry risks conventional budgeting tends to underestimate. Research led by Bent Flyvbjerg at the University of Oxford, published in the Journal of Management Information Systems, examined 5,392 IT projects and found that their cost overruns follow a power-law distribution. In plain terms, a large number of projects run modestly over budget while a smaller but significant tail runs catastrophically over, and the researchers point to interdependencies between technology components as one mechanism capable of triggering chain reactions in cost. For decision-makers who plan around average overruns, that fat tail is precisely the risk that does not appear in a conventional business case.

Unnecessary complexity is therefore more than an inconvenience for the IT department. Every additional dependency adds something that future projects must understand, maintain, test and change, which is why, for construction executives weighing digital investment, simplicity carries measurable economic value. A feature that is never built cannot break during an upgrade, an approval that is eliminated needs no configuration, and data entered once needs no reconciliation.

Automation Can Make Bad Processes Faster

Artificial intelligence makes this discussion more urgent rather than less. The next phase of enterprise technology is moving beyond digital record-keeping towards systems that can interpret information, initiate actions and eventually execute multi-stage workflows on their own, and businesses are modernising their technology estates partly because that ambition depends on integrated, trustworthy data.

Capgemini chief executive Aiman Ezzat framed the dynamic sharply in late July 2026, describing a multi-year modernisation supercycle as companies prepare to run AI at scale. The real barrier to wider adoption, he argued, is not access to models but the legacy systems, fragmented data and complex technology estates built up over decades. Organisations everywhere want to become agentic, Ezzat told analysts, but before they can become agentic, they must become AI-ready, and most are not.

That framing exposes an important gap between automating a process and improving it. Suppose five people currently approve a purchasing decision because, historically, nobody trusted the information available to the first approver. Digitising that workflow produces five electronic approvals, automating it routes those approvals instantly, and adding AI helps each person review the request faster, yet none of those steps addresses whether five approvals remain necessary at all. The organisation has simply progressed from manual inefficiency to digital inefficiency and, finally, to automated digital inefficiency.

AI is especially good at disguising this problem because automation generates visible activity. Documents move faster, reports appear on their own, reconciliations complete in seconds and notifications arrive immediately, while the underlying process remains exactly as flawed as before. There is a direct parallel in technology modernisation itself, where McKinsey has warned that simply converting old software into a modern equivalent can transfer technical debt from the legacy environment into its replacement rather than eliminating it. Business processes deserve the same suspicion, because automating yesterday’s workaround does not create tomorrow’s operating model.

Transformation Should Start With Outcomes, Not Features

The alternative sounds obvious and is difficult in practice, because it begins with the outcome rather than the activity. When an employee requests a report, the useful step is to establish which decision the report supports; when a department requests an approval stage, to establish which risk it controls; when information must be entered twice, to establish why two systems need separate copies; when somebody checks a figure by hand, to establish why the original figure is not trusted; and when a bespoke feature is requested, to identify which business capability would disappear without it.

These conversations change the role of the implementation team. Instead of merely confirming whether requested functionality is technically possible, the team becomes responsible for understanding the consequence of building it, which requires explicit permission to challenge requirements. That can be uncomfortable, because established processes have owners and long-standing workflows acquire institutional authority simply by surviving, so removing a process often feels riskier than digitising it.

There are also cases where an old process exists for a sound reason that is not immediately visible, and safety, regulatory, contractual and financial controls should never disappear merely because a programme is pursuing simplification.

The objective is not indiscriminate removal but evidence. Every significant requirement should be able to demonstrate the outcome it supports, the reason that particular process is necessary to achieve it, and the cost of maintaining the decision across the life of the system. Those three tests turn requirements from instructions into investment decisions.

Standardisation Is Also a Management Decision

This exposes a more uncomfortable issue, because many technology projects become heavily customised for a reason that has nothing to do with technology: organisations are reluctant to standardise themselves. Divisions acquire their own systems through decades of organic growth and acquisition, regional operations adopt different terminology, and project teams develop local practices around particular clients. Implementation forces a choice between configuring the platform around all of those differences and deciding, instead, how the company actually wants to operate.

The second path is harder because it demands management decisions rather than software decisions. Somebody has to determine whether three approval processes should become one, whether a single source of data should become authoritative, and whether a department genuinely requires its own workflow. Software cannot make those organisational choices, which is why programmes drift towards customisation, since configuring another workflow is often politically easier than resolving why two parts of the same company insist on working differently. Digital transformation is, in large part, an exercise in organisational design, with the technology merely making the consequences visible.

The Smartest System May Do Less

Construction’s enthusiasm for digital technology is well founded. Connected project platforms, mobile working, BIM, digital twins, automated workflows, AI and structured asset information can strip enormous amounts of friction out of project delivery. Technology, however, has no inherent ability to distinguish a valuable process from an obsolete one, and it will execute both with equal willingness, which places the responsibility firmly back with the people designing transformation programmes.

Before replicating an existing workflow, those teams need to understand its history; before commissioning bespoke development, they need to understand its lifecycle cost; and before automating an activity, they need to establish whether the activity should exist at all. This discipline matters more with each passing quarter, because AI is lowering the technical barriers to building software and automating processes, which makes it easier, not harder, to manufacture unnecessary complexity at speed. The defining skill of the next phase of construction digitalisation may therefore be restraint.

Modernisation should not mean taking everything an organisation currently does and making it digital. It should be an opportunity to decide what deserves to survive. The companies that grasp that distinction will not simply swap old technology for newer technology; they will use the transition to remove the compromises, duplications and workarounds that accumulated around systems which no longer exist. That is genuine transformation, and sometimes the most valuable feature delivered by a multimillion-pound technology programme will be the one somebody was brave enough not to rebuild.

Key Industry Questions

1. Why do digital transformation projects recreate old processes? Most implementations begin by establishing what users need from the replacement system, and employees naturally describe the processes they currently perform. Some of those processes represent genuine operational requirements, but others developed as workarounds for limitations in previous software, fragmented data or poor integration. Unless the implementation team investigates why each activity exists, those historical compromises are documented as requirements and rebuilt in the new platform, so the organisation modernises its technology without modernising its operating model.
2. What is the difference between a business requirement and a legacy workaround? A genuine requirement supports an identifiable outcome such as safety, regulatory compliance, commercial control, quality or operational performance. A workaround exists because another part of the process or technology environment cannot deliver that outcome directly. The distinction can usually be uncovered by repeatedly asking why an activity is necessary. If a report exists because managers cannot access reliable information, for instance, the underlying requirement is reliable information rather than the report itself, and identifying that before implementation removes unnecessary features and workflows.
3. Is custom software bad for construction companies? No. Custom development can create significant value when it supports a genuinely distinctive capability that standard software cannot accommodate. Problems arise when bespoke development is used to preserve processes that exist primarily because of historical technology limitations. Custom functionality also carries lifecycle costs well beyond initial development, including testing, documentation, training, integration maintenance and potential complications during upgrades, so construction companies should evaluate customisation as a long-term investment rather than simply asking whether a particular feature can technically be created.
4. How does technical debt affect digital transformation budgets? Technical debt is the future cost created by earlier technology decisions, including temporary fixes, outdated systems, one-off integrations and bespoke development. McKinsey estimates that companies pay an additional 10 to 20 per cent on projects to address existing technical debt. As dependencies accumulate, modernisation becomes harder because new platforms must accommodate or replace the architecture created by previous decisions, so reducing unnecessary complexity during today’s programme lowers the cost and risk inherited by tomorrow’s.
5. Why is construction particularly vulnerable to duplicated digital processes? Construction depends on temporary project teams and extensive supply chains while simultaneously relying on permanent corporate systems. Estimating, procurement, accounting, workforce management, plant, BIM, project controls, documents and asset information may all reside in different applications, and employees have historically bridged those systems through spreadsheets, exports, emails, manual checks and duplicate data entry. These activities gradually become accepted business practice, so when platforms are replaced, organisations must distinguish between processes that genuinely support construction delivery and those that merely compensated for disconnected technology.
6. Can AI fix inefficient business processes? AI can accelerate processes, interpret information and automate tasks, but that does not make the underlying workflow necessary or efficient. An unnecessary approval remains unnecessary when an AI agent routes it automatically, and a redundant report remains redundant when AI generates it instantly. Companies preparing for agentic AI therefore need to examine processes as well as technology, and current enterprise modernisation activity is increasingly being driven by the need to provide AI with integrated systems and trustworthy data, which makes process simplification an important part of AI readiness.
7. What should companies ask before automating a workflow? The starting point should be the outcome rather than the existing process. Organisations should identify what decision, control or operational result the workflow supports, why each step is required, and whether the replacement technology removes any assumption on which the existing process was based. They should also weigh lifecycle implications such as maintenance, integration, testing and future upgrades. The purpose is not to remove legitimate controls, but to ensure every automated step continues to serve an identifiable business need.
8. How can construction companies avoid digitising legacy inefficiency? Transformation programmes need authority to challenge requirements before configuration or development begins. That means involving operational users while also examining why their processes developed, identifying duplicated information, questioning manual reconciliation and separating competitive differentiation from historical exception. Standardising data and workflows can require difficult management decisions, particularly across regional businesses and acquired companies, and making those decisions before development begins is generally easier than trying to simplify the platform once integrations, documentation, training and testing have been built around unnecessary complexity.

Strategic Takeaways

1. Do not confuse existing processes with genuine requirements, because some workflows are valuable controls while others are historical workarounds created by systems the organisation is replacing.
2. Customisation should protect competitive advantage, not inherited inefficiency, as bespoke functionality creates lifecycle obligations extending well beyond its initial development cost.
3. Construction’s fragmented technology history makes process archaeology essential, since manual reconciliation, duplicated entry and spreadsheet workflows usually reveal integration problems rather than fundamental business needs.
4. AI amplifies poor process design, because automating an unnecessary activity makes it faster without making it more valuable.
5. Simplification has measurable economic value, as every unnecessary feature, integration, approval and dependency removed today is one less component that future transformation programmes must maintain, test and replace.