Sir Robert McAlpine

Mo Shana’a: Awesome. We’re now moving on to our last talk for the day. Last, but certainly not least, you’ll see they’re also doing some incredible work. We’ll have Mark and Josh from SRM, and they’re going to be sharing their perspective with us.

Thank you so much for joining us, Mark and Josh.

Mark Harrison: Thanks, Mo. Cheers mate. Thank you.

Mo Shana’a: Awesome. You should have your screen now and we’re all good to go.

Mark Harrison: Okay, cool. So yeah, thanks for inviting us to present today, Mo. So for those of you who don’t know who SRM are, we’re a tier one contractor working in the UK, delivering all sorts of projects across multiple sectors, and we’re a family owned business and have been operating for over 150 years now.

So I’m Mark Harrison. I’m joined by my colleague today, Josh. We’re part of the SRM Digital Construction team. I work as a national resource, with Josh leading a team on a large project down in Somerset.

I’m going to run through our Morta journey so far, touching on lessons learned, our approach to scaling initiatives, rolling them out across the business. And then Josh is going to take you through some live platform demonstrations at the end of the presentation.

So we started with Morta in October 2023, so around two years ago, with just five licenses. And we didn’t start out on the journey with any sort of particular intention, but we were aware that it had some quite unique functionality that we wanted to explore.

We set up a focus group to start looking at options and trials for resource developments, some of which were successful and others not so much. After the first year, we had a clear understanding of which functions Morta was most effective for, and we started to launch resources onto live projects.

This included handover information management, sustainability risk and opportunity tracking, and information delivery planning tools.

At the start of this year, we launched a second working group with a focus on creating, learning and supporting resources, and by the summer had started to roll out information delivery planning on all new projects. This included a complete package of supporting resources.

In September, we joined the Morta scale up plan and bought 50 licenses, which takes us to today where we have 78 hubs and 116 active users, a number which is increasing daily.

During the first 12 months of development, we tried multiple work streams and attempted to Morta-ise all sorts of existing documents and databases. And through that journey we learned some key lessons which we wanted to share with you guys today.

So number one, Morta isn’t designed to replace Microsoft Word for documents that are primarily text-based. It’s best to use your usual processes. Morta’s strength is in the use of databases, so focus on making the most of that functionality.

Secondly, spend time understanding hub and resource permissions and how you’ll control access. Consider how permissions through tags interact with permissions through roles.

Thirdly, think about how the platform will grow over time to support multiple functions within your programme. Explore overall structure and tables that will apply to more than a single workflow or function. Try to consider all data that you may want to collect against an entry for use within future resources.

And finally, consideration should be given to hubs and their use. Do you have project hubs with multiple work streams or dedicated work stream hubs that contain multiple projects?

Considering the first lesson learned there about planning for expansion, we made some following key decisions along our journey.

So the first one was we developed our hub structure to align with our company management system and documents naming and filing structure. This ensured that the structure and layout was immediately familiar to project teams when they log onto the platform.

We created an admin section for resources that are shared across multiple functions. For example, initially we had multiple data validation tables for each work stream. We then moved to a single categorised data validation table held within our admin section that enabled us to drive consistency and reduced repeating information across multiple tables.

We also realised a project directory table is fundamental to feed into multiple other resources such as responsibilities, definitions, permission settings, and organisational task alignment.

So how did we scale work streams from inception to business as usual? We developed a three stage work stream development process that we follow for any work stream that we want to Morta-ise.

So all work streams start with an idea, usually driven by a need to solve a problem on a project. This idea is then presented at a Gate One review where appropriate stakeholders are invited to determine if Morta is the best solution for the problem. They may be rejected at this stage with an alternative solution being adopted.

We then move into building the resources in the development environment, followed by Gate Two review, where stakeholders comment on whether the objectives have been met. This is typically an iterative process.

Stage two development is a project specific build and is the stage at which we identify a sponsor at company level. Following the project trial, we present to the sponsor and they determine whether the work stream is suitable for company wide rollout. In some cases, it may not be, and will remain specific to a single project.

If it is successful, then we move to stage three, where we develop the resource in Morta and all the supporting information and processes. This then moves to a final sponsor review, followed by a company-wide launch and business as usual.

So how many resources do we have at each stage of development? So we currently have 12 resource types at stage one development with five at stage two, and three at stage three.

What we’ve found is that developing the resource through the early stages of development one and two is relatively straightforward, but then when we move into stage three development, it can be quite resource heavy.

This is for a number of reasons. One is you have to consider all project options. So all projects have unique requirements and trying to build a template that is flexible enough to suit all projects is quite challenging.

We have built in options into each resource to accommodate project requirements such as flexible naming standards and solutions for connecting to multiple CDEs. These options can then be utilised on hub mobilisation to configure the project specific build.

The other thing we found with stage three development is it’s quite time consuming to develop all of the additional resources that are required to roll out resources business as usual, such as process documents, how-to guides and training videos.

So an example of a successful resource that’s gone through the full development workflow is our information delivery planning resource. We used to manage TIDPs and MIDPs through multiple Excel files of all different shapes and sizes. And now we’ve moved to a Morta-ised workflow, including a package of resources that we roll out when we push this onto projects.

So things like in-hub quality and tracking resources. We have Power BI dashboarding. Connection to multiple CDEs. Training material. We have formal SRM procedures that reside in our CMS, and we have project sponsors and project super users.

One of the most important parts of this package is the information delivery planning procedure, which is co-authored and owned by the sponsor. This procedure describes how processes have been developed to align with the principles of ISO 19650 Part Two, workflows for both process mobilisation and operation, and finally responsibilities both at group level and project level for each task that’s required to ensure the projects are successful.

To support the scaling of Morta, we established governance to distinguish the differing required communication routes.

So key relationships within this governance are group sponsor and technology owner at the top level that supports our stage two and stage three development gateways with decision making.

Group admin and Morta. So we have weekly catchups with Ali from Morta who provides us with technical support. We discuss problems with resource development and we talk through new features and training.

And finally, the project admin, project discipline lead and project user relationships. So regardless of the amount of support that we provide at group level through the group administrators, on-project support is critical to a successful implementation.

Josh: So, yeah, just give you a flavour and a whistle-stop tour of how we’re currently utilising the platform. There’s many other ways, not just these particular examples I’m going to show you.

So we invite everyone from SRM project teams all the way through to our external stakeholders, subcontractors, et cetera. And in this particular example, the information delivery planning, I’m going to give you a quick understanding of how we do it.

So when we first introduce the system to a subcontractor, we talk them through the purposes behind the TIDP. What’s it for? Because not always everyone knows what it is. And then once we get to the understanding of the purpose behind it, we add them to the platform, show them the ins and outs of what Morta is, the purpose behind it, and then we need them to complete certain fields to allow the TIDP process to work.

So the first fields that we get them to populate is information package delivery dates. So this is where the subcontractor will define a whole list of their drawings and deliverables for the duration of the job. They would then group those particular drawings into individual packs of information.

And then they would assign a plan date for the first issue and a plan date for construction issue. So it gives us a baseline to track against plan versus actual once that hits 4Projects.

Once they’ve done that, that forms part of the master information delivery plan. And then we can see everybody’s TIDPs within the MIDP, and then we can drill down into this information and see when certain drawings, et cetera, will plan to be issued on the project.

Off the back of this, we then pull all this data into Power BI so we can then see the plan, the actual, for the whole project.

So in terms of the way that looks in Power BI, we have a high level dashboard to give us a flavour of actual versus planned first issue deliverables on the project. And then we’re also extracting some of the 4Projects data that’s embedded within Morta and what status and organisation that belongs to. And then the design manager and the team utilise this to drive the project, to help influence decision making on the job.

The nice thing is that we can then drill a bit further down into these details. And from there we can also drill down into each of the originators. And then off the back of that, also you can use the metadata stored within the file name itself. So you can filter then on individual buildings, functional breakdowns and so forth.

So that was a whistle-stop tour in terms of TIDP, MIDP and reporting.

I’m going to quickly cover the model QA checking now. So in terms of the model QA checking process, what we’ve built in here. The first table just summarises all the current models that are particularly available on the job.

So this is a list of all the models on the job, and it also lets us know what revision that model is and when we last received that model on 4Projects.

So this date here just allows us to understand when we last received it and reasoning why we haven’t received it. So we, for example, every two weeks we expect a new model upload. And if it hasn’t been received, we contact that key person from that particular company and then understand the reasoning why they haven’t uploaded it.

And then off the back of there, we also use this. So when the document control team data checks it, they push it through a certain workflow, which then hits the digital construction team. We can then see the list of models that sit with us for data review and data check.

So within Morta itself, we’ve set up a number of data checks or file checks that we have to run through. The top ones here are just the standard company wide within SRM that we’re now set up to follow. Each project may vary. So we do increase this where required.

But there’s some general rules here, like correct file formats loaded, model integrity in there, errors and corruption. And if that model does particularly fail, you can click fail and then you can jump back into 4Projects, give the reasoning, and then this will then disappear from this filtered view.

Then it would jump down into this view once 4Projects syncs with Morta, and then it would give you a list of models that are currently rejected. And then the team as a whole, all subcontractors and design team all have access to this, so they can go on here and understand why their model is rejected if they need to know further information.

And then just to support as well, we also created a simple view here of all current withdrawn models on the project.

So that’s generally our model QA process.

And the next one we’re going to take a look at is the sustainability risk and opportunity tracker.

So within work streams and initiatives, we’ve developed now a library of opportunities, some sort of ideas and general business stream ideas, that are all listed in here. And certain principles and groups they’re relative to.

And then what happens in here, the external company that has access like a subcontractor or design consultant, they can come in here, they can define the package that they’re delivering on the job. They can define whether this is a risk or an opportunity for sustainability.

In this case going to click opportunity. They can go through here and say environmental waste opportunity, and then they can select the phase of the project that opportunity is relative to. And then they would give some free text in here around the opportunity they think will be beneficial to the project.

So once they’ve populated all that, they’re then going to submit the form. That then comes to SRM internal for review. And then we would have a review table within here, which we then can open, review all the different opportunities and risks that people have raised on the project. And then we can either accept and reject it or have general discussions over meetings.

So that’s generally the risk and opportunities hub.

And then the next one was monthly reporting. So in terms of monthly reporting on the job, we got to a point where we were doing monthly reports with Word documents and it was quite difficult to, say, have a central place. We found it was a little bit inefficient, so we tried to look at Morta to develop this.

As a central place for the individual discipline leads on projects to go in here and update their sections. So for example, the planning function, they’ve created a document within the planning function and they can click on the monthly report.

They would then have here a monthly report text section, which then they would populate for the particular month that they’re reporting on. They would add all the headings that are required to see, and this all feeds to Power BI.

So once they’ve done all that, that’s all populated, that’s fine. And then that’s automated and pulled through to Power BI.

So in terms of the way that this looks within Power BI, we’ve got a number of subsections that basically reflect what we have in Morta. So a cover page, executive summary, commercial, planning, et cetera.

And then the nice thing about it, because we’re storing all the data within Morta, we can then look at previous months that we’ve submitted into there. So if the client wishes to look at previous dates back three months, four months ago, they can then click on the relative month they wish to review.

And the overall goal is to get an Asta to Power BI API connection to Morta. And then we’re going to build some formulas and scripts within Morta to then clean up the data, tidy it up, and then we’re going to bring that into Power BI to then feed those reports.

So that’s generally my section complete.

Mark Harrison: So, yeah, next steps with Morta.

The first one is cross organisational collaboration. So we’re now working with multiple trade contractors and consultants who are also using Morta for TIDPs. So what we want to try and do is automate the pull of their TIDP information into our MIDP.

We’re also working with clients that are using Morta. And we’ve recently been asked to go into a client enterprise and work within their hubs to build solutions for our projects that we’re working on together as well.

Secondly, we’re going to be looking at the use of public hubs where we send out a link to a public hub for a contractor to populate a form, which then populates a table in the public hub, and then we swap that through to private hubs.

We’re going to continue to identify opportunities to support further SRM disciplines. So whether that be planning or commercial or design management or sustainability, we’re going to continue to work with those discipline leads within the business to Morta-ise new solutions.

And finally, we’re going to look at API connections to some of our existing platforms, so that could be progress tracking, quality control and digital handover.

Mo Shana’a: Amazing. First, thank you so much for sharing that. I think again, this has been a great example of sharing reflections and lessons learned. I think I especially really liked the points you made towards the beginning around the use cases and finding the right use cases.

Because I think, yeah, I know initially you were looking at things like BIM execution plans and so on and so forth, but you ended up seeing that the real value is in the tracking, and I really appreciate you sharing these types of lessons with the rest of the community.

I also like, generally speaking, how you think about scaling and the processes that you’re putting in place for that. Definitely can appreciate the challenges when it comes to template creation.

So I’ve just, yeah, really, really appreciate you sharing these reflections with the rest of the community. Thank you both so much.

Mark Harrison: Awesome. Thank you. Thanks.

Mo Shana’a: Thank you both. Have a really good one.