CDE platform requirements that work – not just on paper

In most tender documents, CDE platform requirements look much the same: a long list of features, a few security requirements, a mention of the SaaS model and local-language support, in line with standards described, for example, by buildingSMART. It is tempting to treat such a list as a checklist to tick off. But a ticked-off checklist and a system you can actually work with are two completely different things.

This article shows how to move from a list of formal tender requirements to requirements for a system your team will actually use. It is based on conversations and tender documents collected during bidding processes over the past few months.

1. The longer the CDE requirements list, the worse the contract

1.1 What choosing a CDE platform looks like in practice

When a general contractor prepares for a tender, they gather the necessary documents and check whether their current CDE solution meets the requirements. If it does not, they start looking for a new vendor. At that point, attention naturally shifts to comparing offers.

They look for potential vendors, contact them and compare their systems against the tender requirements. At this stage the focus is more on the question “what must the system have?” than “what must the system do for me?”. It is a subtle but crucial difference – and one of the most common traps when choosing a CDE platform.

1.2 Where does this trap come from?

Each feature on the requirements list is described in one short sentence. As a result, that sentence says nothing about how the feature actually works. If the software “has” everything on the list, it is easy to assume it will be good. In practice, however, individual features are only tools – the goal of implementing software is to improve processes, not simply to have features.

1.3 Example: the document approval process

Let’s look at this in detail using the popular feature “document approval process”. On the one hand, this short description can hide a simple process in which documents are approved one after another, entirely manually and without any additional automation.

On the other hand, it can be a system in which several people review a document in parallel, an automatic alert is shown to all decision-makers if someone misses the deadline, and everything is recorded in a single, clear history view. Crucially, both solutions meet the same one-sentence requirement – even though one is many times more advanced than the other.

Document approval process – tender specification entry vs. system requirement

1.4 Changing how you define requirements

Above all, change your attitude to software. The purpose of an application is to serve people, automate and organise work – not to be a box-ticking exercise for a tender. Instead of asking “does the system have this feature?”, ask “how will this feature work in my specific process?”. In other words, instead of a list of fifty short points, it is enough to define ten points together with what meeting each of them actually means.

Do you see the difference?

2. Functional CDE requirements – what the system should do

To back this up, the analysis below is based on real documents: descriptions of the subject of the contract, terms of reference, annexes to implementation agreements and requests for proposals. Construction dominates, but the material comes from different contract models and projects of different scale.

2.1 Functional requirements for a CDE platform

Having analysed the documents, the section of the tender specification covering software and the CDE platform almost always includes the following features:

• Document versioning – with a full revision history
• Configurable approval process – for accepting and approving documents
• Permission and role management – for users
• Filtering and search – of documents by metadata
• Correspondence register – letters, notes, handover protocols, replies
• Email notifications – about status changes, deadlines and tasks
• Reports, summaries and dashboards

2.2 Features that appear less often

Less often, but still regularly, the following appear:

• Mobile app – for reporting defects and incidents on site
• Material submittals module – submission, review and approval
• Automatic protocols – for documentation handover
• Support for 3D BIM models – coordination in IFC format
• Asset register – linked to technical documentation
• Validation of data completeness and quality – before handover

2.3 Example: what a feature’s name does not tell you

Each feature on the first list is general enough to be found in most products on the market. Its mere presence on the list tells you nothing – the value only becomes visible in use. Take “document versioning and full revision history”. Every vendor will say they have it. But what does it really mean in day-to-day work?

Does each new version of a document replace the previous one in the main view, so that old versions have to be deliberately looked up in the history? Or does the system clearly mark which version is current and which are archived – visible to everyone, without extra clicks? And can you compare two versions side by side, or do you have to download and open them separately? “Document versioning” in one sentence covers all these variants. In other words, only a description of how the feature should work in daily practice distinguishes one product from another.

3. Security, standards and support – CDE requirements in a tender

Besides features, every tender document contains requirements for data security, compliance with standards, and implementation and support. Each of these areas requires checking something different with the vendor – and each has its typical pitfalls.

3.1 Data security requirements for a CDE

This area is described relatively well in the documents – probably because IT and legal departments have firm views here. The standard set looks like this:

• Data hosting exclusively in the EU
• At least two redundant data – processing centres
• ISO 27001 certificate – confirmed by an independent audit
• Two-factor authentication (2FA)
• Access only after logging in
• User activity log
• 24/7 availability – with a defined SLA

3.2 ISO 27001 and ISO 19650 – which standards the market requires

This is the area that most clearly separates general contractors new to CDE from those who already have several implementations behind them. The basic level is ISO 27001 – described above in the context of data security. It appears everywhere.

3.3 ISO 19650 as a higher level of requirements

The higher level is ISO 19650 – the standard for information management in a BIM environment. It defines how information should be created, verified, approved and archived on construction projects, distinguishing four work areas: work in progress, shared, published and archive. ISO 19650 appears rarely – but where it does, the whole tender document is of a different quality.

3.4 What is worth doing now

Even if this particular tender does not require formal ISO 19650 certification, it is worth checking whether the software you choose supports a way of working consistent with the standard. Above all, it protects you for the future – if ISO 19650 becomes a requirement in the next tender, you will not have to start your search from scratch.

3.5 Implementation, training and support – additional requirements

Implementation, training and support are often treated as an add-on in tender documents. In practice they decide whether the system will actually be used or only exist on paper. In the tender specification they are usually described in a single word. It is worth raising these topics when talking to a vendor:

• Implementation timeline with milestones – not “up to 3 months”, but a concrete schedule with dates and acceptance conditions
• Training for all roles – administrators, coordinators, contractors, subcontractors; separately, not one session for everyone
• Technical support in your language – with a defined response time
• Ability to reconfigure during the contract – without programming and at no extra cost

3.6 What appears too rarely

• Clarity on price guarantees and scope of services – for the entire contract period, not just the first year
• The option of regular, self-service data export – as a routine option during the contract, not only in case the cooperation ends

3.7 Why this is not about system features

This is not a question of system features, but of how conditions change on a project that lasts several years. As a result, most general contractors only discover these questions once prices have already gone up or support has already shrunk.

4. Access to CDE documentation after the project ends

4.1 Why it matters

The project ends, the building is put into service, the contract with the general contractor is settled. Then the question arises: where is all the documentation – design, construction, as-built, correspondence, decision history? And, importantly, can the client access it without anyone else’s involvement?

The client needs the documentation to operate the building, handle warranties, and carry out inspections or refurbishments – often for many years after the project ends. The general contractor, in turn, may need access to the same data for a shorter period, for example to defend against claims or for settlements. Importantly, once the project is over, the contractor usually no longer has any reason to maintain the platform. The problem is that this topic is rarely addressed explicitly in tender requirements.

4.2 What to include in the requirements

Instead of a general “ensuring access to data”:

• Export of documentation with metadata and folder structure – in a format that can be opened without the vendor’s software (e.g. PDF, DWG, XLSX)
• Clarity on whether export is a standard platform feature – available from the interface, or whether it requires a request and a separate quote
• Turnaround time for an export on request

4.3 Practical advice

Don’t wait until the end of the project to export. If the platform allows you to download data regularly during the contract, make use of it periodically – for example, when closing each stage. In other words, what you already have is certain. What “will be available after the contract ends” depends on many factors you have no control over.

5. One requirement, three teams – what really changes

5.1 Context of use – why the same requirement means something different to everyone

Position and the nature of the work shape how we understand a system’s features – that is the context of use. Take an example from a tender specification: “the system must support large CAD files with preview and allow 3D models to be viewed”. From the client’s perspective, this is one of many requirements on the list – it sounds reasonable and fits the fact that the project is designed in BIM. But the same sentence means something different to each party.

5.2 The general contractor’s side – site managers and engineers

For site managers and engineers on the contractor’s side, who have so far only used paper documentation and have never opened a 3D model, simply “providing a 3D model viewer” changes nothing. The model will sit on the platform unused – the requirement formally met, practically meaningless.

On a construction site, software is a tool just like a drill – it takes practice, experience and solid training. It is also worth remembering the hardware: for a 3D model to open smoothly, it needs powerful smartphones or tablets – not the cheapest model that happened to be in stock.

5.3 The designer’s side

The designer will be more interested in the form and quality in which they will deliver models. Do they update the model on the platform with every revision, or only at key stages? If the requirement does not specify this, the designer will do whatever is most convenient – which may not be what the client actually expected.

5.4 The client’s side

For the client, the question is what they actually want to do with it. Should the 3D model be used to verify that construction matches the design, to coordinate disciplines, or perhaps for future facility management? If the answer is “I don’t know yet, but it’s worth having”, the requirement will be met formally, and the model will never be used in a way that justifies maintaining it.

5.5 How to phrase CDE requirements better

Every functional requirement in a tender specification is at the same time an instruction for three teams who will have to change something in their daily work – even if the requirement seems to concern “only” the system. Before a requirement goes into the document, it is worth going through it from each party’s perspective and asking a simple question: what does this mean for day-to-day work?

If the answer for the designer, the general contractor and the client’s team is “nothing changes, we just click somewhere else”, the requirement is safe – but probably not very valuable either. If, on the other hand, the answer is “we have to change how we hand over, receive and check documentation”, that is a sign that the requirement is real and has a chance to change something. What’s more, it is also a sign that simply putting it in the specification is not enough: who on each of the three teams will be responsible for making sure that change actually happens?

5. Summary: how to prepare requirements for a CDE platform that will really work

The CDE requirements list from a tender is a starting point, not a technical specification. It tells you which features the software must have to formally pass the evaluation. But it does not tell you how those features should work for your team to want to use them. To sum up, there are three things worth remembering from this article.

5.1 Break general requirements down into scenarios

Every general phrase on the list – “versioning”, “approval process”, “technical support” – covers solutions of very different quality. So before you sign a contract with a vendor, break the most important points down into concrete scenarios – just as we did with the document approval process.

5.2 Check what is not on the list

In addition, some of the most important questions do not appear on the list at all, because they concern not system features but the terms of cooperation over time: whether prices are guaranteed for the entire contract period, whether data export is a real, ongoing option, and whether access to documentation will survive the end of the project.

5.3 Remember that a requirement is a change in people’s work

Finally, every requirement is not just an entry in the system – it is a change in the work of specific people: the site manager, the designer, the client. As a result, software that formally “has” a feature but that nobody uses is no different from software that does not have it at all.