Jamile Tuma, Associate Director – BIM at Mace Consult.
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
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.
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.
| Figure | Meaning |
|---|---|
| 115 required deliverable types | The required list used in the planning and submission examples. A type could have more than one file. |
| 97% submission presence | The displayed CDE check, with four required types still missing. It checked for files before technical acceptance. |
| Nine core metadata fields | The common columns used to connect different CDE field names to the review template. |
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.

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.

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.

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.
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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.
| Task | Earlier approach | Approach used in May 2024 |
|---|---|---|
| Find a deliverable | Navigate each project's CDE and locate the required revision. | Follow an assigned review list and a direct revision link. |
| Check incoming submissions | Export a CDE report and repeat the spreadsheet check for new uploads. | Refresh the connected submission view against required deliverable types. |
| Prepare a varying MIDP | Interpret the contractor's spreadsheet. | Retain human interpretation, then load the data into a common structure. |
| Coordinate outstanding reviews | Work with inconsistent progress information. | Use the lead-adviser overview to identify files and disciplines needing follow-up. |
| Review the file formally | Use the project CDE. | Continue in the CDE, with a separate discipline vote in Morta for coordination. |
| Exchange fallback comments | Use an alternative where the CDE could not support commenting. | Collect comments in Morta and exchange a CSV when the contractor did not participate there. |
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.
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.
Get started