Thibaud Guerrero, Project Digital Lead for Bouygues TP Murphy JV, and Ioan Evans, Design BIM Lead for Arup Mott MacDonald JV.
Bouygues TP Murphy JV
Bouygues TP Murphy JV and Arup Mott MacDonald JV used Morta as a common starting point for deliverables across Asite and ProjectWise, then extended the shared structure into programme reporting, consents and procurement.
On Lower Thames Crossing, the contractor and designer used different document systems but needed a common way to plan and create deliverables. Bouygues TP Murphy JV and Arup Mott MacDonald JV made Morta the starting point for creation in both systems, then extended that shared foundation into programme reporting, consents and procurement.
Executive summary
Bouygues TP Murphy JV and Arup Mott MacDonald JV coordinated information for the Lower Thames Crossing Tunnels and Approaches package across Asite and ProjectWise. Thibaud Guerrero and Ioan Evans built the setup together, with shared names, user conventions and information delivery plans in Morta. A planned deliverable could initiate creation in the appropriate document system, using common code allocation and the contributor's profile. Design disciplines used a shared component catalogue to link component definitions to information requirements and configure design applications for IFC 4x3 delivery. Programme data also supported the dates other teams needed, while consent staff could compare planned work with actual document dates and statuses. This was a preliminary-phase implementation, with functional teams learning to build within shared standards and direct P6 API connections still to develop.
- Two CDEs, ProjectWise for design and Asite for contractor work, were connected through the shared delivery plan.
- Thibaud recalled more than a year of Morta use by the project team at the community session.
The results
The delivery plan became part of creating the work, rather than an Excel file submitted only to meet a contractual requirement. Contributors planned deliverables in Morta before creating them in a common data environment, or CDE. The process handled document codes across both systems and used each contributor's profile to determine the destination.
Programme information became useful beyond the planning team. Planners could organise and add to the data for milestone views and programme-on-a-page reports, giving other teams access to the dates they needed for consents, tendering and site work. Thibaud counted planners among the project's biggest Morta user groups.
Consent staff gained a comparison between planned work and actual CDE dates and statuses. Maintaining consent documents in the CDE fed their tracker, giving the team a practical reason to use the controlled document process.
The challenge
Designers, the contractor and supply-chain contributors needed to work to a common information structure while keeping their own access arrangements. ProjectWise served design work and Asite served the contractor. Naming, document codes and information requirements had to work across that divide.
A shared name is only useful when teams mean the same thing by it. On a previous HS2 project, Thibaud had found that different departments gave different answers when asked what the south portal meant. For Lower Thames Crossing, he wanted common definitions that teams could reuse instead of repeatedly naming the same thing differently.
The choice of system also had to suit a joint project. Thibaud wanted people to start working without first assembling a large supporting IT arrangement. Morta's immediate availability and open API were important to that choice, alongside a place where people could access information and contribute to it. More advanced data infrastructure might follow, but everyday project work still needed an accessible tool.
The solution
Make the delivery plan the starting point
Design, contractor and supply-chain teams planned their deliverables through task information delivery plans, or TIDPs, brought together in the master information delivery plan, or MIDP. Views and permissions limited access to the information each contributor needed. Client requirements and information standards informed that shared structure.
The MIDP connected to Asite and ProjectWise, with programme information from both the contractor and designer. Their P6 programme exports passed through quality review in the CDEs before synchronising into Morta. Direct P6 API connections were a possible next development.
In the process Ioan set out, populating a TIDP triggered the creation of the planned deliverables in the relevant CDE. If a document code had already been taken in one system, the process allocated the next available code. The contributor's user profile determined which CDE received the document. Planning, code allocation and creation therefore worked as connected steps across the two systems.
Document controllers could then use processing states to find problems with creation or updates. The interface separated access to deliverables, adding them to a TIDP, reviewing deliverables and administration. Colour-coded states distinguished created, updated or existing records from processing errors, and the administration area gave controllers a place to investigate and correct those errors.
Give design components shared definitions
Each design discipline created its components in the project component catalogue and linked them to asset, carbon and Uniclass requirements. The catalogue brought together client and industry information standards, including the buildingSMART Data Dictionary. It specified the geometry, alphanumeric information and documentation to be delivered for those components, giving disciplines a shared structure for both naming their work and defining what it needed to contain.
Ioan's team used those catalogue definitions to drive the design applications. Automation configured the software from the requirements held in Morta, through a create–automate–configure–deliver process ending in IFC 4x3 files. When standards changed, the team updated and relinked the catalogue information before pushing it into the applications again. The requirements were connected to how the design information was produced, rather than held separately from delivery.
That structure also gave the teams a basis for further component checking and carbon reporting. Linking deliverables to programme codes and TIDPs allowed progress to be reviewed against the plan. Ioan's next step was to develop these uses of the structured information, with some reporting in Power BI and some in Morta charts.
Put programme information to work
P6 remained the programme tool, but its information was needed well beyond the planners who maintained it. Consent teams needed to know when their process should start, procurement needed tendering dates, and delivery teams needed planned site-start dates. Repeated questions, exports and copied values took planners' attention away from maintaining the programme and working with production teams.
The planning team used Morta to organise, filter and enrich the extracted programme information for these uses. People could access the shared data and add information to it, while planners prepared milestone views and programme-on-a-page reports. Power BI still presented some outputs. Morta provided the place to connect programme data with the additional project information those reports needed.
The implementation
Agree the conventions together
Both joint ventures had administration rights and worked on the setup from the beginning. They agreed column-header colours, red–amber–green status colours, naming and categorisation across documents, tables and views. Contributors could recognise validation states and find information using the same conventions across their work.
A custom tile-based home page helped people reach the documents and tables they needed. Ioan wanted that navigation to become available by default, rather than remain an addition built for the project.
Decide which work to add
Ioan's suitability checks considered whether a dataset already existed, how it would interact with other data, who needed to share it, what permissions were required and how it would be tracked. The project team used those questions when deciding whether to add work to Morta. For Thibaud, the answer was not always Morta.
Their implementation used code behind the interface to support a no-code experience for the end user. Tables are not always the best way for people to interact with information. Thibaud also found that Morta's flexibility made it easy to create unwieldy structures, so organisation and a clear design remained necessary.
Add one connected use at a time
The initial temptation was to put everything in Morta. Thibaud's team returned to an incremental approach, using the established programme and MIDP as the foundation for each new use.
The consent team started with a register. Moving that list from Excel into Morta did little on its own. Connecting it to the CDE supplied actual document dates and statuses alongside the plan, so consent staff could compare the intended sequence with current progress.
Thibaud found that the tracker encouraged people to maintain their consent documents in the CDE. Their own tracking depended on that controlled information, which gave them a reason to follow the process rather than keep a separate manual account of progress.
Procurement followed, with project-level charts helping the procurement team see current progress in its tendering work. The team used Morta charts where all the relevant data was already in Morta. Where reporting needed outside data, Power BI still had a role. Temporary-works packaging was another use they began adding.
Each addition reused common definitions where possible. Locations, activities, plant, equipment and people had shared lists that functions could reference in their own work. Defining them once meant the next use could draw on the existing information instead of introducing another set of names.
Give teams ownership within shared standards
People need room to adapt how they work with information. Thibaud had seen teams return to Excel when they could not make a report their own. In Morta, contributors could create views and organise their information, while the project developed a community of trained builders who could do more for their own teams.
Procurement staff could build for procurement, and the carbon team for its own needs. The central digital team supported the overall setup and common standards. Local views gave teams control of their work, while shared concepts let them reuse each other's information rather than create separate versions.
Before and after
| Criterion | Earlier handling in the contributors' experience | Lower Thames Crossing approach |
|---|---|---|
| Deliverable creation | CDE creation separate from an Excel TIDP that could serve mainly as a contractual submission | Plan deliverables in Morta, allocate codes and create them in the CDE selected by the contributor's profile |
| Programme information | Repeated extracts, copied values and date questions to planners | Shared programme information that planners could filter and enrich for milestone, consent, tendering and site-date uses |
| Consent progress | A register with progress tracked separately | Planned information compared with actual CDE dates and statuses |
| Common definitions | Different departments could mean different things by the same name | Shared component definitions and reference lists reused across functions |
About the project team
Bouygues TP Murphy JV worked on Lower Thames Crossing's Tunnels and Approaches package. Arup Mott MacDonald JV provided design services, alongside Bouygues' technical department for tunnel design. The work brought the contractor and designer joint ventures together on this package.
What comes next
Direct P6 API connections, better interaction with data and a wider community of project builders remained areas to develop. The teams shared their custom work with the Morta community to discuss what should become part of the product.
