gantt
The chart on the trailer wall was accurate the morning it was printed. Then the concrete pour moved two days for rain, the electrician took a job across town, and the inspector offered a Thursday instead of a Monday. Everything to the right of that pour is now wrong, and fixing it means drawing the whole thing again.
That redraw is the real cost, and it is the thing construction schedule software should be bought to remove. Producing a first schedule is not hard, and a spreadsheet does it adequately. Producing the fourth version of it in six weeks, without an evening of work and without anyone building from the old copy, is where tools earn their price.
Count the redraws on a recent job. Most jobs of any length go through one every week or two, and each one takes somewhere between thirty minutes and half a day depending on how the schedule was built. At a modest rate for the person doing it, that is a recurring cost large enough to fund most scheduling tools several times over.
The hidden cost is larger than the visible one. While the schedule is being redrawn it is unavailable, so there is a window every week where the only correct version of the plan exists on one laptop. During that window everyone else is working from the previous version, which is the origin of most wrong day arrivals.
There is a third cost that shows up as behavior rather than hours. When redrawing is expensive, people stop doing it for small changes, and the schedule quietly stops matching reality. It is still on the wall, still being pointed at in meetings, and no longer true. A schedule that is trusted and wrong causes more damage than no schedule at all, because decisions get made on it.
So the question to put to any scheduling tool is not whether it can draw bars. It is what happens after one bar moves. If the answer is that everything downstream moves with it and everyone sees the result immediately, the tool is doing its job. If the answer is that the rest has to be dragged by hand, the tool has only replaced the paper.
The difference between a drawing of a schedule and a working schedule is whether the bars know about each other.
In a spreadsheet, a bar is a row with two dates. Nothing connects the rows, so moving the pour does not move the slab finish, the framing or anything else. The person holding the file becomes the dependency engine, recalculating in their head and retyping dates. This works for ten tasks and collapses somewhere around forty.
In a real scheduling tool, the relationship is stored. Framing starts after the slab is ready, so a two day slip on the slab pushes framing two days automatically, and the same push travels down the chain until it hits a task with enough slack to absorb it. That absorption is the useful part: the tool shows which delays cost nothing and which ones move handover, which is not something a human can reliably work out on a forty task job.
Two details separate tools that do this usefully from tools that merely have the feature. The first is whether a task can be pinned to a fixed date that refuses to move, because some dates genuinely do not move: a crane booking, a permit window, a concrete supplier slot. Without pinning, one recalculation quietly slides a fixed commitment. The second is whether the tool can show the difference between the original plan and where things now sit, so the accumulated slip is visible as a number rather than as a feeling.
Software listings rarely mention that the word schedule covers several different documents with different purposes.
| Kind | What it is good for | What it costs to maintain |
|---|---|---|
| Bar chart, one bar per activity on a calendar | Communicating the plan to trades, owners and inspectors | Low. Most tools and even spreadsheets handle it |
| Critical path network with stored dependencies | Working out which slips actually move the finish date | Moderate. Needs the logic entered once and kept honest |
| Line of balance or takt, repeated work across locations | Repetitive work such as floors, units or bays, where crews flow through space | Higher. Needs locations defined, and few general tools support it directly |
| Rolling three week lookahead | Running the job day to day and catching slips early | Low, if it is a view of the same tasks rather than a separate document |
Most small and mid sized contractors need the first, the second and the fourth, and do not need the third. That combination is worth knowing because it is the point where general project management tools become a legitimate option: a bar chart with stored dependencies and a short window view is ordinary Gantt functionality, not construction specific functionality. Line of balance and takt planning are where construction specific scheduling products are genuinely required, and paying for them when the work is not repetitive is paying for an unused capability.
Task based schedules assume that if two activities can happen in parallel, they will. On site they often cannot, because the same three people do both.
This is the most common cause of a schedule that is internally consistent and physically impossible. The logic says drywall and trim can overlap. The reality is one finishing crew, so they run in sequence, and the schedule was two weeks optimistic from the day it was drawn. Nothing about the dependency network catches this, because the conflict is in the resource, not in the sequence.
What catches it is a view organized by person or crew instead of by task, with people down one side and dates across the top. In that arrangement, double booking is visually obvious: a crew with two bars on the same days cannot do both. A tool that offers this alongside the Gantt lets the same schedule be checked from two directions, which is what the review before publishing a schedule should consist of. Board types that lay work out by person and by date are described on the features page for general tools that include them.
For subcontracted work the equivalent check is against the commitment, not the crew. A trade partner running four jobs has a capacity limit that is invisible in any single schedule, which is why the date has to be confirmed with them before it goes on the chart rather than after.
A schedule that counts calendar days rather than working days is wrong by about thirty percent before work starts. Weekends, holidays and shutdown periods have to be excluded by the tool, and any tool that cannot hold a working calendar will produce dates nobody can hit.
Weather allowance is the harder part, and it is a planning decision rather than a software feature. The usual approach is to build an allowance into the durations of weather exposed activities, such as excavation, concrete and roofing, based on what the site historically loses in that season, and to leave interior work unpadded. Padding everything equally hides where the risk actually sits and invites the allowance to be negotiated away wholesale.
Two habits make the allowance survive. Keep it as a visible task or a stated buffer rather than hiding it inside optimistic durations, because a hidden buffer gets spent without anyone noticing. And record the reason each time a date moves, so that by the third month there is evidence about whether the losses are weather, supply or sequencing. Most disputes about a schedule are really disputes about which of those three caused the slip, and the side with dated records tends to prevail.
Prices below were read from the published pricing pages on 2026-09-26 and exclude tax.
| Tool | Basis of the price | Published price |
|---|---|---|
| Fieldwire | Per user, per month | Basic $0, capped at 5 users, 3 projects and 100 sheets. Pro $39, Business $64, Business Plus $89, each per user per month billed annually |
| Contractor Foreman | Per company, in seat bands | $49 per month for 1 user, $105 up to 3, $166 up to 8, $221 up to 15, $332 for unlimited users, billed annually with a 30 day trial |
| Procore | Annual contract, users not counted | No figure published. The pricing page routes to a custom quote and states that users are unlimited |
| General project tool with Gantt boards | Per user, with a free tier | Commonly free for a small team, then a few dollars per user per month |
The basis matters more than the figure, and the reason is subcontractors. Under per-user pricing, every trade partner invited to see the schedule has a price, so most do not get invited, and the schedule reverts to being an office document that the field learns about by phone. Seat band and unlimited-user pricing remove that decision. Some general tools solve it by not counting view-only guests toward the seat total, which is stated on their pricing page. Whichever route is chosen, the test is the same: can everyone who needs to build from the schedule see the current version without someone deciding it is worth the money.
One person drawing and redrawing the schedule looks like control. It behaves like a queue. Every change waits for that person, and while it waits the published schedule is wrong.
The alternative is not that anyone can move anything. It is that the people doing the work can report what happened, including dates that slipped, while a smaller number of people can change the plan. That split keeps the record current without letting the plan drift, and it removes the bottleneck that makes weekly redraws feel expensive.
This is usually a permissions question rather than a scheduling question, which is why it gets skipped during tool selection and then decides the outcome. Before buying, check whether the tool can give a foreman the ability to mark a task late without giving them the ability to rewrite the sequence. If it cannot, the schedule will keep passing through one person, and the redraw problem will still be there after the purchase. How different tools divide these roles is set out in the tool comparisons.
Move the schedule off any format where dates are typed rather than linked, because until the bars know about each other every change is a redraw. Then check two things on whatever replaces it: that trade partners can see the current version without adding to the bill, and that a foreman can report a slip without being able to rewrite the plan. A board where the Gantt, the calendar and the crew view are the same cards is enough to start, and Pinateca is free for up to five people and ten boards while that is being tested.
For a short job maintained by one person, yes, and it costs nothing. It fails on two specific things: dates in a spreadsheet are typed rather than linked, so every change is a manual redraw, and there is no reliable way for the field to see the current version. When redraws start happening weekly, the labor cost has usually passed the cost of a tool.
Stored dependencies are worth having on anything past roughly forty activities, because that is the point where working out the knock-on effects of a slip stops being reliable in someone's head. Formal critical path analysis with float calculations matters most when there are contractual delay claims. Below that, dependencies plus a three week lookahead cover most of the value.
There is no universal figure, and copying one from another region produces a schedule nobody can hit. The workable approach is to add allowance only to weather exposed activities such as excavation, concrete and roofing, sized on what that site loses in that season, and to keep it visible as a stated buffer rather than hiding it inside durations.
The master schedule covers the whole job and is the contractual reference, revised occasionally. The lookahead covers the next two to four weeks in detail and moves forward every week. The lookahead is what catches slips in time to act, and it works best as a view of the same tasks rather than a second document kept in step by hand.
Only if it can show the plan organized by person rather than by task. In a task oriented Gantt, two parallel bars assigned to the same crew look perfectly valid. A view with people down one side and dates across the top makes the conflict visible, which is why checking a schedule from both directions before publishing it is worth the few minutes.