Two schedules, one job
On a mid-size commercial project there is a critical path schedule with somewhere between three and twelve thousand activities, maintained by a scheduler, updated monthly, and submitted because the contract says so. There is also a three-week lookahead that the superintendent rewrites every Thursday, built from what the foremen said they can actually do, and it is the document the job runs on. These two artifacts describe the same building and they routinely disagree by weeks. Nobody is lying. They are answering different questions for different audiences, and the gap between them is where the schedule quietly goes bad.
The gap matters because the monthly update is the only version that ever gets analyzed, and it is the version furthest from reality. A month is a long time on a job that is losing three days a week to a submittal that has not come back. By the time the network shows the slip, the sequence that would have absorbed it is gone.
So the useful question is not whether to build a better forecasting model. It is whether the commitments made in the trailer on Thursday can reach the schedule of record without a person retyping them, and whether the constraints that break those commitments can be seen far enough ahead to be cleared. That is mostly plumbing and workflow, and it is worth considerably more than a prediction.
You are probably here because
- The schedule says you are fine and the superintendent says you are not, and both have evidence
- Float on the critical path went from thirty days to negative eleven in one update and nobody can point to the cause
- A long-lead package was ordered eight weeks after the date it needed to be ordered, and everybody assumed somebody else was watching
- You bought a scheduling tool and the field never opened it
These are one problem seen from four sides: the plan people work to and the plan people report on are maintained separately, by different people, at different speeds.
Float is only as honest as the logic underneath it
Float is arithmetic on a network. If the network is loose, the arithmetic is fiction, and a great many submitted schedules are loose in specific, recognizable ways. Activities with no successor, so the path just ends. Hard start dates used as duct tape because someone did not want to model the real driver. Long lags standing in for work nobody wanted to break out. Activities with ninety-day durations that hide four sequences inside them. Start-to-start relationships everywhere, which make everything look parallel and drive float up for free.
A schedule quality pass is cheap and catches most of this. Count open ends, hard constraints, activities longer than about a month, negative float, high float above roughly forty days, and the proportion of relationships that are not simple finish-to-start. None of this requires a model, and running it on the last four schedules a scheduler submitted is usually more informative than anything else you could do in the same afternoon. If a third of the activities have more than forty days of float, the network is telling you the logic is incomplete, not that the job is comfortable.
Out-of-sequence progress is the other quiet distorter. Work happens in a different order than the logic says, and whether the recalculation uses retained logic or progress override changes the projected finish, sometimes by weeks, with nothing else changed. Two people can open the same file and read different completion dates. Anyone who wants to trust a forecast has to know which setting produced it, and it should be printed next to the date.
What a jobsite actually produces that is worth using
Construction produces more usable data than most industries and trusts almost none of it, usually for good reason. Sorting the trustworthy from the aspirational is the first real step in any project here.
| Source | What it really contains | How much to trust it |
|---|---|---|
| Submittal log | Package, date sent, days in review, ball in court, approval status | High. Dates are system-generated and the log is contractual |
| Purchase orders and delivery promises | Long-lead equipment, promised ship dates, revisions to those promises | High on dates, moderate on promises. Track the revision history, not the current value |
| Daily reports | Headcount by trade and area, weather, deliveries, visitors | Moderate to high on manpower. This is the most underused dataset on a job |
| Activity percent complete | A judgment, entered monthly, often anchored to the previous number | Low. Nearly useless for measuring productivity |
| Requests for information | Question, age, who is holding it, what area it affects | High on aging. The age distribution predicts trouble better than most metrics |
| Inspection results | Pass, fail, corrections, re-inspection dates | High, and a repeat failure by area is a strong early signal |
Notice the shape of that table. The reliable data is administrative and the unreliable data is the productivity measurement everyone wants to model. That constrains what is honestly buildable: constraint status, aging and procurement risk are well supported by real records. Crew productivity forecasting is not, unless you invest in measuring installed quantities, which most jobs do not.
What actually breaks weekly commitments — typical ranking
A representative ordering, not a measurement of your job. The point is that the top two are visible weeks ahead in records you already keep.
Count kept commitments before you forecast anything
The single practice that improves construction schedules most costs a spreadsheet. At the weekly planning meeting, write down what each trade commits to finishing in the coming week. The following week, count how many of those commitments were met and record a reason code for each miss. Six to eight reasons is enough: prior work not ready, material short, manpower short, information outstanding, weather, access, changed scope, other.
Two numbers come out. The percentage of commitments kept, which on jobs that have never measured it commonly starts somewhere in the fifty to seventy percent range and improves substantially once people know it is being counted. And a ranked list of why plans fail on this job, which is worth more than any predictive output because it names something the team can fix on Monday. If a third of misses are material short, the problem is procurement, and no scheduling software addresses procurement.
This matters for anyone considering a software purchase, because it is the honest baseline. If a vendor's product cannot tell you whether kept-commitment rate improved, it cannot tell you whether it worked. And if you have not measured it, you have no way to evaluate any claim about schedule improvement, from a vendor or from yourself.
Constraints are the part software genuinely fixes
Here is a workflow that exists on almost every job and works badly. A superintendent knows that the electrical rough-in on level four cannot start until the switchgear submittal is approved and the gear is delivered. That knowledge lives in his head and in a note. The submittal log lives in one system. The purchase order lives in another. The schedule lives in a third. When the approval slips two weeks, nothing connects that fact to the activity that depends on it until the week the crew shows up.
A constraint log that ties an activity to its blocking records, and pulls the current status of those records automatically, is straightforward engineering with a large payoff. Every activity starting in the next eight weeks gets a list of what must be true before it can start, each item pointing at a live record with a date. Anything whose blocking date has moved past the activity's start shows up on a list with a named owner. That is not artificial intelligence. It is a join and a query, and it prevents the single most common form of avoidable slip.
The extension worth building next is procurement lead time against need date. Long-lead equipment has been the defining schedule risk for several years running, and lead times on electrical distribution equipment, large air handling units and elevators have been long enough that the order date, not the installation date, is the true constraint. A report that lists every long-lead item whose order date is inside the next ninety days, with the current promise and its revision history, is the most valuable single screen on many jobs.
Thirty seconds, one hand, work gloves on
The superintendent is the person who has to enter a constraint, and he is doing it standing on a deck. If adding one takes more than about half a minute, or requires two hands, or requires choosing from a taxonomy he did not write, it will not happen, and the constraint log will be accurate for three weeks and then abandoned. Every successful field tool we have seen is designed around that limit. Every failed one had a better data model and a worse entry screen.
What a forecast can honestly say
Owners want a completion date. A single date implies a precision nobody has. What is defensible is a range built from your own history: durations on comparable activities across previous jobs, the current constraint load, and the kept-commitment rate for the last eight weeks. That produces a statement like a projected finish between the second and fifth week of March, driven by the level-four mechanical sequence and the elevator delivery.
Two conditions have to hold before that is anything other than decoration. You need enough completed jobs with comparable activity coding to know what duration variance looks like — a couple of dozen is a reasonable floor, and fewer than ten is guessing with extra steps. And the activity coding has to be consistent, which is a standards problem inside your own company that no software fixes. Firms with a real work breakdown standard get useful ranges. Firms where every scheduler names activities their own way do not, and the first project should be the standard rather than the model.
Be careful about what gets written down. A schedule is a contract document and an internal forecast that predicts late completion is a document too. That is a conversation for your counsel and your risk manager before a system starts generating and storing predictions, not after. It is a normal conversation to have. It is a bad one to have for the first time in response to a subpoena.
Send us your last four schedule updates and we will tell you what the logic is hiding.
Export the files, plus the submittal log if you can. You get back a written read: open ends, hard constraints, where float is manufactured, which sequences are actually driving the finish, and whether the network can support a forecast at all. One project, no charge, no meeting. Email contact@precisionfederal.com.
contact@precisionfederal.comThe superintendent who overrides the plan is usually right
Any tool that proposes a sequence will eventually propose one the superintendent knows is wrong. The inspector only comes on Tuesdays. The hoist comes down on the fourteenth. The owner's tenant is moving furniture through the lobby that week and nothing heavy goes up the east side. This knowledge is real, it is not written anywhere, and it will never be in your data.
Systems fail here in a predictable way. They present the model output as the answer, the super ignores it, the tool's recommendations drift further from reality each week, and within a month nobody opens it. The alternative is to build the override as a first-class feature: any user can pin a sequence, block a date range, or mark an activity as constrained by a reason they type in themselves, and the system takes it and re-plans around it without argument. Those overrides then become the most valuable dataset in the system, because they are a record of the constraints your planning process cannot see.
When you do not need software for this
A fourteen-person contractor running tenant improvements does not need a scheduling platform. That firm needs the submittal log to be current and someone calling the gear vendor monthly. Buying software to solve that is expensive procrastination.
The same is true one level up. If your schedules fail their basic quality checks, if activity coding differs by scheduler, if nobody counts kept commitments, then any analytics you buy will be computing on sand. Fix the standard first. It is unglamorous, it takes a quarter, and it makes every later investment work. We have told firms this and watched them buy the platform anyway, and it did not go well.
Where software does earn its place is at portfolio scale: a contractor running fifteen to sixty jobs, where nobody can hold the constraint status of all of them in their head, and where a project executive needs to know which three jobs need attention this week rather than reading fifteen reports. That is a real problem, it is genuinely hard by hand, and it is worth paying for.
The mistakes we get called in to fix
- A forecast built on activity percent complete, which is a monthly judgment anchored to last month's judgment
- Constraint logs maintained by hand, accurate for three weeks, then quietly stale for the rest of the job
- Float reported without saying whether retained logic or progress override produced it
- A field app with a twelve-field entry form, designed by someone who has never worn gloves
- Long-lead procurement tracked by current promise date only, with the revision history discarded
- Lookahead plans kept in a separate tool that never writes back to the schedule of record
- Duration estimates from a national database rather than from this contractor's own completed work
- Predictions stored with no retention policy, decided by an engineer rather than by counsel
A first phase that pays for itself
Typical sequence on a first project
Forecasting is deliberately not in that list. It comes after the coding standard and a couple of dozen completed jobs, and by then the constraint work has usually delivered more than the forecast would have.
Before you buy anything
- Run the quality checks on your own last four schedule updates and read the result honestly
- Count kept commitments for eight weeks so you have a baseline any vendor claim can be tested against
- Confirm your activity coding is consistent across schedulers before paying for anything that compares jobs
- Time the constraint entry flow with a stopwatch, standing up, on a phone
- Ask what happens when the superintendent disagrees and watch whether the answer is a feature or a shrug
- Decide the retention policy for generated forecasts with your counsel before the first one is written
- Require write-back to the schedule of record, or accept that you have bought a third schedule
Bottom line
The distance between the schedule you submit and the plan your crews work to is the whole problem, and most of it closes with joins, a constraint log and a weekly count of kept promises rather than with a model. Get your network logic honest, connect the records that block work to the work they block, and design every field interaction for someone standing on a deck in the rain. If there is budget left after that, a range-based forecast built on your own completed jobs is worth having. Not before.
Frequently asked questions
It can produce a defensible range if you have consistent activity coding and a couple of dozen comparable completed jobs to derive duration variance from. It cannot produce a trustworthy single date, and any product that offers one without asking about your historical data is selling confidence rather than analysis.
Usually because entering what they know takes too long, and because the tool cannot accept an override from someone who knows something it does not. A superintendent who cannot tell the system that the hoist comes down on the fourteenth will stop using the system rather than stop knowing about the hoist.
Count the commitments made at the weekly planning meeting, count how many were kept, and record a reason code for every miss. Six to eight reasons is enough. The ranked list of reasons will point at something fixable, and it costs one spreadsheet and ten minutes a week.
For billing, yes. For measuring productivity or forecasting, no. It is a monthly judgment that tends to anchor on the previous month's judgment, and it does not carry enough information to estimate a remaining duration. If you want productivity data, measure installed quantities, which is a real commitment most jobs decline to make.
Buy the systems of record — documents, submittals, purchase orders, daily reports. Build the connective layer that ties constraints to activities and pushes lists to named owners, because that logic is specific to how your company runs jobs. That layer is usually a few months of work, not a product.