Developer milestones are not ordinary planning targets. Once they are published to purchasers, funders, local authority conditions or a main contract, they become pressure the site has to live with. Freezing them from a weak network is how you buy a dispute with your own sales narrative. A baseline review before the freeze is the cheaper discipline.
The review is not a delay to the project. It is the last chance to change the date while it is still a planning output, not a promise.
Why developer dates harden so quickly
A construction finish in the planner's file can move with a logic change. A developer milestone often cannot. It sits in a sales release, a funding drawdown, a vacant possession commitment, or a sectional completion the contractor will be measured against. Marketing and commercial teams treat the date as fixed because their audiences do.
That is rational for them. It is dangerous for the programme if the date was taken from a tender programme that never survived a path walk, or from a summary bar that hid procurement and design release risk.
Freeze only after the network can carry the date
Do not freeze a developer milestone until four things have been checked against the working schedule.
- Logic: the path to the milestone is closed, walkable, and matches the method the site intends to use.
- Durations: crew sizes, shifts and production rates are still credible for the location and the trade market.
- Procurement and design: long-lead items and release packages sit as predecessors of the work that needs them, not as a single bar at the start.
- Sectionals: intermediate handovers, access dates and landlord or utility interfaces are modelled, not assumed inside a summary duration.
If any of those fail, you are freezing a hope. Hope is a poor contractual position.
What a baseline review covers
A baseline review before freeze is a structured read of the file that will become the benchmark. It is tighter than a casual look, and shorter than a full redesign.
| Review item | Why it matters before freeze |
|---|---|
| Open ends and constraints | A date held by a must-finish is not a calculated milestone |
| Critical and near-critical paths | You need to know what actually drives the developer date |
| Calendars and shutdowns | UK holidays, possessions and weather limits change working time |
| Procurement and approvals | Lead times often own the path after the frame is up |
| Sectional milestones | Sales or handover phases can be tighter than practical completion |
| Progress rules | The first update must measure the same network you froze |
| Float visible to leadership | A zero-float developer date with hidden near-critical paths is a trap |
The output should say: safe to freeze, safe to freeze if these fixes are made, or not safe. "Looks fine" is not an output.
The cost of freezing a weak network
Once the date is public, every honest update that moves it becomes a commercial and reputational event. Teams then protect the date in the file instead of protecting the truth. Remaining durations are squeezed. Constraints are added. The baseline is quietly edited. Variance disappears until it returns as a large slip nobody can explain from the record.
A weak freeze also damages claims and change control. If the benchmark never described a buildable sequence, later delay analysis spends its energy defending the original fiction. That work does not recover the sales date. It only documents how early the problem was knowable.
When to book the review
Book it when the developer milestone list is about to be issued, not after the brochure is printed. Book it again if the main contract programme will adopt those dates as sectional completions. Book it when the file has passed between MS Project and Primavera P6, or when a new planner has inherited a tender programme and is about to baseline it.
You do not need a crisis. The act of freezing is the trigger.
What to send
Send the current programme, the proposed milestone list with definitions of what "complete" means for each date, known procurement lead times, and any sectional or access constraints already agreed commercially. The reviewer needs the dates that will be sold, not only the bars that look important in the software.
Book the review before the promise
A baseline review is the point at which planning, commercial and developer interests should share one file. If the path cannot hit the date, change the date or change the method while both are still allowed. After freeze, you mostly change the story.
EVM Solutions runs baseline and schedule health reviews for teams who are about to lock developer and contractual milestones. If your dates are close to publication, send the programme before the announcement. Freezing a date the network cannot support is optional. Living with it afterwards is not.
