Every project schedule is wrong in detail from the first week, and a project manager who responds to each variance will spend the whole project re-planning and will still be surprised by the one that matters. Schedule control is mostly a filtering problem: which movements deserve a response, and which should be absorbed and watched.
Section 2.3.2 of the PMBOK® Guide Eighth Edition deals with monitoring and controlling the schedule, and the filter that works in practice comes down to three questions asked of any slip.
Float exists to be used. An activity with eleven days of float that finishes four days late has consumed part of a buffer that was put there for exactly this. Treating that as an incident teaches a team to hide small slips, which is how the large ones arrive without warning.
Measurement wobbles. Progress recorded on a Friday afternoon, percentage complete estimated by the person doing the work, an activity marked started on its planned date and not on the day the work began: all of these produce movement that describes reporting more than delivery. A variance that disappears next week without anybody doing anything was probably noise.
Does it touch a commitment? A slip that moves a date somebody else has planned around, a contractual milestone, a regulatory submission or a handover to operations needs a response today, whatever its size. A slip with no external consequence and plenty of float can wait for the normal cycle.
Is it an event or a rate? This is the question that separates a bad week from a trend. An activity delayed by a specific cause that has now passed is an event, and the schedule absorbs it. Work completing at eighty per cent of the planned rate for the third week running is a rate problem, and it will repeat every week until something changes, so the forecast has to be rebuilt on the observed rate rather than the planned one.
How much float has gone? Float consumption is the most useful early-warning measure on any schedule and the least reported. A chain that has used sixty per cent of its float in the first third of its duration is heading for trouble long before it shows a late date, and that is visible to anybody who looks.
A telecoms operator was building fibre through a city area, with splicing and commissioning following the civils. The programme reported against milestone dates monthly, and for three months the milestones were met.
The splicing rate told a different story. The plan assumed a crew would complete a certain number of closures a week. From the first week the actual rate ran at about three-quarters of that, consistently, with no week that came close to the planned figure. The early milestones were met because the first sections had float in them and because the build had started a fortnight early.
Each monthly review treated the position as recoverable, because each individual milestone was still being hit and the cumulative shortfall was described as something the team would catch up. Nobody asked the question that mattered: has the rate ever, in any week, reached the planned figure? It had not, so there was no evidence for catching up anywhere in the data.
By month five the float was gone and the shortfall was about seven weeks. The splice cabinet at one of the aggregation points made it visible in the plainest possible way: six trays closed and labelled, one part filled, and the rest bare with the fibre still coiled and taped against the side of the cabinet.
The recovery involved a second crew, which took six weeks to bring on, and a resequencing of two sections to release commissioning earlier. Both would have been available in month one at a fraction of the cost and with the date intact.
Absorb, resequence, compress, then re-baseline. Take float first, because that is what it is for. Resequence next, which usually costs nothing but attention. Compress only when the first two are exhausted, and with the trade stated. Each step costs more than the one before it, so working up the ladder from the bottom is both cheaper and easier to explain.
Re-baseline last, and never to tidy the report. A baseline is reset when the plan no longer describes the work at all, following a scope change, a major external event or a structural replan. Re-baselining because the variance has become uncomfortable destroys the only record of how the project has performed, and it is usually visible to everybody who has been watching.
For a PMP® candidate, it helps to recognise that the response depends on what the variance touches and whether it describes a rate, so a scenario about repeated small slips is asking about the rate rather than the individual events. A response that recovers each slip separately treats symptoms weekly. A structured PMP exam preparation course examines situations where every milestone has been met and the underlying rate has never been achieved.
Ask one question of your own project this week: in how many reporting periods so far has the work actually achieved its planned rate? If the answer is none, the plan is describing a capability the project has never demonstrated, and no amount of encouragement will close that gap.
Knowing which slips to absorb and which to act on is the difference between a project that is managed and one that is continuously re-planned. Omega's PMP® Exam Preparation works through schedule control as a filtering judgement.
Monitoring and controlling the schedule is covered in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
A110: The PMBOK 8 Schedule Performance Domain: What It Really Covers
A111: Dates Are Not a Schedule
A112: Critical Path Explained Without the Mystique
A113: Float Explained: How Much Delay Can You Really Absorb?
A114: Milestones vs Activities: Stop Treating Them as the Same Thing
PMP and PMBOK are registered marks of the Project Management Institute, Inc.