A project manager checks the programme and sees that flooring is arriving on Thursday. Procurement has an email saying Monday. The site supervisor has booked the installation team against the original date.
Each person has a record. The difficulty is knowing which one reflects the current position and who needs to act on the difference.
For a commercial fit-out business, improving project management can start with those handovers between systems. Before adding software, establish where important information belongs, who maintains it and what should happen when it changes.
Start with one journey through the project
Choose a recurring piece of work, such as confirming a delivery. Follow it from the supplier’s message through procurement to the site team and the project report.
Ask where people retype information, where they make assumptions and where an update waits for someone to notice it. Look at a real recent example together. A process described from memory can miss the informal steps that make it work.
For the flooring delivery, the missing step might be simple: the buyer records the revised date, but nobody is responsible for checking the installation booking. A new dashboard would still depend on that responsibility being agreed.
The UK BIM Framework’s September 2020 guidance on common data environments makes a useful distinction between the workflow and the technology supporting it. It recognises that several technologies may be involved. That is a helpful starting point for teams whose project records already sit in different places.
Give each important record a clear home
Decide which system holds the record the team should rely on for each purpose. The accounting package might hold purchase orders, the document system the issued drawings, and the programme the agreed sequence of work.
Write down who can update each record and how other people will find it. The aim is to make ownership explicit enough that a colleague can follow the trail without asking the person who created it.
A short working map could look like this:
Purchase order: maintained by procurement; referenced by the order number.
Supplier delivery commitment: recorded by the buyer, with the dated confirmation attached or linked.
Installation activity: maintained by the project manager in the programme.
Site booking: confirmed by the site team after checking access and readiness.
These records describe different things. An order being placed does not confirm when goods will arrive, and a delivery date does not confirm that the site can receive them.
Use references that survive the handover
A shared project code is a start. Add a consistent package, order or item reference wherever the records need to connect.
For example, “Level 2 flooring” may refer to several products and deliveries. The purchase order number and a delivery reference give the buyer and site supervisor a more precise way to identify the same event.
Link back to the original record where practical. Repeated copies of spreadsheets and attachments make it harder to tell whether an update has reached everyone. Where an export is necessary, show when it was produced and who owns the current version.
Be realistic about access. A subcontractor may not use your internal system, so agree how their confirmation enters the project record and how they receive subsequent changes.
Agree what happens when information changes
A connection between systems needs a practical rule. What should trigger an update? Who checks it? Who needs to know?
In the flooring example, a changed supplier date could prompt the buyer to record the new commitment and ask the project manager to review the affected activity. The site team then confirms whether the revised booking works.
If the programme and supplier record disagree, show the conflict to the owner. Do not silently replace one with the other. One may be an agreed target and the other a supplier’s latest forecast; that difference matters.
The same principle applies to automation. Decide which updates can be copied, which require review, and how failed transfers become visible. An unnoticed connection failure can leave a report looking current when it is not.
Check the tools you already have
Look for existing notifications, linked records, approval steps and exports before commissioning anything new. Availability will depend on the product, subscription and configuration.
A useful test for any proposed change is whether it removes a specific repeated task. If the team must maintain another status list alongside all the old ones, ask what work it actually saves.
An AI colleague could help where updates arrive in varied emails or documents. With suitable access, it could extract a proposed delivery change, identify the matching order and prepare a discrepancy for the buyer to review. It would need to show its source and flag uncertain matches.
That gives the agent a defined place in the team: helping people connect records while the responsible colleagues retain control of the programme and commitments.
Test the handover before widening the scope
Try the revised process on one package. Measure how long it takes for a supplier update to reach the people affected, how often the records disagree, and how much checking the team still does.
A useful result might be a clearer responsibility, a better use of existing software or a small AI pilot. The evidence should determine the next step.
If one project update is being entered or checked in several places, talk to Build Agents about that workflow. We can explore how a focused paid pilot could support the handover alongside your current systems.
