Four statuses — Planned, In Progress, Delayed, Completed. Marking a stage in progress stamps the real start; finishing it stamps the finish and works out the run: "Actual: 7 days (planned 5) · +2 late". Both dates stay editable, because the crew tells you on Monday what happened on Friday. The closed Project phases card sums it up — done, running now, behind. One system for the whole post-frame business, instead of five tools taped together: the same dates feed the board, the customer's page, crew pay and the reports.
Also called: planned vs actual · how late are we · stage running over · days behind
Every stage records what it actually took, beside what you said it would
Marking a stage In Progress stamps the real start; completing it stamps the finish and works out the run — "Actual: 7 days (planned 5) · +2 late". Those lengths used to be worked out on screen and thrown away, so every completed stage carried a blank behind it and no builder could say how long framing really takes on his own jobs. Both dates stay editable, because the crew tells you on Monday what happened on Friday.
Asked how long post set really takes, the honest answer is a shrug, because every finished stage has a blank where the real days should be.
An owner can only fix what he can measure, and the crew's memory is not a measurement. Stamping the real start and finish as the stage moves — and keeping both editable for Monday's corrections — builds a record of how long each stage really takes on your jobs.
The plan is frozen at kickoff so nobody can move the goalposts
Change a stage from five days to seven halfway through and the estimate you are measuring against moves with it — a job that ran two weeks over reads as on time, because the plan was quietly edited to match reality one stage at a time. What a stage was figured to take is locked the moment the job starts. Where it sits on the calendar stays free to move, because rescheduling a job that slipped is not the same act as re-estimating it.
Post Set gets quietly re-estimated from five days to seven mid-job, and a build that ran two weeks late reports as on time.
Owner, crew and customer only get a fair measure if the yardstick holds still. Locking what a stage was figured to take at kickoff means a job that ran two weeks over reads two weeks over, while the calendar stays free to move.
Late and early are written on the bars themselves
A finished stage carries its variance on the bar — +3d in red, −2d in green — so the jobs that ran over are visible from the other side of the office without opening anything. The bar is the only place most people will ever look, which is why the number lives there instead of in a report someone runs at the end of a quarter.
Overruns live in a quarterly report nobody runs, so the same stage runs long on job after job.
The owner looks at the board, not at reports, so the number has to live on the bar. +3d in red and −2d in green make the jobs that ran over visible from across the office, the week it happens.
The numbers are worked out once, not by whichever screen happened to save
Actual days and variance are worked out where they are stored, on every write, rather than being sent up by the screen doing the saving. The office, the crew's phone and the analytics all read one figure, so there is nothing to reconcile. The alternative is a fault on one screen quietly writing numbers every other screen then trusts.
The phone says three days late, the office says one, and the end-of-job meeting turns into an argument about whose screen is right.
The office, the crew's phone and the reports should never disagree about how late a stage was. Working the numbers out where they are stored, on every save, means one figure for everyone and nothing to reconcile.
Every change to a real date says who moved it, and from what
Editing a real start or finish records the old value, the new value, the job, the stage and the person. Real dates decide crew pay, delay claims and what the customer gets told, so a quiet correction three weeks after the fact is exactly the kind of thing you want a line about.
A finish date gets pulled back three weeks after the fact, the crew's payout changes, and nobody can say who did it.
Real dates decide crew pay, delay claims and what the customer is told, so the owner needs to know when one changes. Recording the old value, the new value, the stage and the person turns a quiet correction into a line you can read.
The closed phases card says done, now and behind
Close the Project phases card and it still tells you the state of the job: the Hostetler Equipment Shed reads 3 of 6 done · Now: Siding / Roofing · 1 behind. A phase counts as done when every checkpoint that applies to it is ticked, and as behind when its planned end has passed and it isn't done — Post Set ran past its plan, so it is called out in red.
Post Set ran over on Tuesday and nobody noticed until Friday, because the stage still said In Progress and that sounded fine.
A project manager opening ten jobs a day needs the state of each without clicking in. Done, now and behind come from the checkpoints and the plan, not from a status somebody remembered to set — so "behind" shows the day it happens, not at Friday's call.
A finished job reads finished — without made-up crew logs
Try itOnce a job's last checkpoint is ticked in the project window it carries a completed date, and its phases show Done on the board and in the window even where no crew ever logged a start and finish for one of them. A real crew log always wins. Finished jobs sit under Completed on the Build Schedule.
Back-filling made-up start and finish dates to make old jobs look complete would quietly drag every "how long does framing take" number toward fiction.
An owner wants old jobs to look finished, but not at the price of fake numbers. Showing Done without inventing logs keeps the crew's real durations clean, so "how long does post set take us" is still measured only on jobs where somebody actually logged it.
- 1Mark a stage
In Progressand the real start is stamped. - 2Mark it
Completedand the finish is stamped. - 3The stage shows what it actually took beside what you said.
- 4Correct either date — every change records who moved it and from what.
- 5Choosing
Delayedopens the delay form instead of just flipping a switch. - 6Close the Project phases card and it still says how many are done, which is running and how many are behind.
Actual lengths and variance were worked out and shown on screen, then thrown away — written into the page and never into the record, so the numbers survived one session and vanished on reload. Every completed stage in the system carried a blank actual length behind it, which is why nobody could answer how long framing really takes on their own jobs.
- Variance metrics that were never persisted
- Estimates silently following actuals so nothing could be measured
- No record of when a stage really started or ended
- Overruns invisible until somebody opens the job
The estimate is frozen when the job starts
The moment a job goes live, the length you figured each stage at stops changing. The start day stays movable, because rescheduling a job that slipped is not the same act as re-estimating it. Over and under are measured against that frozen figure, not against something a mid-build edit rewrote.
