If I read a P6 update like an owner, I stop asking "what's late?" and start asking "can this job still finish when promised?"
That shift changes everything. I focus on the driving path to turnover, float loss, new constraints, calendar edits, procurement links, commissioning sequence, and 3-update trends. I also check a few hard numbers right away: CPLI below 0.95, more than 5% missing logic or hard constraints, lags over 5 workdays, activities over 44 workdays, and float drops over 10 days without a change event.
Here’s the article in plain terms:
P6 Schedule Red Flags vs. Strong Signals: Owner's Quick Reference Guide
| What I Check | What I Want to See | What Puts Me on Alert |
|---|---|---|
| Schedule version | Clear split between contract, baseline, and update | Team members reviewing different files |
| Critical path | One clear path that moves the finish by 1 day if delayed by 1 day | Path breaks, jumps, or depends on forced dates |
| Float | Stable near-critical chains with explained movement | Float erosion, low free float, or hidden delay absorption |
| Constraints | Few hard constraints with written support | New forced dates with no paper trail |
| Calendars | Same rules as approved plan unless documented | 6- or 7-day swaps, missing holidays, removed weather days |
| Procurement | Discrete links for submittal, approval, fabrication, delivery, and startup | One long bar or hidden time inside lags |
| Commissioning | Step-by-step logic to turnover | One "Commissioning Complete" activity at the end |
| Update trend | Stable or improving forecasts across 3 months | Finish slipping each month by the same amount |
If I can explain those points in simple language before the OAC meeting, I’m in a much better spot. The rest of the article shows how to make that review part of my monthly routine.
Owners want to know if the finish date is driven by logic they can trust all the way to turnover. That’s why it helps to review the path first, before OAC questions turn into awkward surprises. Start with the path. Then use float to see how close the schedule is to cracking.
A simple test works well here: delay the first critical-path activity by one day. If the project finish also moves by one day, the path is holding. If it doesn’t, the logic is broken.
A path you can trust should come from activity logic, not hard constraints. Trace it backward from turnover and make sure systems readiness, control wiring, and test plans are all tied in. If those links are missing, the finish date may look fine on paper while the field tells a different story.
A real critical path can be explained step by step without a report; if it cannot, the software built it, not the logic.
Also, flag any activity longer than 44 working days. Long durations tend to hide detail and can cover up slippage [9].
Once the path is solid, float tells you how near the schedule is to failure.
Total float is the time available before the project finish moves. Free float is the time available before the next activity moves. That difference matters.
When total float is high but free float is low, the activity sits in a chain that later runs into the critical path. That’s the kind of pattern an owner watches closely, because it can point to trouble before the finish date turns red.
Watch CPLI too. If it drops below 0.95, the plan has to perform better than planned to finish on time [9].
A useful filter is activities with 10 working days or less of total float. If a schedule has several near-critical paths, the risk is much higher than the critical path alone suggests [5][3]. And if total float keeps shrinking on a major milestone chain between updates, with no documented change order behind it, that usually means slippage is being absorbed quietly [2].
These are the patterns owners tend to question first in an OAC review.
| Owner Red Flag | What It Usually Means | PM Corrective Action |
|---|---|---|
| Dangling activities | Open ends make the schedule look healthier than it is | Add missing logic and close open ends |
| Long lags | Work or slack is buried inside a lag | Convert lags into activities |
| Hard constraints | Float is being protected by force, or negative float is being hidden | Remove non-contractual constraints |
| Out-of-sequence progress | The work in the field no longer matches the logic, so the forecast is off | Match logic to actual site sequence |
| Critical path migration | The path jumps between unrelated scopes with no clear reason, which can look like manipulation | Explain the path change in writing |
| Negative float | The schedule already shows a late finish before recovery starts | Issue a recovery plan or revise the finish date |
"A schedule that appears sound may, in fact, be manipulated to obscure float." - Mahdi Shahsavand, Associate, Rider Levett Bucknall [10]
Use DCMA as a baseline quality check. The targets are no more than 5% missing logic, 5% hard constraints, 5% high float, and 0% negative float [9][3].
Once you’ve confirmed the critical path holds and float is telling you the truth, the next step is simple: are the dates themselves real? A schedule can look neat in P6 and still hide risk underneath. Constraints, calendars, and milestones are usually where that happens.
In P6, constrained dates show up with an asterisk (*) in the Start or Finish date columns. Before each monthly review, add the Primary Constraint and Constraint Date columns to the activity view. If more than 5% of activities have hard constraints, the schedule misses the DCMA 14-Point threshold and should go back for correction [5].
Hard constraints such as Must Finish On and Mandatory Start override network logic. In plain English, the date comes from the constraint, not from the logic path. That matters because owners are looking at those dates to judge whether the finish date can be trusted.
"Hard constraints override the schedule logic and prevent the network from calculating dates correctly. They can mask negative float, artificially shorten the critical path, and make what-if analysis unreliable." - Adam O'Neill, Director, SOMA Project Controls [11]
One audit habit works well here: compare the current constraint log with last month’s version. Any new constraint added after baseline approval should have a written reason behind it, such as a contract change, a permit date, or a physical restriction. If there’s no paper trail, that constraint may be soaking up delay without showing the risk [2].
Calendar edits can move a finish date earlier on paper without changing the work itself. Shift an activity from a 5-day calendar to a 6-day or 7-day calendar, and the finish date can pull in. The same thing happens when weather days or holidays disappear from the calendar [4]. The fix is straightforward: compare the current calendar settings against the approved baseline [4].
This check matters even more on mission-critical and data center projects. Outage windows, AHJ inspections, procurement dates, and commissioning hold points are often tied to fixed outside dates. A commissioning milestone should match the contract exhibit exactly. Owner-furnished equipment dates, regulatory hold points, and substantial completion requirements should also be tied to real predecessor logic, not left hanging as isolated milestones [3][11].
The table below shows the four constraint types owners tend to question most in OAC reviews.
| Constraint Type | Typical Valid Use | Potential Abuse or Risk | What an Owner Will Question |
|---|---|---|---|
| Start On or After (SNET) | Site access restrictions; permit receipt dates | Pins a start date even after the restriction is lifted | "Is this tied to a specific contract exhibit or permit?" |
| Finish On or Before (FNLT) | Contractual completion milestones | Suppresses negative float; hides the true extent of a delay | "Is this date being met by real logic or just a forced setting?" |
| Mandatory Finish | Hard drop-dead dates for facility outages or school openings | Breaks the CPM network; prevents float from flowing to successors | "Does this constraint prevent us from seeing the impact of upstream delays?" |
| As Late As Possible (ALAP) | Just-in-time delivery for equipment with high storage costs | Consumes all available float; leaves zero buffer for commissioning | "How does this impact our commissioning buffer if delivery slips?" |
Soft constraints like Start No Earlier Than are usually acceptable when they model a real outside restriction. Hard constraints should be rare. If the team can’t tie a constraint to a contract document or a field condition, the owner will press on it.
Once the dates look believable, the next check is whether procurement and commissioning can still hit them.
Once critical path, float, and constraints look sound, the next places schedules tend to crack are procurement, commissioning, and labor. Owners read these areas as direct delivery risk. If procurement, commissioning, or labor planning looks thin, the milestone date looks thin too.
If long-lead procurement is not driving the schedule, the finish date doesn’t have much behind it. Equipment like switchgear, transformers, and chillers should show up in P6 as a clear chain of activities: submittal, approval, fabrication, factory testing, delivery, setting, and startup. It should not sit there as one summary bar.
A simple test helps: delay the long-lead activity and see whether the finish date moves with it [12]. If it doesn’t, that logic probably isn’t doing real work.
It also helps to filter for relationship lags over 5 workdays. Those lags often hide actual fabrication or transit work. Instead of burying that time inside a lag, the schedule should show it as trackable activities [8][3].
Once procurement is tied in the right way, the next step is making sure that same logic carries all the way into startup.
Commissioning logic should show how the team gets to turnover. It shouldn’t just stamp a late milestone on the far right side of the schedule. This is one of the most common places projects lose time they never planned for.
Start with the owner turnover milestone and trace backward. A solid schedule should show pre-functional testing, TAB, functional testing, controls integration, IST, training, punch list closeout, and turnover documents as separate activities tied together with logic [6][5]. If the whole thing appears as one “Commissioning Complete” milestone, the schedule is being guessed at, not sequenced.
Resource loading matters too. On paper, a schedule can look fine while quietly ignoring whether the crews even exist to do the work. That’s why the schedule also needs to reflect the labor and resource plan required to hit those milestones.
| Strong Schedule Signal | Risk Indicator | Likely Owner Interpretation |
|---|---|---|
| Discrete activities for submittal, approval, fabrication, and delivery [6] | Procurement shown as a single long bar with no logic ties [6] | Lack of accountability; high risk of hidden delays [6] |
| Lead times based on confirmed supplier quotes or tracked market data [6] | Generic placeholders or unverified assumptions [6] | Unrealistic planning; schedule is not a delivery tool [6] |
| Progressive commissioning milestones (pre-functional, functional, IST) [6] | A single "Commissioning Complete" activity at the end [6] | Commissioning is underplanned and likely to lose time at the end of the job [6] |
| Realistic trade density and leveled resource curves [7][12] | Aggressive trade stacking or over-allocated teams [7][5] | High risk of site congestion and productivity loss [7] |
| Resource-loaded with confirmed subcontractor commitments [6] | Unresourced activities or unlimited labor assumptions [6] | The schedule is planning fiction, not a management tool [6][5] |
Once you've checked logic, float, constraints, procurement, and commissioning, the monthly update should tell you one thing: what the owner needs to hear next.
A single monthly update shows where the job stands. Three updates in a row show where it's going.
Before the OAC meeting, compare the last three forecasts. You're not just looking at dates on a page. You're looking for direction.
If the forecast slips five days each month without a change event, that's a trend, not random movement. Look at float across the five to ten most critical chains. If total float drops by more than 10 days and there's no documented change event behind it, that's a strong sign that job performance is slipping and no one is calling it out [2].
There are two other patterns worth checking before you walk into the room.
When the trend is going the wrong way, don't stop at "the project is late." Turn that trend into a set of owner decisions.
Telling the owner the schedule slipped isn't enough. They need a path forward.
That means the recovery plan can't just be a new bar chart with tighter dates. It should spell out what slipped, why it matters, what the team plans to do about it, what the time or cost effect will be, and what decision or input the owner needs to give.
Give the owner options they can react to. That might mean resequencing work, adding shifts, or changing turnover timing.
But the plan also has to hold up under scrutiny. If the team says it can recover time, make sure the support is there. Confirm subcontractor availability. Show peak manpower by trade. Check that overtime or extra shifts fit site access limits and match what crews can actually produce. An owner's representative is going to pressure-test those assumptions [6][1].
Use this checklist to turn schedule findings into a clean OAC discussion.
| Review Area | What to Confirm | Red Flag |
|---|---|---|
| Critical path integrity | Can you explain the current driving path in one minute? | The path jumps between unrelated scopes without a clear narrative [2] |
| Float movement | Has float eroded since the last update without a change event? | Total float drops by more than 10 days without a documented change event [2] |
| New constraints | Have any new hard dates been added since the last update? | New "Must Finish On" dates added after baseline approval [2] |
| Procurement logic | Did long-lead dates move for a real reason? | Procurement dates shift without a documented supplier or change event |
| Commissioning sequence | Did turnover logic change since the last update? | Commissioning milestones move without a revised sequence behind them |
| Update trends | Is variance stable or improving across three updates? | Finish date slips by a consistent increment each month [4] |
Bring this checklist into the OAC meeting so the conversation stays on trend, risk, and decisions.
Check the logic first. Activities shouldn’t have open ends, and the critical path should come from real dependencies between tasks, not hard constraints that force dates and hide float.
Then look at monthly updates side by side. If the critical path jumps across very different parts of the job without a clear story behind it, that’s a red flag. A path you can trust should be easy for the planner to walk through and explain in plain language, not just something the software spits out.
Before an OAC meeting, look for warning signs that the schedule may be off or that project risk is climbing:
Check the schedule logic from construction completion through handover. Commissioning shouldn’t sit there as one big block at the end. It needs to be linked to specific systems so the handover path reflects how the job will actually finish.
Ask a simple question: Which systems need to be commissioned before other work can begin? That’s often where the schedule tells the truth - or doesn’t.
The same goes for procurement. If key procurement items slip and the schedule barely moves, the turnover forecast probably isn’t telling the full story. That usually points to missing logic ties between procurement, installation, startup, and handover.
It’s also worth checking whether concurrent trade work is hiding delays. On paper, overlapping activities can make the plan look fine. In the field, one late package can jam up several crews at once.
