Construction scheduling software cannot fix a schedule nobody updates

This guide is published by SyteNav, which makes one of the tools in this category. It is written as the process guide we would want if we did not sell anything: what a schedule is for, what has to happen when it moves, and only then what software does about it - including where ours stops.

Why the schedule stops being true

Ask a contractor when their schedule was last correct and the honest answer is usually a date, not a duration. It was correct at the pre-construction meeting. It has been drifting ever since, and the drift is invisible because the document does not change - the job does.

Three things cause it, and none of them is laziness.

• THE SCHEDULE LIVES WHERE THE WORK IS NOT. It is maintained in an office by one person, from photographs and phone calls, a day or two behind what is actually built. By the time a slip is entered, the trades behind it have already been told the old dates.
• UPDATING IT IS EXPENSIVE. If moving one trade means re-typing the eleven that follow it, that job gets done on Friday if at all - so the schedule is accurate once a week, on the day fewest decisions are made from it.
• NOBODY IS TOLD. This is the one that costs real money. A date that changed in a file and not in anybody’s week is a date that has not changed: the sub shows up, or does not, on the date they were given.

So the useful question about scheduling is not "can it draw a bar chart". Every tool draws a bar chart. It is whether keeping the plan true is cheap enough that it actually happens, and whether a change reaches the people whose week it is.

What a schedule is actually for

It is doing three jobs at once, and they pull in different directions - which is why schedules that serve one of them well feel useless for the other two.

• SEQUENCING. What has to finish before this can start. This is the part that looks like project management and the part software is usually built around.
• TELLING PEOPLE WHEN. Each sub needs one thing from your schedule: the days they are expected, kept current. They do not want your Gantt chart, and they will not open it.
• EVIDENCE. Months later, what was planned, what moved, when it moved, and who was told. This is what a delay claim is made of, and it is the job a schedule silently stops doing the moment somebody starts overwriting dates in place.

And a slip usually has a cause. When the cause is extra work somebody asked for, the two days the schedule moves are part of what that change order costs - which is worth pricing at the time rather than remembering at the end. When the cause is a trade that simply did not turn up, the schedule is where you can later prove it.

One trade slips, and everything behind it moves

This is the whole problem in one sentence, and how a tool handles it is the thing worth evaluating. Say sheetrock finishes three days late.

Hand-run, you now have a choice nobody enjoys: re-type every trade behind it, or leave the plan wrong and hold the difference in your head. Most people do the second, and the schedule quietly becomes a record of what was once intended.

A tool that models dependencies does it for you - but the arithmetic it uses matters more than the feature name suggests.

The second is the correct behaviour and it is worth testing explicitly in a demo, because both look identical in the simple case: when a dependent starts the very next day after its predecessor ends, snapping and shifting produce the same date. The difference only shows up on the lines that sit further out, which are exactly the lines nobody checks.

The rules that go with it

• MEASURE THE PREDECESSOR’S FINISH, NOT ITS START. A trade whose start holds but whose end slips three days has taken three days longer, and everything waiting on it moves three days. Measuring the start reports "nothing else moves" for the most ordinary slip there is.
• THE SHIFT WORKS BOTH WAYS. If a trade finishes early, everything behind it should come forward too. A chain that only ever moves later drifts in one direction for the life of the job.
• DO NOT RE-APPLY THE GAP EACH TIME. If a dependency carries a few days of breathing room, that gap is already in the dates. Adding it again on every recalculation turns it into a floor, and the line creeps later every time anything upstream twitches.
• A DATE SOMEBODY TYPED WINS. If a person has set a line’s dates by hand since the link was made, an automatic recalculation must not overwrite it. Skip that line - and say so on screen, because a linked line missing from the list reads as one that is not linked at all.
• REFUSE A LOOP. If A waits on B and B waits on A, the tool should say so rather than compute forever or pick one.

A schedule nobody is told about is just a calendar

The dates moving in your system is the easy half. The half that decides whether the slip costs you money is whether the electrician who was coming Tuesday knows they are now coming Friday - and whether the trade that was waiting knows it can start.

Two messages are worth their weight here, and they go to different people: your dates moved, and you are no longer blocked. The first prevents a wasted mobilisation. The second is the one that recovers time, because a sub who does not know the wall is ready does not turn up early out of optimism.

Telling people should also be an explicit act rather than an automatic one. There are legitimate reasons to move dates quietly - you are re-planning, the change is not settled, the move is a correction of your own typo - and a tool that emails eleven subs every time you drag a bar will be used once.

The field has to be able to read it

A schedule is consumed on a phone, outdoors, by somebody holding something in the other hand. That constraint kills most of what desktop scheduling tools do well. Seven columns of a month grid on a 390px screen is a square about the width of a thumbnail - text does not fit in one, so a phone month view has to be colour and a tap, not labels.

It also changes what you should expect people to do. A foreman is not going to re-plan a chain of dependencies from a phone. What they need is today and the next few days, for this job, in one screen - and for the office, a view across every job so two crews are not promised the same Thursday.

The schedule is also read by people who are not planning anything. Progress claimed on a sub’s invoice gets checked against the logs and the schedule before anybody approves it, so a schedule three weeks out of date quietly removes one of the few cross-checks you have on a progress claim.

Be realistic about who needs write access, too. Most of the people who READ a schedule should never edit one, and the ones who do the editing are a small group in the office. A tool that makes everybody a scheduler produces a schedule nobody trusts.

What to test before you buy

Twenty minutes with a real job answers more than any feature grid. Build a short chain - framing, rough-in, inspection, drywall - and then break it on purpose.

1. 1Link four trades in sequence, with a couple of days of breathing room between two of them.
2. 2Slip the first one by three days and look at what the tool proposes BEFORE it writes anything.
3. 3Check the line furthest down the chain. Did it move three days, or did it jump to sit against its predecessor? This is the whole test.
4. 4Check that your deliberate gap survived.
5. 5Now pull the first trade three days EARLIER and confirm the chain comes forward as well as back.
6. 6Edit one line’s dates by hand, then slip its predecessor again. The hand-edited line should be left alone and reported, not silently overwritten.
7. 7Send the change to a sub and look at what they actually receive. Then check what happens to a sub with no email address on file.
8. 8Open the whole thing on a phone, outside, and try to answer "what is happening on this job today" in one screen.

How SyteNav handles it

A schedule line is a trade, a set of dates and optionally the sub who owns it - and a line with no sub attached is a placeholder, so a chain can point at "sheetrock, dates to be confirmed" before anybody is awarded. Dependencies point at a LINE rather than a trade, which is what lets electrical rough-in and electrical finish be waited on separately. A link can carry a few days of lag, and it can carry a progress gate: drywall does not start because framing is finished, it starts because framing is far enough along.

When a line moves, every line that waits on it shifts by the number of days that line’s FINISH moved - signed, so pulling a trade earlier pulls the chain forward too - and the lag takes no part in the arithmetic, because shifting by the delta already preserves the gap. A line whose dates were edited by hand after the link was made is skipped and listed with the reason, never moved underneath you. Circular links are refused. Nothing is written until a review screen shows what moves, what does not and why, and then asks the question separately: notify the subs, or shift silently. It names the subs who will get an email, and warns you about the ones with no address on file who will not hear it from SyteNav.

Two notifications carry it: the sub whose dates moved is told, and the sub who just became unblocked is told. There are three views over the same job - a month calendar, a timeline and a list. Only the calendar draws the job’s other dated things beside the schedule: tasks that are due, and inspections that are actually booked. The timeline and the list stay schedule-only, because they are the editor, and a row nothing can save does not belong in one. On a phone the month grid is dots, and tapping a day opens what is on it.

What it does not do, plainly: there is no critical path, and no float or slack. It does keep a baseline - every date move is recorded with what the dates were before, whether somebody called it a delay and why, so as-planned against as-built is a question it can answer - but there is no resource levelling, and no import or export to MS Project or Primavera. It works in calendar days - there is no working-day calendar, so weekends and holidays are not skipped for you. And the cross-project month view is for admins and managers; everyone else gets their own job and their own day.