Fifty percent of what?

Two things make that possible. The schedule has to know where the work sits in the project. And it has to measure progress by something real.

Get either wrong and your reports become fiction — confident, well-formatted fiction.

Where does this activity live?

Every activity in your model needs an address.

Not just a name — an address. Which part of the WBS does it belong to? Which control account pays for it? Who is the one manager accountable for that account?

This sounds like paperwork. It isn't. It's the wiring that lets a delay on site travel upwards.

One pipe spool arrives late on level 3. Because that activity is coded — to the HVAC package, to the mechanical control account — the delay doesn't stay on level 3. It rolls up. By the end of the day it's in the forecast the board reads.

That's vertical traceability: the site and the boardroom looking at the same number, arrived at the same way.

Without it, you get the thing every construction professional has seen. The site knows it's late. The monthly report says everything is fine. Both are being honest — they just aren't connected.

Coding buys you something else, too: one model, every audience. Filter by "level 3 + mechanical" and you've got the look-ahead for the mechanical subcontractor. Filter by milestone and you've got the client's view. Same file. No second schedule to keep in sync — and no second version to contradict you.

The 50% trap

Now the measurement itself. This is where most progress reporting quietly falls apart.

There are two ways a schedule can tell you an activity is half done.

Duration % complete measures time. The activity was planned for ten days, six have passed, so it reports 60%. Notice what it never asked: is any work actually done?

Physical % complete measures the work. Eight hundred square metres of blockwork planned, two hundred built — that's 25%. It doesn't care how long you've been standing there.

Duration percent will happily march to 100% while nothing gets built. It's a clock, not a measurement. Left unchecked it produces the classic construction disease: every activity reports 90% for months.

Physical percent is the only progress number worth putting your name on. It's objective, it's auditable, and it can be walked and counted on site — which is exactly why it's uncomfortable, and exactly why you should use it.

Define the rule before the work starts. How do we measure this activity — square metres poured, spools installed, welds tested? Agree it in advance, and progress becomes a fact. Agree it afterwards, and progress becomes a negotiation.

The wall between past and future

Every updated schedule has a line running through it: the data date. It's the moment your update is true as of.

Think of it as a wall.

To the left of the wall is the past. Only actuals live there — things that really happened, on the dates they really happened.

To the right is the future. Only forecast lives there.

Nothing crosses. And this gives you the fastest schedule audit in existence: look for work sitting on the wrong side of the line. An activity that was supposed to start three weeks ago, still showing as "planned," sitting to the left of the data date? That's not a schedule — that's a schedule nobody updated. Every hour it sits there, the forecast to the right of it gets more wrong.

Don't dictate. Let it calculate.

One last component, and it's the one that does the most damage: the constraint.

A constraint is you telling the schedule a date instead of asking it for one. Some are relatively harmless. One is close to fatal.

"Must finish on" is the fatal one. It overrides the forward pass and the backward pass. It forces total float to zero. And from that moment on, the activity will keep showing that date no matter what happens upstream — because you told it to.

Delays stop showing up. The critical path goes quiet. Everything looks fine, right up until it very much isn't. A hard constraint doesn't fix a date; it just blindfolds you.

The safer kind only pushes one way. "Start no earlier than" the site is handed over — that's a real-world fact, and it only limits the early dates. It doesn't destroy your float or hide your delays.

The principle behind all of it fits on one line:

You built the model so it would tell you things you don't already know. The moment you start typing the answers in, it can only tell you what you told it.

Practical insight

Three questions for your next progress report.

Is the percentage on this report time, or is it work? Can I walk the site and count it? Is there any activity to the left of the data date still showing as planned? And how many hard constraints are in this model — and what is each one hiding?

Answer those three honestly and your report stops being a summary of what people said. It becomes a measurement.

Key takeaways

✔ Every activity needs an address: a WBS place and a control account with one accountable owner.
✔ Vertical traceability means a site delay reaches the board's forecast automatically.
✔ Coding gives you one model for every audience — no second schedule to contradict you.
✔ Duration % measures the clock; physical % measures the work.
✔ Physical % is the only progress number worth reporting — and the rule is agreed before work starts.
✔ The data date is a wall: actuals to the left, forecast to the right, nothing crosses.
✔ Hard constraints ("must finish on") zero your float and hide your delays.
✔ Let the schedule calculate. Do not dictate.

What's coming next

We now have a model that knows where the work lives and how to measure it honestly.

Next week we go back to the beginning of the build — to the structure everything else hangs from. The Work Breakdown Structure: how to break a project into pieces that can actually be planned, priced, assigned and controlled. Get the WBS wrong and every schedule built on top of it inherits the flaw.

It's the most underestimated hour you'll ever spend on a project.