ALEC: database-driven information management

A Tier 1 Contractor's perspective on database driven information management with ALEC

ALEC had experienced project teams, but its information management templates were carried from one project to the next. Andy Boutle wanted centrally organised resources that other departments could use. In July 2022, his team was developing connected templates and had replaced a weekly manual model-tracker update with a BIM 360 metadata refresh.

Executive summary

ALEC used its preparation for the BIM Kitemark to rethink how it managed information. Andy Boutle and his team tested a supplier questionnaire in Morta, then developed a template hub for tender response, appointment and delivery. The hub provided stage-specific resources for project Digital Construction Managers to develop after award, while joined tables and naming codes let teams reuse shared information without retyping it. On one project with more than 500 model files, a weekly BIM 360 refresh replaced manual tracker checks and entry used for client reporting. The project information lead estimated five person-hours saved each week on that activity. Templates were being deployed and peer-reviewed, permissions took learning, and wider adoption required people's time. Aconex integration was in development, while links to planning and client-side systems remained ideas to investigate.

Evidence at a glance

• More than 500 model files were tracked on the ALEC project Andy discussed.
• The project information lead estimated five person-hours saved each week on that project's model-tracker checking and entry, according to Andy.

repeat information without entering it more than once.

Andy Boutle

The results

The clearest saving came from connecting a tracker to information already held in BIM 360. Each week, the project information lead checked whether the latest model versions and required formats had been uploaded, then keyed the results into Excel. That tracker fed a Power BI dashboard used to report progress to the client.

The team rebuilt the tracker in Morta and connected it to BIM 360 metadata. A weekly refresh updated the table automatically, replacing the lead's manual checking and keying step in the reporting workflow. The lead estimated a saving of five person-hours a week for that activity alone. Andy saw scope to repeat useful connections across projects and departments, with the wider return dependent on doing that work.

The template hub gave project teams a shared starting point as well. Instead of adapting the last project's documents, they could copy the relevant stage's resources and develop them for their own project. The templates were being deployed while the team continued to review them.

The challenge

Excel remains useful. Repeated handling becomes the problem when shared information is scattered across files and recreated in different places. Andy's examples included the same party, role or originator code being typed into three, four or five tables, often in separate documents.

His earlier experience at Kier illustrated the repair work. The team sent task information delivery plan templates to the supply chain, collected the returned files and combined them through Power Query into a read-only master plan. Formatting changes could break the workflow, leaving someone to repair it. Separate trackers added another task when someone had to open the delivery system, check its information and recreate the status elsewhere.

At ALEC, the BIM Kitemark work created an opportunity to organise the templates centrally. Andy also wanted to avoid a resource confined to the BIM department. The tendering and design teams would need to participate in developing and using the resources relevant to their work.

The solution

Organise resources around the delivery stages

ALEC began with a practical test. The team asked Morta to build a supplier-questionnaire workflow that could send an email invitation and collect a response. Seeing that use case work won the team's support for the broader template build.

The hub followed the delivery stages relevant to ALEC as a lead appointed party under ISO 19650. For an incoming tender, the team would create a hub, copy in the tender-response resources and develop the pre-appointment BIM execution plan, mobilisation plan and other inputs. Those resources formed part of its response to the client.

After award, the BIM execution plan would move into the appointment stage and the remaining resources would be copied across. The project Digital Construction Manager would then manage and develop them. That handover gave the manager the resources appropriate to the awarded project, rather than a collection to assemble from previous projects.

A menu-heading table controlled how resources were grouped in the hub. The hub builder could assign each resource to a heading, keeping the navigation aligned with ALEC's stages.

Make responsibilities visible

The tender-response process map connected incoming client information with the work needed for the response. It set out the nomination of information management roles, the pre-appointment BIM execution plan, capability and capacity assessments, mobilisation and information risks. The team could follow how those activities and their outputs contributed to the tender submission.

The information management function assignment matrix allocated responsibility for those activities. Project teams could select departments or roles as responsible, accountable, consulted or informed, then filter the matrix to a department's work.

Andy filtered a view for the commercial team. In that part of the process, its responsibility was to complete the appointment documentation, including the resources being produced. The filtered view made that duty visible without asking the team to work through every other department's activities.

Carry shared requirements into each appointment

A separate high-level responsibility matrix sat within the BIM execution plan. ALEC used it to organise the client's required BIM uses, with source references, descriptions, proposed software and responsible parties. These entries provided the shared starting values for appointment requirements. Andy questioned whether this arrangement fully matched the intended purpose of the matrix, but found it useful for the requirements ALEC received.

A table join makes values from related records available in another table. ALEC's exchange information requirements used a join to that BIM-use matrix. The team selected the uses applicable to an appointment, brought through their shared information and added package-specific detail in manual columns.

The appointed party could then receive the requirements relevant to its package instead of having to comb through the entire client set. ALEC did not need to retype the shared values, and changes upstream could flow into the linked requirements. The team still had to choose what applied and supply the appointment detail. Andy considered this a working concept with further development needed.

Build the identification from reusable codes

Andy created separate tables for the naming fields used to identify an information container, such as a model or drawing. These held controlled project, originator, functional and spatial breakdown, form and discipline values. He aligned the example with the UK national-annex codes that many of ALEC's clients referenced.

A readable choice and a coded identifier serve different purposes. The plan author could select a label combining a code with its description, such as M-Model. The formula used only the code when composing the identifier, so the author could recognise the intended value without manually assembling the whole name.

Separate tables could also serve more than one resource. An originator table could hold companies and contact details, while the delivery plan referred only to the originator code it needed. The team could maintain that richer information without recreating the code in every plan.

Andy entered a test row in a task information delivery plan, selected the values and obtained the composed identification. The plan also held a title and planned issue dates. The example ended with no warnings or duplicate flags, giving the author a check on the entry made.

The next aim was to compare planned deliverables with metadata from the common data environment. Delivery planners could then look for gaps between the plan and actual uploads, including information uploaded without an entry on the plan.

The implementation

Keep review and formal outputs in place

The first-pass templates were being peer-reviewed. People with the relevant permissions could leave comments against document sections, allowing the team to capture suggestions on the resources it was developing. Andy also wanted comments on subsections, which were not available in the same way at that point.

Formal submissions continued alongside that review. The team exported PDFs to Aconex for approval, and the mobilisation plan's version-control table recorded the revision and status of those static outputs. The team could keep track of what had been submitted while developing the working resource.

Plan mobilisation separately

ALEC kept the mobilisation plan separate from the BIM execution plan. It set out education for task-team specialists and other delivery-team members, key information exchanges, system training, configuration and testing. The plan gave the client a view of how the team intended to prepare for using the systems.

The training table paired each topic and system with a delivery role. The QA/QC Manager was assigned Aconex training, while the Digital Construction Manager was assigned BIM 360 Docs, Revizto and Morta training. Those responsible could see which training they needed to deliver before the team used the systems.

Andy wanted a mobilisation tracker to record onboarding, training and access to systems against the plan. Moving that tracker into Morta was a later step. The plan set out the preparation. The proposed tracker would record its progress.

Learn the structure and permissions

Permissions took time to understand. Once the team understood the table views and access model, Morta tags let it group people and apply permissions without repeatedly assigning individuals. Andy found ongoing administration more manageable after that learning, but the initial curve was steep.

A spreadsheet's layout does not define how its information should be grouped in a database. Andy found that importing a flattened CSV was a starting point. Where a merged cell had held several entries together visually, he needed a grouping in the database. Rebuilding the tracker meant deciding how those entries should be organised, rather than copying their appearance.

On the project Andy discussed, the client-side team had access and some training. He encouraged them to review and comment in Morta rather than work only from exported versions. That gave client reviewers a route into the working plan alongside the formal submission.

Give people time to use it

A positive demonstration does not supply the time needed to adopt a new workflow. Andy could create an instance, build part of a workflow and offer training, but people still had to spend time using it. Adoption was small and gradual.

A tendering colleague was still circulating Excel trackers and collecting responses by email. Andy wanted to bring that work into Morta and show colleagues how to update it there. The colleague was busy delivering tenders, and the change remained work in progress.

The design department had a matrix rebuilt in Morta, with its user still learning it before deployment. An interactive Morta view was also embedded in the intranet, letting people work with that information from the intranet page. These were distinct ways of extending use beyond the initial template work.

Before and after

About ALEC

ALEC was the main contractor developing these resources for its role as a lead appointed party. Its Digital Construction team worked with project and departmental colleagues. Andy Boutle presented the approach as Head of Digital Construction.

What's next

In July 2022, the BIM 360 connection was working and ALEC was working with Morta on an Aconex connection. Aconex held published information and its audit trail, while BIM 360 held working and shared information, particularly models. The two connections would therefore draw from different parts of the delivery workflow.

A possible P6 connection remained an idea to investigate for dates and dependencies in information delivery planning. Andy had not yet had that conversation. He also saw an opportunity to connect client-side information requirements with delivery-team systems where appropriate.

Within ALEC, Andy wanted the design department's matrix to inform the information delivery resources. He was considering its relationship with a rolled-up information delivery plan, and that work remained to be developed with the design team.

Try Morta on a real project

Start with a process where the same information is entered, collected or checked repeatedly.