Detail Design Out of Sync? How to Build a Coordinated Toll Road DED

Picture a situation that a toll road contractor's team could easily face. Pier foundation work is ready to start. But when the site team checks the structural drawings against the latest drainage drawings, a box culvert runs straight through the pile cap area. The utility drawing used by another team shows a cable route that has not yet been relocated at the same spot. Each drawing looks correct on its own. The problem only appears when they are overlaid.

Note: the scenario above is a hypothetical illustration, not an event from a specific project or client.

This article explains why the detail design in a toll road DED can fall out of sync, what the root causes are, and how to build a coordinated DED from the start, whether you receive the DED from a design consultant or prepare and refine it yourself under a design-and-build arrangement.

Executive Summary

The problem. In a toll road DED, geometry, pavement, drainage, structures, utilities and right-of-way boundaries are produced by different disciplines on different revision cycles. The result is geometric clashes, elevation mismatches, and gaps between drawings and quantities.

The main causes. There is no single source of data, coordinates and datums are inconsistent, naming and document status rules are missing, cross-discipline coordination happens late, and drawings are issued without a clear quality gate.

The core solution. Define information requirements and a delivery plan (BEP) early; manage documents in a Common Data Environment (CDE) with clear status; harmonise coordinate systems and naming; federate discipline models and run clash detection on a regular cycle; manage interfaces with a register and documented coordination meetings; and add a QA gate before issue.

An important limit. BIM and software do not automatically fix a poorly coordinated design. Results depend on process discipline, clear responsibility, and the quality of input data.

What Is a Toll Road DED?

Detailed Engineering Design (DED) is the detailed design stage that produces technical documents ready for tendering and construction, typically construction drawings, technical specifications, design calculations and quantity breakdowns. Terminology and exact contents vary between project owners, so the Terms of Reference (ToR) and the contract remain the primary reference.

On a toll road, the DED spans many disciplines at once: geometric design (horizontal and vertical alignment), pavement, drainage, structures (bridges, underpasses, culverts, retaining walls), geotechnics, utilities, road furniture, and the right-of-way (ROW). Because they all share the same physical space, a change in one discipline almost always affects another.

Identifying the Problem: What Does Out-of-Sync Detail Design Look Like?

Misalignment rarely shows up as one large error. It usually appears as a series of small findings that only surface during construction. Common symptoms include:

• Drainage invert levels that do not match outlet levels or ground levels on other drawings.
• Structural foundations that clash with channels, pipes or buried utilities.
• Cross-sections that no longer agree with plan views after one of them was revised.
• Quantities in the bill of quantities that differ from quantities recalculated from the latest drawings.
• Several drawing versions circulating among different teams, with no clarity on which one governs.
• Repeated requests for information (RFIs) about the same location because the root cause was never closed.

Many parties feel the impact: designers who must revise, contractor engineers waiting for clarification, site crews who stop work, quantity surveyors who recalculate, and project managers who must explain delays. The accompanying risks span schedule (delayed work), cost (rework and claims), quality (improvised fixes on site), and coordination (disputes over responsibility).

Root Cause Analysis

To solve the problem we must separate symptoms from causes. The most likely root causes, organised along the information workflow, are as follows.

1. No single source of data. Each discipline often works from its own files and versions. Without one authoritative location, nothing guarantees that everyone uses the same data.

2. Inconsistent coordinate systems and datums. If one team uses local coordinates and another uses a different system, models and drawings will not overlay correctly. On projects following the Bina Marga BIM guidance, modelling coordinates refer to SRGI2013.

3. No naming or document-status rules. Without naming conventions and statuses (for example work in progress, shared, published), it is hard to tell a draft from an approved drawing.

4. Coordination happens too late. If cross-discipline checks only occur just before drawings are issued, findings are expensive to fix because many sheets already depend on one another.

5. Unclear responsibility at discipline boundaries. Elements at the edges, such as drainage passing beneath a structure or utilities crossing the ROW, often have no clear owner.

6. 2D drawings and quantities travel separately. When quantities are calculated manually from drawings, each drawing revision may not be followed by a recalculation.

7. No QA gate. Drawings are issued without a cross-discipline consistency checklist.

Key Takeaway: Almost every symptom of misalignment comes from process and data problems, not simply drafting mistakes. The solution must therefore address process and data, not only software.

Solutions and Implementation Strategy

Here are seven steps that can be adopted progressively. Each is described in terms of what to do, why, how, who is involved, the expected result, and its limitations.

Solution 1: Define information requirements and a delivery plan early

What and why. Decide what information is needed from each discipline, in which format, and when. Without this, each team interprets what to deliver in its own way.

How. Prepare a BIM Execution Plan (BEP) covering roles, software and versions, exchange formats, naming conventions, level of detail, and the information exchange schedule. For projects under Directorate General of Highways (Bina Marga) Circular No. 11/SE/Db/2021, the service provider is expected to prepare a Tender BEP and a Project BEP.

Who. The project manager, a BIM manager or coordinator, and a representative from each discipline.

Expected result. Everyone starts from the same expectations.

Limitations. A BEP that is too long and unread by the team will not help. Keep it concise and update it when scope changes.

Solution 2: Manage documents in a Common Data Environment (CDE)

What and why. A CDE is a shared digital workspace that acts as the single source of project information. Its purpose is to reduce duplicate versions and clarify the status of every file.

How. Use a consistent status workflow. The Bina Marga circular above, for example, describes folders for Work in Progress, Shared, Published and Archived, and a Check, Review and Approve feature before information is shared. This is consistent with the information management framework of ISO 19650.

Who. The information coordinator, discipline leads, and approvers on the client side.

Expected result. A clear version and approval trail, and fewer obsolete drawings reaching the site.

Limitations. A CDE is only effective if the whole team actually uses it. If files continue to travel through other channels, the benefit disappears.

Solution 3: Harmonise coordinates, datums and naming

What and why. Models and drawings can only be overlaid if they share the same reference.

How. Set one coordinate system and datum for all disciplines, along with the survey control points. Define a naming convention that includes, for instance, project code, discipline, zone, level or location, and file type. The Bina Marga guidance describes a naming pattern of this kind.

Who. Surveyors, the BIM coordinator, and all model authors.

Expected result. Models from different disciplines combine without shifts, and files are easy to find.

Limitations. New conventions feel burdensome at first. Provide templates to make adoption easy.

Solution 4: Use a federated model and regular clash detection

What and why. Combining all discipline models into one federated model lets geometric clashes be found on screen rather than on site.

How. Schedule model federation regularly, for example at each major information exchange. Build a clash matrix that defines which discipline is checked against which. Set tolerances and priorities, because not all clashes matter equally. Classify findings into hard clashes (two elements occupy the same space), soft clashes (insufficient clearance), and workflow clashes (conflicting construction sequence).

Who. The BIM coordinator drives the process; each discipline's model owner resolves the findings.

Expected result. A traceable list of findings, each with an owner and a resolution status.

Important Alert: Clash detection results must be reviewed by people. Software can report hundreds of clashes, some of which are technically irrelevant, such as reinforcement against its host concrete. Without filtering and prioritisation, the team is simply overwhelmed.

Limitations. Clash detection only checks geometry that has been modelled. Elements that are not modelled will not be detected, and the technical correctness of the design must still be verified by the designers.

Solution 5: Manage interfaces with a register and coordination meetings

What and why. Many problems occur at the boundaries between disciplines. An interface register gives every meeting point an owner.

How. Create an interface register listing the location (for example where drainage meets a structure), the disciplines involved, the decision required, the responsible person and the deadline. Hold regular coordination meetings that focus on findings rather than general presentations. Record issues in a traceable format, such as BCF (BIM Collaboration Format) when the software supports it, or a simple ticketing system.

Who. The coordinator, discipline leads, site representatives and, when needed, utility owners or landowners.

Expected result. Documented decisions that do not depend on meeting attendees' memory.

Limitations. Meetings without follow-up only add burden. Close every issue with a clear status.

Solution 6: Link the model to drawings and quantities

What and why. If drawings and quantities are derived from the same model, a change in one place is more likely to be reflected elsewhere.

How. Define the attributes needed on objects (such as material type and dimensions), then use quantity take-off from the model as a cross-check against manual calculations. The Bina Marga circular states that, for projects within its scope, quantities for the cost estimate are taken from the quantity take-off of BIM objects.

Who. Designers, the quantity surveying team and the BIM coordinator.

Expected result. Quantity discrepancies are detected sooner.

Limitations. Results depend on the completeness of attributes and modelling discipline. A model built only for visualisation cannot be relied on for quantities. Japan's BIM/CIM guidance likewise cautions against modelling in so much detail that the model becomes an end in itself.

Solution 7: Add a QA gate before information is issued

What and why. A QA gate ensures that every drawing release has passed a standard check.

How. Prepare a checklist covering: coordinates and datum are correct; high-priority clashes are closed; drawings agree with the model; naming and status are correct; quantities have been compared; the revision log is complete. A package moves to Published status only after the checklist is passed.

Who. A reviewer who is independent of the author, plus the formal approver.

Expected result. Issued drawings have a consistent standard of checking.

Limitations. QA adds time to each release. Balance the depth of checking against the risk of each drawing package.

Practical Tip: Start where disciplines are most densely packed, such as around bridges, interchanges or utility crossings. It is easier to prove the value in a small area than to apply everything at once.

Comparison: Conventional vs Coordinated Workflow

Worked Example (Hypothetical Scenario)

The scenario below is only an illustration of how the approach works. It is not a Fujicon client case study.

Suppose a toll road section includes a river bridge, a drainage box culvert near the abutment, and an electrical cable route that still has to be relocated. Three teams work separately: structures, drainage and utilities.

Step 1. The coordinator sets one coordinate system and uploads the control points to the CDE. Each team uploads its model to the Work in Progress folder under the agreed naming convention.

Step 2. At the first information exchange, the models are federated and clash detection runs according to the matrix. The software reports, for example, a clash between the abutment pile cap and the box culvert, and insufficient clearance between the cable route and a foundation.

Step 3. The findings are filtered. Irrelevant clashes are excluded. Two high-priority findings are entered in the interface register, each with an owner.

Step 4. The coordination meeting decides that the drainage team will change the culvert level and alignment, while the utilities team adjusts the cable route. The decision is recorded, and the structures team updates the affected drawings.

Step 5. Before issue, QA checks that the model, drawings and quantities agree. Only after passing is the package moved to Shared or Published, following the approval workflow.

The outcome one would hope for in such a scenario is fewer clash findings on site, but the size of the benefit depends heavily on project conditions and cannot be promised in general.

Implementation Recommendations

Here is a realistic implementation sequence. The duration of each stage depends on project size, so no fixed figures are given.

1. Map the current situation. Identify the disciplines involved, file flows and recurring problem locations. Choose one pilot area.
2. Set the baseline rules. Coordinates, naming, document status, and exchange formats (for example native files and IFC where required).
3. Prepare the CDE and roles. Appoint an information coordinator and a model owner per discipline.
4. Run a coordination cycle in the pilot area. Federate, run clash detection, review, decide and close findings.
5. Install the QA gate. Use a simple checklist, then refine it based on findings.
6. Evaluate and expand. Review indicators you choose yourself, such as the number of repeated RFIs, the number of clash findings closed before release, or quantity discrepancies. Expand to other areas if results are adequate.

A note on data exchange: IFC (Industry Foundation Classes) is an open data schema for exchanging model information. The second edition of ISO 16739-1 (2024) added coverage of information needed for infrastructure facilities including bridges, roads, railways, waterways and port facilities. Actual support for road objects still depends on the software and the exchange requirements agreed in your project, so test your tool chain on a small sample first.

Expert Insight (Fujicon editorial perspective, not a quotation from any individual): Design coordination is a working habit, not a software feature. Tools help find clashes, but the decision about who changes what must still be made and recorded by people.

Conclusion

An out-of-sync toll road DED is usually not caused by a single mistake but by an accumulation of fragmented data, inconsistent rules and late coordination. A structured approach, from the BEP, CDE, shared coordinates and naming, a federated model with clash detection, interface management, to a QA gate, helps move problem-solving from the site back to the design stage.

A practical first step this week: pick one discipline-dense area on your project, agree coordinates and naming, then run one cycle of model federation and findings review. From there you can judge whether the approach is worth extending.

Discuss Your Project Needs

If your team wants to review its DED coordination workflow, prepare BIM modelling, or run clash detection and multidisciplinary coordination, Fujicon can be a discussion partner. Service information is available at Fujicon and BIM Solusi. You can also consult directly via WhatsApp. The scope and suitability of services for your project will be discussed during consultation.

FAQ

What is a toll road DED?
A toll road DED (Detailed Engineering Design) is the detailed design stage that produces construction drawings, specifications, calculations and quantity breakdowns used for tendering and construction. The exact scope follows the project's ToR and contract.

Why does detail design in a DED fall out of sync?
Common causes are fragmented data sources, inconsistent coordinates and naming, late cross-discipline coordination, and no quality check before drawings are issued.

Does BIM automatically solve DED coordination problems?
No. BIM makes it easier to federate models and detect clashes, but results depend on working process, data quality and team decisions.

What is clash detection?
Clash detection is an automated check on a federated model that finds elements that collide or sit too close together. Results must be reviewed and prioritised by the technical team.

What does a CDE do on a toll road project?
A CDE (Common Data Environment) is a shared digital workspace that acts as the single source of information, with file statuses such as work in progress, shared, published and archived.

Is BIM mandatory on toll road projects in Indonesia?
Bina Marga Circular No. 11/SE/Db/2021 states that BIM is applied to freeways and toll roads within a defined scope. Whether it is required on your project depends on the contract and the project owner, so please verify.

Where should we start if the project is already under way?
Start with one discipline-dense area, harmonise coordinates and naming, and run one model coordination cycle before expanding.