Ask a construction team for an update on a project and there’s rarely a complete lack of information.
There’s usually plenty of it.
Progress has been updated in a spreadsheet. Someone has a list of outstanding constraints. The latest programme has been exported as a PDF.
Actions were agreed in yesterday’s meeting. A subcontractor confirmed something over WhatsApp. Another team has its own weekly plan. Somewhere else, somebody is updating the master programme in Primavera P6.
The problem isn’t always getting more information.
It’s working out how all the information you already have fits together.
On a busy project, that becomes a job in itself.
Think about how much information gets created during a normal week on site.
Teams discuss what they completed.
They agree what they’re going to do next.
They raise issues preventing work from starting.
They chase drawings, materials and approvals.
They review upcoming activities.
They make commitments.
They update progress.
None of this is unusual. On a well-run project, it’s already happening every day.
But the information doesn’t necessarily end up in the same place.
One part might be captured during a coordination meeting. Another sits in a spreadsheet.
Someone keeps a separate constraint register. Progress gets reported through another process. The programme lives in P6 and gets distributed as PDFs. A subcontractor confirms an important update in a message.
Each piece makes sense on its own.
The difficulty appears when someone needs to understand the project as a whole.
Now those pieces have to be brought back together.
Suppose the planning team wants to understand why an activity due to start next week is at risk.
The programme gives them the activity and planned date.
But the reason it might not start could be somewhere else.
Maybe an RFI is sitting in a separate register.
Maybe access was discussed during yesterday’s meeting.
Maybe the subcontractor has already said it won’t be ready.
Maybe the latest progress update shows the preceding work is behind.
All of that information may exist.
Someone just has to connect it.
And on many projects, that connection happens manually.
People compare spreadsheets against the programme. They copy information between systems. They update trackers after meetings. They chase different teams for the latest position. They take something discussed on site and translate it into something the planner can use.
Then the process starts again the following week.
This is where a surprising amount of project information gets lost, delayed or stripped of context.
The project isn’t short of data. The data is short of connections.
It’s easy to look at this and conclude that projects need to stop using spreadsheets, PDFs, WhatsApp or whatever other tools people rely on.
That misses the point.
Teams use these tools because they’re useful.
A spreadsheet can be quick and flexible. A PDF is easy to distribute.
WhatsApp gives somebody on site a fast way to communicate. Meetings are still one of the most practical ways to coordinate work between multiple contractors.
The issue appears when important execution information stays inside those individual places.
A subcontractor saying, “We won’t be ready on Tuesday,” is useful information.
But if that commitment never gets connected to the activity scheduled for Tuesday, the wider project may not understand its significance.
An unresolved constraint in a spreadsheet is useful information.
But if nobody can immediately see which P6 activity it threatens, somebody has to work that out later.
The information itself isn’t the problem.
The separation is.
There’s another side to fragmented project information that’s easy to overlook.
Information takes time to travel.
Something changes on site in the morning.
It gets discussed later that day.
Perhaps it goes into a meeting the following morning.
Someone then updates a spreadsheet.
The planner receives the update and incorporates it into the programme.
Eventually, the wider team sees the new position.
Nothing in that process is necessarily being done badly.
But every manual step creates a gap between what the site knows and what the programme knows.
That matters because project conditions keep changing while the information is travelling.
By the time everything has been collected, checked and reconciled, the team may already be dealing with something new.
This is why simply asking people to report more often doesn’t always solve the problem.
If every additional update creates more manual reconciliation for somebody else, you’ve increased the amount of information without necessarily making the project easier to understand.
There’s also a lot of duplication hidden inside normal project reporting.
A contractor gives an update during a meeting.
Someone writes it down.
The same information gets added to a tracker.
Later, it’s sent to the planning team.
The planner interprets it and updates the programme.
Then a report is produced so the wider team can see the result.
One piece of information may have passed through several people before it reaches the place where its programme impact becomes visible.
That creates administrative work for people who would rather be managing the project.
It also creates opportunities for interpretation.
These sound like small questions.
Across hundreds or thousands of activities, they add up.
There’s a reason the information originates on site.
The people delivering the work are usually closest to the conditions affecting it.
They know what was completed today.
They know what they believe can be achieved next week.
They know when something is getting in the way.
They know whether an activity that looks fine on the programme is actually ready to start.
The challenge is getting that information into the planning process without turning everyone on site into an administrator.
If every update requires somebody to open another system, fill out another form and repeat information they’ve already provided elsewhere, adoption becomes difficult.
People find workarounds.
The spreadsheet comes back.
The WhatsApp group keeps moving.
And someone ends up reconciling everything manually again.
The better approach is to make it easier for the people doing the work to contribute the information they already have.
This is where construction technology sometimes gets adoption wrong.
A new system arrives with a new workflow.
The project team has to learn a different process. Contractors have to report differently.
Information has to be entered in a new format. Existing routines get replaced because the technology expects the project to adapt around it.
That can work.
But it creates another challenge before the project has received any value: getting everyone to change how they work.
Most well-run projects are already doing the important things.
They already have a master programme.
They already plan upcoming work.
They already discuss constraints.
They already make weekly commitments.
They already report progress.
The opportunity isn’t to invent a completely new planning process.
It’s to connect those behaviours.
The master programme gives all of this information context.
A progress update becomes more useful when it’s connected directly to the activity being delivered.
A constraint becomes more useful when the team can see which upcoming activity it threatens.
A weekly commitment becomes more useful when it relates back to the programme the project is actually trying to deliver.
Now the team doesn’t have to keep rebuilding those relationships.
The programme says what should happen.
The people delivering the work provide information about what is actually happening around it.
When those two sides stay connected, the project gets a much clearer view of execution.
And importantly, P6 doesn’t have to disappear.
Neither do the planning conversations that are already working.
The goal is to reduce the amount of manual effort required to move information between them.
Think about how a planning meeting changes when the information is already connected.
Instead of spending the first part of the meeting establishing what happened, the team can spend more time deciding what to do next.
Those are useful project conversations.
Finding the latest spreadsheet isn’t.
Neither is comparing several versions of the same information to work out which one is correct.
Every hour spent reconciling information is an hour that could have been spent acting on it.
That’s the bigger opportunity in connecting site execution with the programme.
It isn’t about collecting more data for the sake of having more data.
It’s about making the information the project already creates easier to use.
Construction teams already produce an enormous amount of useful information every day.
The question is what happens to it.
If progress sits in one place, constraints in another, commitments somewhere else and the programme separately in P6, the project has to keep bringing those pieces together manually.
That takes time.
And the longer information stays disconnected, the harder it becomes to understand what’s actually happening against the programme.
So before asking site teams for more updates, another report or another tracker, there’s a simpler question worth asking:
Are we actually using the information they already give us?
Because the project may already have most of the data it needs.
It just needs to stop making people search for it.
Uconia connects Primavera P6 with the day-to-day information being created by the people delivering the project.
Progress, constraints, lookahead planning and weekly commitments can be connected directly to the master programme, giving teams a shared view of execution without asking them to replace the planning processes they already use.
Instead of manually pulling information together from separate trackers and updates before the programme can make sense of it, teams can connect that information to the work it relates to from the start.
The programme stays in P6.
The project team keeps doing the work it already needs to do.
The difference is that the information finally starts working together.
