CDE platform adoption – why teams go back to email despite a deployed system

CDE platform adoption is a problem that rarely appears in tender documents, yet it decides whether the entire implementation succeeds. The system may be formally up and running, everyone has access and passwords, and still documents keep circulating around the company by email. According to a 2024 Boston Consulting Group study, as many as 74% of companies adopting new technologies fail to achieve tangible value from them – and although that study concerned artificial intelligence rather than CDE platforms, the mechanism behind it is exactly the same. This article shows why this happens in construction and what genuinely increases the chance that the team will use the system every day, not just when someone reminds them.

1. Symptoms: what superficial CDE adoption looks like

Before we get to the causes, it is worth recognising the problem itself. Superficial CDE adoption does not look like a failure or a team rebellion. It looks like ordinary, everyday work – the system runs, people log in, the features are available. The problem is quiet, which is why it is easy to miss.

1.1 Documents still circulate by email, just to be safe

The most characteristic symptom of superficial adoption is a double workflow. A document goes into the CDE platform because it formally has to. At the same time, the same person emails it to a few key recipients to make sure it arrives and gets read. As a result, the company pays for a system whose job is to eliminate email, yet keeps exactly the same email workflow as before – just with an extra step.

1.2 Logging in once a week to upload the backlog in bulk

Another common pattern is putting off work in the system. The site manager spends the whole week collecting photos, notes and scans on their phone or in a folder on their computer. Only on Friday afternoon do they upload everything to the platform in one big batch. Formally, the data ends up in the CDE, but in practice nobody else has access to it for most of the week. The system’s whole advantage – real-time, up-to-date information – simply disappears.

1.3 One person acting as the system’s interpreter for the rest of the team

Many teams also develop an informal intermediary role – usually the youngest or most patient person, who knows how to use the system and therefore does it for everyone else. The rest of the team sends them documents by email or messenger, and they enter them into the platform. This solves the problem in the short term. But it also means that adoption really concerns one person, not the whole team – and sooner or later that person will change jobs, go on holiday or simply burn out.

2. Why this happens – the three most common causes of low CDE adoption

It is worth stressing that low adoption rarely stems from the system being technically poor. In practice the causes lie elsewhere – in the way the implementation was planned and carried out.

2.1 Implementation treated as an IT project rather than a change in the way people work

This is neither new nor specific to CDE platforms. Research on CRM and ERP implementations – software of a similar scale that meets a similar kind of resistance from teams – has described exactly the same mechanism for years. According to data cited by the analyst firm Forrester Research, almost half of CRM implementations fail. The single biggest cause of failure – more than a fifth of all reported problems – is a lack of user adoption, not the technology itself.

A similar picture emerges from ERP implementations, i.e. software that, like a CDE platform, is meant to replace scattered manual processes with one coherent system. The advisory firm Gartner estimates that more than 70 percent of recently implemented ERP systems do not fully achieve their intended business goals. Moreover, according to research by Prosci, human factors have six times more influence on implementation success than purely technical ones. These figures come from software categories other than CDE platforms, but the mechanism repeats: the team gets a new tool, sees no benefit in it for their day-to-day work and goes back to old habits – whether it is a CRM, an ERP or a construction document management platform.

2.2 No clear benefit for a specific role in the team

The same functional requirement in tender documentation means something completely different to a site manager, a designer and a client – we described this mechanism in more detail in the article How to write CDE platform requirements that actually work. The same mechanism is at work on the adoption side. If the site manager does not see a concrete, everyday benefit from using the system – for example, less time spent finding the current version of a drawing – no number of features on the requirements list will change that. Teams do not adopt a tool because it is technically advanced. They adopt it when they see that it makes life easier at the exact moment they use it.

2.3 The system adds a step instead of removing one

The third cause is the most practical and, at the same time, the one most often overlooked when planning an implementation. If using the CDE platform in practice means more clicks and more time than emailing the same document, the team will sooner or later return to the old habit – no matter how hard management pushes. A well-designed process in the system should be a shorter path to the goal, not a longer one.

Management’s declaration vs. reality on site

3. The cost of superficial adoption – why it is more than an inconvenience

3.1 Two sources of truth mean the same errors come back

The whole point of a CDE platform is that at any given moment there is only one current version of a document, accessible to all authorised project participants. But as soon as part of the team keeps using email as a parallel channel, that principle no longer holds. The very problem the CDE was meant to eliminate returns: someone works on an outdated drawing because they received it by email a week earlier and did not check whether a newer revision had appeared in the system.

3.2 Incomplete data only causes damage later

If data reaches the system late or only partially, the consequences do not show up straight away. They surface at final handover, during an audit of as-built documentation or in a dispute with a subcontractor. That is when it turns out that the decision history in the system is incomplete, because some agreements circulated by email the whole time and never made it into the platform. As a result, you pay twice: once for the system, and again for the time needed to reconstruct the missing information from other sources.

3.3 The cost grows quietly, because nobody reports it as a failure

Unlike a technical failure, low adoption does not generate a support ticket. The system works, so formally there is no problem to solve. Meanwhile the cost builds up in the background: duplicated work when handing over documents, time lost searching for the right version of a file, delays in approvals because part of the team does not check the platform regularly. None of this appears in a report as a single, large cost. Yet the sum of these small losses can be greater than the cost of the system subscription itself.

*Data on CRM (Forrester Research) and ERP (Prosci) implementations – cited as an analogy from industries of similar organisational scale, not as data directly concerning CDE platforms.

4. What actually increases CDE platform adoption

Now that we know where the problem comes from, let’s move on to practices that genuinely increase the chance that the team will use the system for good, not just on paper.

• Start with one specific process – not with rolling out the entire system at once. Choose the process that hurts the team most, for example document approval, and move it to the platform first. Only once that single process runs smoothly should you extend the scope to other areas.
• Train each role separately – the site manager, designer, coordinator and subcontractor use the platform in completely different ways. A single joint training session for everyone usually means that nobody gets knowledge tailored to their day-to-day work.
• The system has to be faster than email in practice, not just in theory – if uploading a document to the platform takes more clicks than emailing it, the team will choose the faster option, regardless of which one is formally required.
• Appoint someone responsible for adoption, not just technical implementation – someone on the team’s side should monitor whether the system is actually used in daily work and react when the team starts slipping back into old habits, before that becomes a permanent routine.

5. How we approach this at Hustro

At Hustro, the priority is implementing the solution properly in the company – both in terms of processes and training. Instead of forcing a new way of working on the team from day one, we focus on the client’s existing processes and then gradually move them into our solution – step by step, starting with whatever is slowing the team down the most at that moment. This approach does not eliminate the risk of low adoption entirely, but it significantly reduces it, because from the start the team sees a concrete, practical benefit instead of learning a new tool in isolation from their daily work.

A good example is Mota-Engil Central Europe, an international general contractor operating in 28 countries, which tested several other construction defect management tools before implementing Hustro.

Summary: how to increase CDE platform adoption in your company

To sum up, there are three things worth remembering from this article. First, low CDE platform adoption rarely stems from flaws in the system itself. Most often it stems from treating the implementation as an IT project rather than a change in how specific people work. Second, the cost of superficial adoption grows quietly and only surfaces later – for example at final handover or in a dispute with a subcontractor – so it is worth monitoring before it becomes visible. Third, what genuinely increases adoption is a phased rollout, training tailored to each role, and a person responsible for making sure the system remains a faster path to the goal than email. Not just on go-live day, but throughout the project.