The first progress update feels like the start of control. It is also the moment a weak network becomes the official story. Percent complete, remaining duration and a moved data date all calculate through whatever logic you accepted. If that logic is wrong, every later report is a precise calculation of the wrong project. Test it before the first update, while the file can still be changed without explaining a movement in the forecast.
Start from the finish, not from the first activity
Open the completion milestone the contract cares about and walk backwards. Each step needs a predecessor that is real work, a real approval, or a real delivery. Write the path down in ordinary words. If you cannot explain it to the construction manager without opening the software, the logic is not ready.
Then do the same for the other contractual dates: sectional completion, power-on, a possession, a handover of a floor. A schedule can have a tidy path to the final date and a broken path to the date that actually matters.
The tests that catch most bad logic
| Test | Pass looks like |
|---|---|
| Open ends | Every activity has at least one predecessor and one successor, except the true start and the true finish |
| Relationship type | Finish-to-start is the default, and every start-to-start or finish-to-finish has a reason |
| Lag | Lag is short and explained. Long lag is replaced by an activity with an owner |
| Constraints | Hard constraints are rare, named, and tied to a third-party date |
| Calendars | Holidays, shutdowns, shifts and weather limits sit on the activities they affect |
| Durations | No activity is so long that progress cannot be judged inside one reporting period, unless it is genuinely continuous |
| Milestones | Contract dates are milestones driven by work, not dates typed onto the milestone |
| Critical path | The driving path matches the build sequence the team described in the workshop |
Run the software checks first. They are fast and they remove the noise. Then spend the time on the path. A closed network can still be nonsense. The classic example is a finish held by a mandatory constraint, with the real work showing float, so the report says the job is critical for a reason nobody is managing.
Out of sequence, before any sequence has happened
You cannot see out-of-sequence progress before work starts, but you can see the relationships that will force it. Look for packages that the site will start as soon as an area is free, while the logic says they wait for an unrelated predecessor. Look for design activities that finish after the construction they are supposed to release. Look for procurement that is a predecessor of the whole building rather than of the activity that needs the material.
Fix those links now. After the first update, the same links appear as out-of-sequence progress and a debate about retained logic. That debate is the unpaid invoice for a test you skipped.
A workshop that takes half a day
You do not need a special tool. You need the planner, the person who will build the job, and someone who owns procurement or design if those sit on the path.
- Print or filter the critical path and the paths with less than ten days of float.
- Read each activity aloud. Ask what has to be finished before it, and what it releases.
- Mark any link the room does not believe. Do not defend it in the meeting. Change it or record why it stays.
- Check the calendar on the first and last activity in each path.
- Recalculate. Read the new path. If the finish moved, understand why before you leave.
The output is a baseline you are willing to update, not a file that passed a score. Agree the progress rules at the same time: who states remaining duration, what percent complete means, and how you will record a change in sequence. The first update should not be the meeting where those rules are invented.
What to do with the result
If the path is credible, set the baseline and do not keep editing it in the days before the first data date. Further good ideas can go in a log. They should not keep the benchmark moving.
If the path is not credible, do not take the first progress update on it. An update on bad logic produces a variance you will then have to explain as if it were performance. Delay the report by the time it takes to repair the network. That delay is shorter than the argument the bad update will start.
The standard to hold
Before the first progress update, a stranger should be able to start at the finish milestone and reach the start of the job through relationships the team recognises. Calendars should match the way the site will work. Constraints should be exceptions with names. When that is true, the first update measures the project. When it is not, the first update measures the schedule.
