Most delays don’t arrive on site as delays.
They start much smaller.
An RFI has been open for three weeks. A permit that was expected still hasn’t landed. A crane is needed by two packages because one has overrun. A subcontractor has been appointed, but nobody has a firm start date.
At first, none of these things necessarily means the project is late. The affected activities might still be sitting exactly where they should in the programme.
But something has changed.
There is now a condition that could stop the work from happening as planned.
Finding that condition early matters. But identifying it is only half the job. Unless the team can see which programme activity it threatens, when that activity needs to happen and how much time remains to resolve the issue, the constraint is missing the context that makes it useful.
It’s just another item on a list.
When we talk about delay, we tend to focus on the moment something actually moves.
An activity misses its planned start. Float gets consumed. A handover slips. Eventually, a milestone comes under pressure.
That’s when the problem becomes obvious in the programme.
But go backwards from that moment and there’s usually a longer story behind it.
Imagine an installation is due to start on Monday. Monday arrives and the team can’t begin because a required drawing hasn’t been approved.
From a programme perspective, Monday is when the activity becomes late.
The problem didn’t start on Monday.
The drawing may have been submitted weeks earlier. The RFI might have remained open throughout the lookahead period. People may have chased it in emails or discussed it during coordination meetings.
The risk existed long before the planned start was missed.
And three weeks earlier, the project had far more options than it does on Monday morning.
Most well-run projects already identify constraints.
There are registers for RFIs, design issues, access, permits, procurement and other outstanding actions. Teams review them in meetings and assign owners.
The difficulty begins when those constraints sit separately from the programme.
Imagine opening a constraint register and seeing 60 unresolved items.
Where should the team start?
An RFI that has been open for three weeks sounds serious. Another raised yesterday might appear less urgent.
Now imagine the three-week-old RFI relates to an activity that isn’t due to start for another six weeks, while yesterday’s RFI is preventing work scheduled to begin next Monday.
That changes the conversation completely.
The age of the constraint doesn’t tell you its urgency.
Its relationship to the programme does.
Take that RFI.
A normal constraint register might contain the RFI number, description, date raised, owner and current status.
All useful information.
But there’s another question that changes how the project understands it:
Which Primavera P6 activity depends on the answer?
Connect the RFI directly to that activity and suddenly the team can see the relationship between the issue and the work it could affect.
Here’s the constraint.
Here’s the activity.
Here’s when that activity is supposed to happen.
And here’s the time available to resolve the problem before the planned work is affected.
If the activity starts in four weeks, the team has one type of problem.
If it starts on Monday, it has another.
The RFI itself hasn’t changed.
Its programme context has.
This is why early constraint identification matters so much.
Find an unresolved issue several weeks before the affected activity and the team may be able to deal with it cleanly.
As the planned start gets closer, those options narrow.
Eventually, prevention becomes recovery.
Now the team may have to move resources, resequence other work, consume available float or accept an impact somewhere else in the programme.
The constraint may be exactly the same one the project knew about three weeks earlier.
What changed was the amount of time available to respond.
That’s why simply recording constraints isn’t enough. The team needs to understand their relationship to upcoming work while there’s still something useful it can do about them.
Busy projects generate plenty of noise.
Some issues appear in every meeting. Some generate long email chains. Others get escalated because the person raising them is persistent.
Meanwhile, a less visible issue might be moving steadily towards an activity that can’t start until it’s resolved.
Connecting constraints to programme activities gives teams a better basis for prioritisation.
Instead of asking only how long an issue has been open or who is chasing it, the project can look at what it could actually affect.
Now a constraint register starts becoming a planning tool rather than simply a record of outstanding issues.
Assigning somebody to a constraint is important, but context changes how that action is understood.
There’s a difference between saying:
“This RFI needs to be closed.”
And:
“This RFI is holding up the activity scheduled to start next Thursday.”
The action might be the same.
The reason it matters is much clearer.
That becomes particularly useful when constraints cross different teams.
Procurement may own the material issue while the site team owns the activity waiting for it. An access problem may depend on another contractor. The person answering an RFI may have no involvement in the package that needs the answer.
Connecting everyone back to the affected programme activity gives the project a common reference point.
This is the issue.
This is the work it affects.
This is when that work needs to happen.
And this is who needs to act.
One of the most useful things about linking constraints to upcoming work is that the project doesn’t have to wait for a date to move before recognising risk.
Suppose an activity is due to start in three weeks and currently has an unresolved access issue.
Today, there may be no programme delay.
The planned start is still intact. Nothing has moved.
Look only at the programme and everything might appear fine.
Look only at the constraint register and you know there’s an access issue, but you may not immediately understand its significance.
Connect the two and the picture becomes much clearer:
The activity is currently on programme, but there is an unresolved condition that could stop it starting as planned.
That’s useful information.
It gives the project an opportunity to act while the problem is still a risk rather than a recorded delay.
There can be a reluctance to escalate issues before anyone knows for certain that they’ll cause a delay.
Maybe the drawing will arrive tomorrow.
Maybe access will be resolved.
Maybe the subcontractor will pull things back.
And nobody wants every minor project issue treated as an emergency.
But early constraint management doesn’t require that.
The point is to record the issue, connect it to the work it could affect and understand how much time is available.
Some constraints will be resolved before they ever affect the programme.
Good.
That’s what you want.
A constraint disappearing without becoming a delay doesn’t mean it wasn’t worth tracking. It may mean the team found it early enough to prevent the impact altogether.
Early identification also matters if a constraint eventually does become a delay.
Commercial teams may need to understand when the issue first appeared, which work it affected and how the situation developed.
That story is much easier to establish when the relationship has been recorded as the project progresses.
The constraint was raised on a particular date.
It was linked to a particular programme activity.
The team could see when that activity was supposed to happen.
Someone owned the issue.
The constraint was eventually resolved, or it remained open until the planned work was affected.
That gives the project a contemporaneous record of the sequence.
Without it, teams can end up reconstructing the story afterwards from programme updates, emails, meeting minutes and separate registers.
Those questions become harder to answer the further the project moves from the original event.
Under most standard forms of contract, extension-of-time entitlement is also commonly subject to strict notice periods. Identifying a potential delay close to the causal event can therefore matter commercially as well as operationally.
The easiest schedule problems to spot are the ones already happening.
The activity is behind.
The milestone has moved.
Float has gone.
At that point, everyone can see the problem.
But that’s also when some of the best opportunities to deal with it have disappeared.
A more useful place to look is a few weeks ahead.
That’s where constraint management becomes genuinely useful.
The project moves from keeping a list of problems to understanding the work those problems could affect.
Some will need attention immediately.
Some can wait.
Some will disappear before they ever touch the programme.
But now those decisions can be made with the programme in view.
Because knowing you have a constraint is useful.
Knowing what it could make late, and how long you have to stop that happening, is what gives the team something to act on.
Uconia connects constraints directly to the Primavera P6 activities they threaten, giving planning, delivery and commercial teams a shared view of what’s standing in the way of upcoming work.
Instead of maintaining a separate list of issues with no clear relationship to programme dates, teams can record the constraint against the affected activity, assign ownership and track it while there’s still time to respond.
If the issue does develop into a delay, the relationship between the original cause and the affected programme activity has already been recorded as the project developed.
The goal isn’t simply to find more constraints.
It’s to find them early, understand what they threaten and act before they become tomorrow’s delay.
