Scheduling · Software category
Construction scheduling software,
judged by whether the programme stays current.
Any product can draw a Gantt chart. What separates the category is whether the programme has real dependency logic, whether the trades doing the work ever see it, and whether it is still true in the third month. This page covers what scheduling software does, what actually moves a residential date, what to look for, the questions worth asking, why programmes go stale, the honest limits, and how VIABUILD approaches it.
01 / The direct answer
What construction scheduling software does
Construction scheduling software holds the programme for a job, the tasks, their durations, the order they must happen in and who is doing each one, and it links those tasks so that when one moves the work depending on it moves too. On top of that it usually adds trade allocation and notification, lead time and delivery tasks, non-working days, a saved baseline to measure slip against, and a way for the site to record what actually happened.
The category is easy to shop for badly, because a bar chart is the most photogenic thing in construction software and the hardest to evaluate from a screenshot. A chart with fixed dates and no logic looks identical to a programme that responds to reality. The difference only shows when something moves, which is why every useful demonstration in this category involves moving something.
This page is the category buying guide. The discipline itself is in the scheduling reference, the working routine for a residential job is the residential construction scheduling guide, and the specific question of what AI does and does not contribute to a programme is on AI construction scheduling.
02 / The distinction
A task list and a programme are not the same thing
This is the decision underneath most searches in the category, because a builder already running a shared task list is reasonably asking what else there is. Six differences that show up the first time a job slips.
A task list holds dates, a programme holds relationships
On a list, frame starts on the eighth because someone typed the eighth. On a programme, frame starts after slab cure and after the frame delivery, so when the slab slips by four days the frame moves with it. The difference is not presentation, it is whether the plan can respond to reality without being rebuilt.
The critical path tells you which delays matter
Every job has tasks with slack and tasks without. A week lost on landscaping is a week lost on landscaping. A week lost on the frame is a week lost on handover. A list treats those two identically, and that is why builders chase the wrong delay.
Lead times are commitments, not durations
Windows ordered eight weeks out are a task that starts long before anyone is on site, and the order date, not the install date, is the one that can be missed. A programme that only shows on-site activity hides the decisions that actually control the date.
Trade bookings are a promise to somebody else
Your programme is also six other businesses’ programmes. When a date moves, the useful question is not what your chart says but whether the tiler can still come. Software that changes dates silently and tells nobody has created a scheduling problem rather than solved one.
A baseline is what makes slip visible
Without a saved original, a programme that has been updated twelve times looks like a programme that is on track, because it always shows today’s plan. The baseline is the only thing that lets you answer how far behind the job actually is, and how it got there.
Progress is a fact, not a percentage
A task is not seventy per cent done because it feels that way. It has either started or not, finished or not, and the honest version of a residential programme runs on those two facts plus a realistic remaining duration. Percentage complete on a task list is where optimism accumulates quietly.
03 / The real constraints
What actually moves the date on a residential job
Programmes are usually built around trade durations, and trade durations are rarely what moves handover. Five things do most of the damage on a residential build, and only two of them are inside the schedule as most builders draw it.
Trade availability. Your programme is a plan for the behaviour of six or seven other businesses, each running their own programme. A two-day slip that costs you nothing on paper can cost a fortnight in practice, because the tiler you released has taken other work and the next window is three weeks out. This is why re-sequencing after a delay is usually a negotiation rather than a calculation.
Procurement lead times. Windows, trusses, cabinetry, tiles and imported fittings are ordered weeks or months before they are installed, and the task that can actually be missed is the order date, not the install date. A programme that shows only on-site activity is silent about the decisions that control it. The reference is lead times and sequencing.
Client decisions. Selections, colour choices and variation approvals are tasks with owners outside your business, and they are the most under-scheduled items in residential building. A selection that has to be made eight weeks before the tiler arrives should be on the programme with that date attached, because chasing it in the week it is needed is how a job loses a fortnight.
Inspections and approvals. Mandatory inspections, certifier attendance and occupation certification are hard gates that do not care how ready the site is, and they involve a third party’s calendar. Weather is the fifth, and in most of Australia it is seasonal and predictable enough to plan around, which is a different discipline from recording the days actually lost. Both are covered in weather and construction productivity and inclement weather and extensions of time.
04 / Before you buy
Six things to look for
The first is testable in ninety seconds and eliminates most of the field. The third and fourth decide whether the programme is still true in month three.
Real dependencies, not just a Gantt chart look
A bar chart can be drawn with fixed dates and no logic at all. Test it by moving one early task by a week and watching what happens. If nothing downstream moves, you have bought a drawing of a programme rather than a programme.
A baseline you can keep and compare against
Ask whether the original programme is saved when the job starts, whether you can take further baselines at contract variations, and what report shows planned against actual. This is the difference between managing a job and describing it after the fact.
Something a trade can act on without logging in
The programme only works if the people doing the work know their dates. Subcontractors will not adopt your software, so the question is what reaches them, a text with their dates, an email, a link, and whether their reply comes back to the task or to somebody’s phone.
Site updates that take seconds
A supervisor with a phone, one hand free and no reception has about ten seconds of patience. Judge the field experience on that basis. A programme is only as current as its worst update path, and the office is never the worst update path.
Procurement and lead times inside the programme
Order-by dates, delivery dates and long lead items belong on the same programme as the trade tasks, because they are the tasks that most often move handover. Ask whether purchase orders and the schedule know about each other or live in different products.
A view your client can be given
Most of the calls a builder takes about a programme are from the owner asking what is happening. A client-appropriate view, with the right level of detail and no internal notes, removes more phone calls than any internal feature. Ask to see exactly what the client sees.
05 / The failure mode
Every programme has a maintenance cost, and nobody budgets for it
The most common outcome of buying scheduling software is not a bad programme. It is an abandoned one. The pattern is consistent enough to plan around. A detailed programme is built with enthusiasm at job start. Three weeks in, a fortnight arrives where two trades move, a delivery is late and it rains. Updating the programme properly takes an hour that does not exist, so it is skipped. Once a programme is a fortnight stale, nobody consults it, and once nobody consults it there is no reason left to update it.
The instinctive response is to blame discipline, and the useful response is to lower the cost of an update. Three things do that. Let the update come from the site rather than the office, because the person who knows the frame finished on Thursday is standing in front of it. Let dependency logic carry one change through the rest of the programme, so a delay is one action rather than forty. And build the programme at the level of detail you will actually maintain, which for most residential builders is trade-level phases rather than two hundred tasks.
There is a judgement underneath this that is worth stating plainly. A rough programme that is current beats a detailed programme that is fictional, every time. The detailed one still produces confident reports, which is what makes it dangerous. When you are evaluating products, weight the cost of keeping the thing true far above the sophistication of what it can represent, and see baseline and progress tracking for how to keep slip measurable once it is.
06 / The conversation
Questions worth asking a provider
Six questions with specific answers. The first one is a demonstration rather than a question, and it separates the category faster than anything else you can ask.
- 01
Move one task and show me the whole programme respond
The single most diagnostic demonstration in this category. Push an early task out by a week, live, and watch what happens downstream, to the trade bookings, to the handover date and to whoever gets notified. Any hesitation here means the dependencies are decorative.
- 02
How does a subcontractor find out their date changed
Ask for the actual mechanism, and then ask what happens when the trade replies. A system where changes are broadcast but responses arrive as personal text messages has moved the coordination problem rather than solved it. Then ask what a trade sees on a phone with poor reception.
- 03
What does my supervisor do each afternoon
Get the routine described in steps and minutes, not features. Then ask what the programme looks like on a Friday when nobody has updated it since Tuesday. A tool that degrades into a stale but honest picture is far more useful than one that silently keeps showing the original plan.
- 04
Where do the first dates come from on a new job
Building a programme from scratch is the reason most builders abandon scheduling software in month two. Ask whether templates exist, whether a previous job can be copied and re-dated, and whether the estimate scope can seed the task list. The setup cost decides whether it survives.
- 05
How does the programme treat weather and inspections
Ask specifically about non-working days, wet weather, mandatory inspections and certifier attendance, and whether a delay can be recorded with a reason. That record is what supports an extension of time claim later, and reconstructing it from memory months afterwards is close to impossible.
- 06
What is the total cost including the people who only need to look
Supervisors, trades, clients and estimators use a programme very differently, and per-user pricing that charges full rate for read-only access changes the total sharply. Ask what a view-only participant costs, because that decides whether the schedule is shared or hoarded.
07 / Honest limits
What scheduling software cannot do
Four limits, and the first is the one that decides how much of your delay problem software can actually touch.
It cannot make a trade turn up. The programme is a plan for other businesses, and on most residential jobs the binding constraint is trade availability rather than logic. Better scheduling improves your position in the queue by giving trades earlier and more reliable notice, which is a real gain, and it is not the same as control.
It cannot supply the sequencing judgement. Knowing what has to cure before what, which trades cannot share a site, and where you can safely overlap is knowledge about building, and the software will happily represent an impossible sequence with perfect arithmetic.
It cannot fix an unrealistic duration. A programme built from the durations you wish were true will report that the job is on track right up until the week it obviously is not, and the baseline will then show, accurately, that the plan was wrong from the start.
And it cannot decide what to do about a delay. Whether to accelerate, re-sequence, claim an extension of time or tell the client is a question about cost, contract and relationships. What the software gives you is the consequence made visible on the day it happens instead of a fortnight later, which is usually the difference between a decision and an explanation.
08 / How VIABUILD does it
A programme the trades actually answer
Scheduling in VIABUILD is one module of the Construction Operating System for residential builders, on the same data model as procurement, cost control and claims. Tasks carry real dependencies and milestones, so moving one task moves the work that depends on it, and a saved baseline keeps the original plan visible so slip is measured rather than absorbed into the current view.
The part builders notice first is the communication. Trades receive their dates and confirm with one tap, and when they reply by text the message lands against the task rather than in somebody’s phone, threaded through your own number. That is the difference between a programme the office maintains and a programme the job runs on. Site updates come from ViaSite on a phone, which is the only update path that survives a busy week.
Oryn™ can draft a first programme from the estimate scope, phases, tasks, durations and dependencies, which removes the blank page that stops most builders in week one. The dates themselves are anchored deterministically rather than generated, and the draft is a starting point to own rather than a plan to trust unread. What we do not claim. Oryn does not decide your sequencing, does not know which trades you can get next month, and does not reschedule the job on its own. Full detail is on construction scheduling, and the module is set out for a specific city on the Brisbane, Melbourne, Sydney, Adelaide and Perth pages.
09 / FAQ
Common questions.
Construction scheduling software builds and maintains the programme for a job, the tasks, their durations, the order they have to happen in and who is doing each one. What separates it from a shared task list is dependency logic. Tasks are linked, so when one moves the ones that follow it move too, and the software can show which of them affect the finish date and which have slack. Around that core, a construction-specific product usually adds trade allocation and notification, procurement and lead time tasks, non-working days for weather and holidays, a saved baseline to measure slip against, and a way for the site to record what actually happened. Construction project scheduling software and construction programme software describe the same category.
The critical path is the chain of tasks where any delay pushes the finish date, as distinct from tasks that can slip without consequence. It matters on a house exactly as much as on a tower, it is just shorter and easier to hold in your head, which is why builders often manage it informally and successfully for years. The point at which the informal version breaks is concurrency. Running one job, an experienced builder knows the frame matters and the letterbox does not. Running seven jobs with shared trades, the interactions stop being intuitive, because a delay on job three is now competing for the same bricklayer as job five. That is where explicit dependencies earn their keep. The mechanics are covered in the critical path reference.
Because a programme has a maintenance cost that almost nobody budgets for, and the cost is paid by the busiest person in the business. Every schedule is built with enthusiasm at job start and then meets a fortnight where three trades move, a delivery is late and it rains. Updating it takes an hour that does not exist, so it is skipped, and once a programme is a fortnight stale it stops being consulted, which removes the last reason to update it. The practical fixes are all about lowering the cost of an update rather than increasing discipline. Let the site update from a phone in seconds rather than the office updating from notes. Let dependencies move the downstream work automatically so one change is one action. And accept a rougher programme that is current over a detailed one that is fictional. A schedule that is honest about being three days behind is more useful than one that is beautifully wrong.
Two ways, and both matter. Prospectively, by allowing for the wet season or the seasonal pattern in the region you are building in, which is the difference between a plan that survives February in South East Queensland and one that does not. Retrospectively, by recording the days actually lost, with a reason, at the time. The second is the part builders most often skip and most often need, because an extension of time claim rests on a contemporaneous record rather than a recollection, and the same record is what makes a conversation with a client about a moved handover date a factual one. Different trades are affected differently, which is why wet weather is not a single lost day but a re-sequencing problem, and the detail sits in the weather and sequencing references.
Scheduling is one module of project management, and the distinction is worth keeping because the products differ. A scheduling tool answers when, and holds the tasks, the logic and the dates. A construction project management platform holds the schedule alongside the budget, the purchase orders, the documents, the claims and the site record, and its value is in those things sharing one data model. A dedicated scheduler will usually out-schedule the scheduling module of a suite on depth of logic. A suite will usually beat the dedicated scheduler on whether the programme knows about the purchase order for the windows. Which matters more depends on whether your jobs slip because of sequencing or because of procurement, and for most residential builders it is procurement.
Four things. It cannot make a trade turn up. The programme is a plan for the behaviour of other businesses, and the constraint on most residential jobs is trade availability rather than logic. It cannot supply the sequencing judgement, which is knowledge about how this house goes together, what has to cure before what, and which trades cannot share a site. It cannot fix an unrealistic duration. Any programme built from optimistic durations will report cheerfully that the job is on track until the week it is not. And it cannot decide what to do about a delay, which is a question about cost, the client, the contract and the trades you can actually get. Software makes the consequences of a delay visible immediately instead of a fortnight later, which is genuinely valuable, and it is not the same as controlling the delay.
Scheduling in VIABUILD is one module of the Construction Operating System for residential builders, on the same data model as procurement, cost control and claims. Tasks carry real dependencies and milestones, so moving one task moves the work that depends on it, and a saved baseline keeps the original plan visible so slip is measurable rather than absorbed. Because the modules share one data model, the programme knows about the job it belongs to rather than being a separate chart maintained beside it. The part most builders notice first is the communication. Trades receive their dates and confirm with one tap, and their text replies land against the task instead of in somebody’s phone, threaded through your own number. Oryn can draft a first programme from the estimate scope, with phases, tasks, durations and dependencies, and the dates themselves are anchored deterministically rather than generated. That draft is a starting point for a builder to own, not a plan to trust unread. Full detail is on the scheduling feature page.
10 / Keep reading
Keep reading on programme and delivery
The references behind dependencies, lead times, baselines and weather, the working guide, and the other category guides.
A programme that is still true in month three.
VIABUILD holds real dependencies and a baseline, sends trades their dates for one-tap confirmation, and files their text replies against the task. One module of the operating system, on the same data as procurement and cost control.