gantt
A two week delay is almost never a two week event. It is a one day slip on a Tuesday that nobody wrote down, followed by a trade that could not be rescheduled, followed by an inspection window that closed. By the time it shows up as a two week delay it has stopped being a scheduling problem and become a money problem.
That is the only real argument for construction project tracking software. Not reporting, not dashboards for the owner, not a tidier version of the schedule. The question to ask of any tool in this category is narrow: how many days pass between something slipping on site and the person who can react finding out.
Most software sold as tracking is actually reporting. Reporting looks backward and is addressed to someone else: the owner, the lender, the head office. It is produced weekly or monthly, it is formatted, and by the time it exists the information in it is old enough that nothing can be done about it.
Tracking is addressed to the person who can still change the outcome, and its useful lifespan is measured in days. It answers a different question. Reporting answers how the job is doing. Tracking answers which of the next ten tasks is now at risk, and whether a phone call today prevents a week of standing around next month.
The distinction matters when choosing software because the two jobs pull in opposite directions. Reporting rewards completeness, so reporting tools ask for a lot of fields. Tracking rewards speed of entry, so every extra required field makes tracking worse. A tool that satisfies the head office often fails on site for exactly that reason, and the failure is silent: the fields get filled in on Friday afternoon from memory, which produces a record that looks complete and is not true.
Decide which job is being bought before comparing anything. If both are needed, it is usually cheaper to do tracking well in one place and generate the report from it than to buy a reporting system and hope the field feeds it.
Ask for progress and the answer comes back as a percentage. Framing is 70 percent done. That number is the least useful thing on the page, for two reasons.
The first is that it is an opinion. Nobody measures 70 percent, they estimate it, and estimates from the person responsible for the task drift optimistic in a predictable direction. The second is worse: percent complete has no relationship to the calendar. Framing at 70 percent tells nobody whether it will finish on Thursday as planned or the following Wednesday.
Three signals carry more information and all three are yes or no answers, which is why they survive being collected on a phone.
Did the task start on the day it was supposed to start. A late start is the earliest reliable predictor of a late finish, it is knowable the same morning, and it requires no judgment. A task that started three days late is behind by three days, and no amount of percentage optimism changes that.
Second, how many tasks sit to the left of today on the schedule and are not marked finished. That count is one number for the whole job, it takes one glance at a Gantt view to read, and it goes up before anything visible goes wrong.
Third, how many days of float are left on the critical path. Float is what a delay spends. A one day slip on a task with ten days of float is noise, and the same slip on a task with none is a delivery date moving. Tools that show these two identically are the reason people stop trusting their own schedule.
Long tracking templates are the reason tracking stops. On a job run by a handful of people, four items carry most of the value.
| What to track | How it is recorded | What it tells you |
|---|---|---|
| Planned start against actual start | One date, entered the day it happens | Whether a slip has begun, days before the finish date moves |
| Tasks past their finish date and still open | A count read off a Gantt or list view | Whether the backlog of small slips is growing |
| Blocked tasks and what is blocking them | One line of text on the task | Which phone call to make today, and who owes the answer |
| Committed dates given to trade partners | The date on the task the sub can see | Whether the schedule in the tool matches what people were actually told |
The last row is the one most often missing and the one that causes the most reschedules. A date that lives only in the office is a plan. A date the sub has seen and acknowledged is a commitment, and only commitments are trackable. When the two diverge, the tool starts describing a project that is not the one being built.
Everything else, including cost codes, labor hours and photo counts, is worth collecting for other reasons. None of it makes a delay visible earlier than the four rows above.
Tracking systems do not fail on capability. They fail because entering the update is more expensive than the update is worth to the person entering it.
A useful threshold is thirty seconds on a phone, one handed, outdoors. Marking a task started, attaching a photo and typing one line about why something is waiting should fit inside that. If the action requires a laptop, a VPN, choosing from a drop-down of forty cost codes, or finding the right sheet first, it will happen for about a week and then stop.
There is a second threshold that gets ignored: the update must be visible to everyone else without a human step in between. Any arrangement where the field sends a text message and someone in the office types it into the master file has a single point of failure who occasionally takes a holiday. That arrangement also destroys the timestamp, which is the whole point of tracking. An update that arrives in the system three days after the event cannot make a delay visible early.
The test on a trial is therefore not whether the tool can hold the data. It is whether a foreman with no training can mark a task late from a phone, and whether the number that counts overdue tasks changes immediately when they do.
The word covers very different products. Prices below were checked on 2026-09-26 and exclude tax.
| Kind of tool | What it tracks best | Published entry price |
|---|---|---|
| Field management, such as Fieldwire | Tasks tied to a position on a drawing, punch items, inspections | Basic $0 per user, capped at 5 users, 3 projects and 100 sheets. Pro $39 per user per month billed annually |
| Business system, such as Contractor Foreman | Costs against budget, time cards, change orders, daily logs | $49 per month for 1 user up to $332 per month for unlimited users, billed annually |
| Platform, such as Procore | Everything, across owner, general contractor and subs | No figure published. The pricing page routes to a custom quote and states users are unlimited |
| General project tool with a Gantt | Dates, owners, dependencies, decisions and conversation | Commonly free for a small team, then a few dollars per user per month |
The choice follows the question being asked. A tool built around drawings answers where in the building the problem is. A tool built around cost codes answers what the problem costs. A tool built around dates and dependencies answers what moves next if this slips, which is the question behind most searches for tracking software, and it is the only one of the three that a general tool handles well. Details of what that looks like are on the features page for the general option, and the pricing page shows what the seat rules do to the cost of inviting subcontractors.
Master schedules are for contracts. They are long, they are revised rarely, and they are too big to read every morning. Tracking against one produces a single verdict about the whole job, which is not actionable.
The alternative used on most well run sites is a rolling three week window. Only the next three weeks are held in detail, the window moves forward every Monday, and the master schedule updates from it rather than the other way round. That shape has two properties worth paying for. It is small enough that someone will actually review it in a standing meeting, and it is exactly long enough to fix a problem: three weeks is usually enough notice to reschedule a trade or reorder a long lead item.
Tracking software should support this without ceremony. What that requires in practice is one set of tasks that can be viewed as a whole job and as a three week slice, rather than two documents kept in step by hand. A tool where the lookahead is a separate export is a tool where the lookahead goes stale.
Every tracking system records that a date moved. Most lose why, and the why is what prevents the same slip next month.
A date change with no attached reason is a fact without a cause. Six weeks later, when the same trade slips again, nobody can tell whether the pattern is weather, a supplier, an access conflict or one person's optimistic estimating. The reason usually exists somewhere, in a text thread or a phone call, and it dies there.
This is a strong argument for keeping the conversation in the same place as the task rather than in a separate chat tool. When a comment on the task carries the reason, the history is readable a year later by someone who was not there. When the reason lives in a chat channel organized by day, it is unfindable within a week. Comparisons of how different tools handle this are set out across the tool comparisons.
Stop tracking percent complete and start tracking planned start against actual start, because that one change makes slips visible weeks earlier at no extra cost. Then check that a foreman can record it from a phone in under thirty seconds without anyone retyping it, since that is what decides whether the data is real. A board where the Gantt, the task list and the conversation sit on the same cards is enough to run this, and Pinateca is free for up to five people and ten boards while it is being tried.
Tracking is a subset aimed at one question: what is late or about to be. Management software usually adds estimating, procurement, document control and cost accounting around it. Many small contractors need good tracking and very little of the rest, which is why a cheaper general tool sometimes outperforms a construction platform on the thing that was actually hurting.
Daily for starts and finishes, weekly for the lookahead. Daily works only if the update takes seconds and is made by the person who did the work. Weekly batch updates entered from memory produce a record that looks complete and reports slips several days after they could have been acted on.
They can, by phone and text, and that is what most small contractors do. The cost is that the tracking record is a transcription made by someone in the office, so it is late and incomplete. A limited or view-only role scoped to their own tasks is usually the better trade, and the deciding factor is whether the pricing counts those restricted users as paid seats.
For dates, dependencies and a record of decisions, free tiers are often sufficient at the scale of a five person office. The limits that bite first are caps on projects and on drawing sheets in field management tools, and caps on people and boards in general tools. Check which cap applies before assuming free is a trap.
Float is how many days a task can slip before it moves the finish date. A slip on a task with plenty of float costs nothing, and the same slip on a task with none moves handover. Percent complete cannot distinguish the two, which is why schedules that report only percentages feel reassuring right up until the delivery date moves.