Consultant

Jamile Tuma, Associate Director – BIM at Mace Consult.

Mace

Mace Consult created a consistent review route across contractors' different common data environments. Discipline assignments linked reviewers to current files, while an overview of their votes helped the lead technical adviser direct follow-up.

Mace · May 2024

Why MortaGive client-side reviewers a consistent route into different CDEs
Review teamDiscipline reviewers and the lead technical adviser
Common structureNine core metadata fields
StageTrial at the May 2024 presentation
Nine core fieldsthe common metadata structure behind the review template.
97% submission presencethe displayed check for a file against each required deliverable type, before technical acceptance.

Mace Consult's client-side reviewers had to find and assess deliverables across different contractors' common data environments, or CDEs. Jamile Tuma and her colleagues built a review interface in Morta that connected each discipline's assigned work to the right file and revision.

Executive summary

Mace Consult's technical advisers needed to coordinate reviews across the CDEs chosen for their projects. The team mapped incoming metadata into common fields and used a review matrix to give each discipline its own target list. Reviewers followed links to the files in the CDE, completed their review there and recorded a discipline vote in Morta. An overview of those votes helped the lead technical adviser direct follow-up. In one submission example, the check displayed 97% presence across 115 required deliverable types, before technical acceptance. Jamile identified time saved on compliance checks, document searches and finding review bottlenecks. The approach was still being trialled in May 2024, with technical setup, manual MIDP preparation and a fallback CSV exchange for comments remaining part of the work.

In the May 2024 examples

FigureMeaning
115 required deliverable typesThe required list used in the planning and submission examples. A type could have more than one file.
97% submission presenceThe displayed CDE check, with four required types still missing. It checked for files before technical acceptance.
Nine core metadata fieldsThe common columns used to connect different CDE field names to the review template.

The results

Jamile identified three practical savings. Information managers could check new uploads without repeating a CDE export and spreadsheet exercise, then advise when the review could start. Reviewers could work through their assigned list using links to the current files. The lead technical adviser could locate outstanding work by discipline and deliverable, focusing follow-up on the people involved.

A file's presence does not establish its technical acceptability. The submission view checked whether each required deliverable type had at least one associated file in the CDE. In the example, it displayed 97%, with four types still missing. A manual sync or automatic refresh updated the check as files arrived, giving the information manager a view of remaining omissions. Technical review was a separate step.

Submission table with required deliverable references, associated CDE filenames, 115 rows and a highlighted 97% filled value
The example displayed 97% submission presence, with four required deliverable types still missing. Technical acceptance followed a separate review.

The lead technical adviser's overview brought the disciplines' decisions together. It separated work still to be reviewed from items awaiting a response, rejected items and accepted items. Filtering by file and discipline helped the lead adviser identify who needed to respond. They could then contact the relevant reviewers or arrange a workshop to resolve a problem before resubmission.

Review overview with discipline labels grouped under to be reviewed, awaiting responses, rejected and accepted columns
The lead technical adviser could see the disciplines involved in outstanding reviews and rejected deliverables.

The challenge

Reviewing and accepting information on a client's behalf was central to Mace Consult's technical-adviser role. On frameworks with one CDE, reviewers could become familiar with its workflow. Elsewhere, the main contractor's system became the project CDE. Different products and configurations changed how reviewers found information, often against tight deadlines.

Five contractor groups submitting information through different CDEs towards a client review team, with symbols for searching, delay and uncertainty
Different contractor CDEs gave the client team different routes to the information it needed to review.

Progress tracking and compliance checks added further work. An information manager would extract a CDE report, run it through an Excel checking tool and send the findings back. Another batch of uploads meant repeating that preparation. Where a CDE could not support the commenting process, the team also needed another way to capture and manage review comments.

The solution

Keep the files and formal review in the CDE

A discipline vote communicates a reviewer's position to the lead technical adviser. Formal acceptance or rejection remains a separate CDE action. In Mace Consult's workflow, Morta identified the relevant deliverable and linked directly to its file revision in the CDE. Reviewers could open that file, leave their comments and complete the formal review there, then record their discipline's position in Morta.

The same five contractor CDEs connected through Morta to a client review team
Morta gave the client team a consistent guide to information held in different contractor systems.

Agree the metadata the review needs

The team defined nine core fields: deliverable reference, filename, description, revision, latest-revision flag, status, organisation, last modified and URL. The latest-revision flag removed older versions from the current review list, while status identified the information issued for review. Reviewers then used the URL to reach the file. Four optional fields, created by, format, folder and stage, supported the project's arrangements where that data was available. Folder or stage filters could narrow the information presented for a particular review.

Core metadata list with nine fields beside four optional fields: created by, format, folder and stage
The core fields kept the template's structure consistent, with optional fields supporting particular project arrangements.

Common columns let review-table lookups keep the same structure even when incoming labels differ. In Jamile's filename example, Viewpoint, Autodesk Construction Cloud and Procore used Name, Aconex used Document Number, and Asite used Document Ref. Python logic checked the applicable labels and supplied the common filename column. The team could therefore reuse the lookups against that column when setting up another CDE connection, rather than rebuilding the review tables around each product's labels.

Filename mapping from Viewpoint, Autodesk Construction Cloud and Procore Name, Aconex Document Number and Asite Document Ref
The mapping reconciled different names for the filename field before the data reached the review template.

Give each discipline its own review list

The review matrix assigned deliverable types to the disciplines responsible for assessing them. Mace Consult had begun that exercise before using Morta. Services coordination strategy drawings, for example, needed mechanical, electrical, architecture, public health and information management input. Those assignments determined each discipline's target list, giving its reviewers a defined set of deliverables to work through.

Services Coordination Strategy Drawings at the centre of a matrix linked to mechanical, electrical, architecture, public health and information management reviewers
The review matrix connected a required deliverable type to the disciplines responsible for assessing it.

The current-revisions view paired those assigned files with a discipline vote and a direct CDE link. A reviewer could open the specific revision, leave comments in the CDE and return to Morta to record the discipline's decision. That connected each response to the version actually assessed.

A replacement revision needs a fresh review. In Jamile's example, P02 had been rejected. When P03 arrived, its vote cell was empty because that revision had not yet been assessed. The blank cell made the outstanding task visible to the reviewer.

Architect current-revision table showing revision numbers, coloured votes, organisations, modification dates and CDE links
The current-revisions view combined the discipline's review decisions with links to the corresponding CDE files.

The history view kept earlier revisions and their votes available separately. A reviewer could check the previous decision and follow the old revision's link to revisit its comments in the CDE. That preserved the earlier review context while the replacement remained a new task.

History table grouping deliverable references and names with multiple filenames and descriptions
The history view retained the earlier file revisions for reference alongside the current review process.

Check the plan before checking the submission

Before uploads began, the team compared the master information delivery plan, or MIDP, with the required deliverable list. In the planning example, the MIDP covered 70% of 115 required types. The missing types gave the information manager specific omissions to raise with the contractor, including what would be delivered and when. Those discussions could take place before submission. This was planned coverage, separate from the 97% file-presence check.

Planned-submission table with deliverable references, deliverable names, MIDP filenames, 115 rows and 70% filled
The MIDP check compared the planned information with the required deliverable types before submission.

Validation rules checked the plan's metadata against the project's information standard. Warnings highlighted a project-code typo, an unrecognised organisation code and an incorrect form code. The information manager could isolate rows with issues and investigate those discrepancies without scanning the complete plan. A separate filename check identified whether planned files were present in the CDE.

MIDP validation table with warnings against code fields and true or false values for filenames found in the CDE
Validation highlighted metadata issues, while the final column checked whether the planned filenames were present in the CDE.

Keep a fallback for comments

Where the CDE could not support commenting, the team collected Morta comments in a table. Each comment retained its author, discipline and date, with resolved and unresolved items separated against the file. Reviewers could see which comments still needed attention. The contractor in this example did not join the Morta commenting workflow, so the team exported a CSV and handled the replies manually.

Comment table with filenames, resolved comments, unresolved comments and comment links
Tabular comments provided a fallback where the CDE was unsuitable. Exchanging those comments with the contractor still involved a CSV.

Count the review rounds

The recorded decisions let the team count review cycles by outcome, including rejection, clarification and acceptance. Those counts provided a way to examine repeated reviews of a deliverable. The team was exploring how to extend that analysis to the time and people involved in the review effort.

Review-cycle table grouped by review result and cycle number, with filename counts and filled values
Review-cycle counts let the team examine repeated reviews. Analysis of the time and people involved was still being explored.

The implementation

The reusable template depended on common fields and lookup tables, but its first CDE connection required testing and troubleshooting. Missing data and inconsistent field names needed attention before the team could reuse the connection on another project. Jamile acknowledged the technical knowledge and upskilling involved, alongside Adam Green's support with Python. Easier access for reviewers depended on that setup work.

MIDP preparation still required a person. A consistent MIDP format was not enforced, and contractors' Excel files varied in layout and fields. The team identified the required data, including deliverable reference, filename and description, and loaded it into the common structure. That preparation allowed the checking tables to work with differing incoming plans.

Contractors could continue using their CDE, which limited the changes needed for these reviews. The Autodesk Construction Cloud setup required a plugin, and the comment fallback retained the manual CSV exchange. Internally, Mace Consult had previously used a simpler structure in another database. As the team moved the workflow into Morta, lead technical advisers and architects began suggesting further uses for the collected information.

Before and during the trial

TaskEarlier approachApproach used in May 2024
Find a deliverableNavigate each project's CDE and locate the required revision.Follow an assigned review list and a direct revision link.
Check incoming submissionsExport a CDE report and repeat the spreadsheet check for new uploads.Refresh the connected submission view against required deliverable types.
Prepare a varying MIDPInterpret the contractor's spreadsheet.Retain human interpretation, then load the data into a common structure.
Coordinate outstanding reviewsWork with inconsistent progress information.Use the lead-adviser overview to identify files and disciplines needing follow-up.
Review the file formallyUse the project CDE.Continue in the CDE, with a separate discipline vote in Morta for coordination.
Exchange fallback commentsUse an alternative where the CDE could not support commenting.Collect comments in Morta and exchange a CSV when the contractor did not participate there.

About Mace

In May 2024, Jamile worked in Mace Consult's consultancy team, mainly on public-sector projects. Its technical advisers assessed information on behalf of clients, including decisions to accept, reject or seek clarification on submitted deliverables.

What's next

The team wanted to develop project and master lessons-learned logs, making lessons available beyond individual projects. A proposed derogations schedule would help identify requirements repeatedly set aside by delivery teams. Those patterns could be raised with the client to consider whether a requirement needed review. The team also intended to bring model-review information into its wider assurance report.

Direct MIDP exchange between Morta hubs was another possibility. Jamile wanted to reduce the repeated cycle of receiving revised plans and preparing their data manually. Agreed fields, names and syntax would still be needed whichever exchange method was used. A standard MIDP format could also help the team show the client the core information needed and propose improvements to how MIDPs were prepared.

Maintaining the views created further work. New folders could require filters to be changed in several places, so Jamile wanted central control of those filters. She also wanted administration across hubs, better sync-failure diagnostics and user controls. Clearer navigation would help people with limited access find their permitted information, while more control of chart colours and graphics would support Mace's reporting. These were requests for developing and maintaining the approach.

Watch Jamile's deliverables review presentation.

Get started

Try Morta on a real project.