Define Before Evaluate

Before asking whether a plan worked, I want to know what we agreed to measure.

A shorter programme is not automatically a better programme. It may be working with different scope, assumptions or acceptance criteria.

That is why I want the basis of a decision to be visible before the outcome is evaluated.

For a construction work package, that means agreeing what is included, what must happen first, what counts as complete and who is authorised to accept it.

It also means preserving the baseline when an approved change is introduced. The team should be able to explain the difference between the original commitment, the current forecast and a revised scope.

The same discipline guides how I think about my ongoing BIM-to-schedule work. Before evaluating an output, I want the review criteria to be explicit: defined scope, traceable assumptions, complete work packages and sequencing that a planner can explain.

This is a principle for developing and reviewing the workflow, not a claim of validated performance.

For me, good project controls make decisions easier to explain—to the client, the delivery team and the next person who needs to act.

Agree the rules first. Keep the baseline visible. Make every change explainable.

When a programme changes, how clearly can your team explain what changed—and why?

Concept visual series — fictional scenes, not photographs of my projects or team.