What a construction schedule is
A construction schedule is the time-based programming of every activity in a build. Each activity has a duration, a start date and a finish date, and it relates to others through dependencies: you can't pour the slab before tying the rebar, or paint before plastering. The schedule takes that set of constraints and turns it into a calendar with a finish date you can commit to.
It serves two purposes worth keeping separate. As a planning tool it tells you when the project finishes, when each crew comes on, when each material has to arrive and when each work front is released. As a control tool it gives you something to compare against: without a baseline schedule, "we're behind" is a feeling; with one, it's a number you can measure and correct.
The schedule doesn't come out of nowhere — it rests on the budget. The line items and work items you already priced are, to a large extent, the activities you're going to schedule, and the work quantity of each item is the input for estimating its duration. That's why a good schedule starts with a well-quantified budget: if the takeoff is wrong, the durations come out wrong too.
- Activity description and unit, tied to the budget work item.
- Work quantity to be executed (the volume of work).
- Estimated duration and calendar in working days, not calendar days.
- Predecessors and successors: what comes before and what comes after.
- Owner or crew assigned to the activity.
Program of works and schedule: what sets them apart
In everyday use "program of works," "programming" and "schedule" are treated almost as synonyms and, in practice, refer to the same thing: the project's time plan. The word "program" carries a more formal sense — in public works, the program of works is a contract document — while "schedule" puts the emphasis on the timeline. For the purposes of this guide we treat them as equivalent.
What is worth distinguishing is the program of works from its derived programs. From a single schedule come the material-supply program, the plant-and-equipment utilization program and the labor program: they all hang off the same dates, but each answers a different question — what to buy and when, what equipment to mobilize, how many people to hire per week. Scheduling a project well is, at bottom, scheduling those resources well around a single timeline.
Step by step to build the schedule
The process has a logical order and that order matters: scheduling durations before defining dependencies is the most common cause of unrealistic schedules. These five steps take you from a list of work items to a Gantt chart you can actually manage.
- 1List the activities
Break the project down into activities from the work-item catalog and the budget line items: site prep, foundations, structure, masonry, MEP installations, finishes and cleanup. The level of detail is a balance: too coarse ("structure: 60 days") is useless for assigning owners or measuring progress; too fine (a bar per column) makes the schedule unmanageable. A good rule is that each activity should have a clear owner and a duration of somewhere between a few days and a couple of weeks.
- 2Define the dependencies
Establish what must happen before each activity. The most common relationship is finish-to-start (one finishes so the next can begin), but it is not the only one: some activities start together or overlap. This is where the real sequence of the project is decided, and where the builder's judgment weighs more than any software.
- 3Estimate the duration of each activity
Duration comes from the work quantity divided by the output rate of the assigned crew, not from a round number. 300 m² of plaster with a crew that produces 30 m²/day takes 10 working days; then adjust for working days, weather, shifts and the learning curve at startup.
- 4Sequence over time and calculate the critical path
With dependencies and durations set, place each activity on the calendar. Walk the network forward to get the earliest dates and backward to get the latest; the difference is the float, and the chain of zero float is the critical path that sets the finish date.
- 5Draw the Gantt chart and set the baseline
Represent each activity as a bar along the timeline, with its links and the critical path highlighted. Before you start, freeze that version as the baseline: it is the reference you will measure all progress against. Without a baseline there is no control, just a drawing.
Types of dependencies between activities
A dependency is the rule that says which activity conditions which, and there are four types. Finish-to-start (FS) is the classic one: the successor does not begin until the predecessor finishes — pour the slab after tying the rebar. Start-to-start (SS) forces two activities to begin at the same time or with a set offset. Finish-to-finish (FF) ties the endings: the fine cleanup finishes when the finish work finishes. Start-to-finish (SF) is rare and almost never used on site.
To those relationships you can add a lead or a lag. The most honest lag in construction is cure time: between "pour the slab" and "start stripping the formwork" there is a curing lag that consumes no labor but does consume calendar. Modeling that lag as part of the dependency — and not as a dummy activity — keeps the schedule clean and realistic.
Defining dependencies well is what separates a Gantt of loose bars from a network that reacts. When the relationships are captured, moving one activity automatically recalculates everything that depends on it and reveals the domino effect of a delay. When they are not, the Gantt looks tidy but lies: each bar floats on its own and a slip in foundations pushes nothing.
How to estimate the duration of each activity
Duration is the most manipulated and worst-supported input in a schedule. The right way to estimate it is arithmetic: duration = work quantity ÷ crew output rate. If you have 240 m³ of excavation and a crew with an excavator that produces 80 m³/day, that's 3 days. You don't make up the output rate: it comes from your own experience recorded on past projects or from industry reference tables, adjusted to your real conditions.
On top of that base number come the adjustments the arithmetic does not see. Working days: a calendar month is not 30 working days, but what is left after taking out Sundays, holidays and, in many regions, the rainy season. Weather: pours and earthworks stop with rain. Shifts: doubling the shift does not always double the output, because of fatigue and working space. And the learning curve: the first repetitions of a task produce less than the ones that follow.
A frequent mistake is to schedule with catalog output rates, which tend to be optimistic, instead of the real rates of your own crews. Another is not distinguishing between duration and effort: a 40-labor-day activity can take 10 days with 4 people or 5 days with 8, but only up to a point — there comes a moment when more people on the same front get in each other's way. Scheduling is, to a large extent, deciding that balance crew by crew.
The critical path and float
The critical path is the sequence of linked activities that adds up to the longest duration from the start to the finish of the project. These activities have zero float: any delay in one of them pushes back the completion date of the whole project. It is, literally, the chain that defines how long the project takes; shortening it is the only way to finish sooner.
Float is the margin an activity has to move without affecting the project. It is calculated by walking the network twice: forward you get the earliest start and finish dates; backward, the latest ones. The difference between the late date and the early date is the total float. Activities with float can slip or move up within that margin; those with zero float cannot — they are the critical ones.
Knowing the critical path tells you where to put your attention. If you're going to watch, accelerate or protect something, that's where it is; adding more people to an activity with float doesn't move the project forward a single day. It's also worth remembering that the critical path is not fixed: as the project advances and float is consumed, a chain that wasn't critical can become critical. That's why it is recalculated at each cutoff, not only during planning.
- Total float: how much an activity can slip without moving the finish date.
- Free float: how much it can slip without affecting the earliest start of its successor.
- Critical activity: zero float; it is part of the critical path.
The Gantt chart, the baseline and milestones
The Gantt chart is the graphic representation of the schedule: the horizontal axis is time and each activity is a bar whose length is its duration. Dependencies are drawn as lines connecting the end of one bar to the start of the next, and the critical path is usually highlighted in another color so it stands out. It's the view you review with the client and the one you use on site to know what each week calls for.
The baseline is the snapshot of the approved Gantt before you start. Freezing it is what turns the schedule into a control tool: without a fixed reference, every week you redraw the plan so it "matches" reality and there is never a delay, because the plan always adjusts. With a baseline, the scheduled bar stays put and the actual-progress bar gives it away.
Milestones are zero-duration markers that flag key events: "foundations complete," "structure 100%," "handover." They consume no time but they organize how the schedule reads and often coincide with billing or contractual review points. A schedule with well-placed milestones communicates far better than one of a hundred bars with no hierarchy.
You control the project on that same Gantt: you draw a progress bar inside each activity to show the percentage completed and a status line at the cutoff date. The activities left of that line that aren't finished are the ones running behind; if they are also critical, the delivery date has already moved.
Worked example: schedule for a single-family house
Let's run the full method on a hypothetical project: a single-story house of about 120 m². The quantities, durations and dollar weights that follow are an illustrative example to explain the procedure; they are not output rates or market prices and will change with your area, your project and your crews.
The activities and their quantities come from the budget. Take the plastering: if the project has 300 m² and the crew produces 30 m²/day, the base duration is 10 working days; with an adjustment for lost days we schedule it at 12. Repeating the exercise item by item gives a duration for each activity, which in this example would look like this (in working days):
- Site prep and layout — 3 days.
- Excavation and foundations — 12 days (starts when site prep finishes).
- Structure: columns, tie beams and slab — 20 days (starts when foundations finish).
- Walls and masonry — 18 days (after the slab has cured).
- Plumbing, drainage and electrical installations — 15 days (overlapped with the masonry).
- Plastering — 12 days.
- Finishes: flooring, paint and carpentry — 20 days.
- Cleanup and handover — 3 days.
From the example: the critical path and why it costs money
Chaining the activities that can't be overlapped — site prep, foundations, structure, walls, plastering, finishes and cleanup — the critical path of this example adds up to about 88 working days, that is, roughly 18 weeks or a little over four months, not counting the slab's cure time. The installations, running overlapped with the masonry, have float: they can move a few days without moving the handover. Adding a contingency buffer for weather and surprises, the realistic commitment would land around five months.
That calculation has an economic effect, and this is where the critical path stops being theory. Suppose, always illustratively, a contract of $480,000 and liquidated damages of 0.5% of the amount for each week of delay: every week lost on the critical path would cost $2,400. Delaying the installations by a week costs nothing while there is float; delaying the structure by a week pushes everything behind it and triggers the penalty.
That, in money, is the reason to watch the critical path and not the bars with float. The same one-week delay is worth zero dollars on one activity and twenty-four hundred on another, and the only difference is whether or not it touches the critical chain. A schedule serves, precisely, to know in advance which is which. To be clear: the figures above are an example to illustrate the reasoning, not a market data point.
Control: physical progress against plan and the S-curve
The schedule doesn't end when the project starts; that's where its most important use begins. At each cutoff — weekly or biweekly — you record the actual physical progress of each activity (how much of its work quantity was executed) and compare it against the progress scheduled for that same date under the baseline. Measuring physical progress by quantity executed, and not by eye, is what makes the comparison reliable.
The difference between actual progress and scheduled progress is the variance. If by today you should be at 60% of the structure and you're at 45%, there's a 15-point delay; whether that delay matters or not depends on whether the activity is critical. A slip on the critical path moves the handover; one on an activity with float does not — as long as you don't eat up all the float. Catching it at the cutoff, and not at the end, is what lets you reschedule, reinforce crews or negotiate in time.
The clearest way to see all of this together is the S-curve: the graph of cumulative progress (in percentage or in money) against time. It's called that because the project advances slowly at the start, accelerates in the middle and slows again at the close, drawing an S. On the same graph you plot two curves — the scheduled one and the actual one — and the gap between them is the variance at a glance: if the actual curve runs below the scheduled one, you're behind. It's the same control logic you apply to the budget against actual cost.
How to recover a delayed schedule
When the cutoff shows the critical path is behind, there are two levers to recover time, and it's worth knowing them because neither is free. The first is to overlap activities that were in series (fast-tracking): start the next one before finishing the previous one — for example, begin installations in the already-built area while the rest goes up. It compresses the calendar without overspending, but it increases the risk of rework and interference between crews.
The second lever is to load more resources onto the critical activities (crashing): more people, more shifts, more equipment. It shortens the duration, but it costs money and has diminishing returns — doubling the crew rarely doubles the output — and it only works on the critical path: accelerating an activity with float spends without moving the project forward. The decision is usually a mix of both, applied carefully to the critical activities.
Before accelerating, it's worth exhausting the cheap options: check whether the sequence can be reordered, whether there are fronts stalled for lack of material or design definition, and whether the delay comes from a cause that will repeat. Often the schedule isn't recovered by adding people, but by unblocking the decision, the supply or the permit that had the front stopped. Accelerating over an unresolved cause only burns money.
Variations by project type
Not every schedule is built the same way. In single-family housing or remodeling, the programming is relatively linear and fits in a simple Gantt; the risk usually lies in supply and in client changes more than in the complexity of the dependency network.
In vertical building and repetitive work — a multi-story building, a subdivision — cyclical work appears: the same sequence (structure, masonry, installations, finishes) repeats floor by floor or house by house, advancing like a train of crews. Here rhythmic scheduling, with lines of balance, usually reads better than a giant Gantt, and the goal is that no crew is ever left without a front.
In industrial or infrastructure work, the weight shifts to long-lead fabricated supplies and to logistics; the critical path often runs through a piece of equipment with months of delivery, not through a field activity. And in public works the programming takes on a contractual character: the program stops being an internal document and becomes one with legal and economic effects, which is what we look at next.
The program of works in public construction
In private work the schedule is, above all, a management tool: its form is decided by the contract between the parties. In public or government-funded work things change, because the procurement is governed by public-works regulations that typically require the contractor to submit a program of works as part of the bid and the contract.
From that general program come quantified programs: the material-supply program, the plant-and-equipment utilization program and the labor program. They are not paperwork: they are the baseline against which the owner measures progress, approves payment applications and calculates retentions or liquidated damages when the work falls behind the agreed program. In that context, a badly built schedule doesn't just disorganize the project: it can cost money in retentions.
That's why, in public work, keeping the program current and documenting the causes of any slippage in the project log is part of the job, not an extra. Changes to the program usually require formalization — change orders, time extensions — and the committed delivery date is the one in the approved program. It's best to treat the regulations in general terms and consult the current version of the applicable public-works law and its rules for the detail, since their provisions get updated.
How the schedule connects with the rest of the project
The schedule does not live in isolation: it is the "time" dimension of a system where the budget is the "cost" dimension. The activities you schedule are, to a large extent, the line items you costed, and the work quantity of each item feeds both the amount (quantity × unit price) and the duration (quantity ÷ output rate). A change in the takeoff moves both at once.
Downstream, the schedule orders the cash flow and the payment applications. The S-curve of scheduled progress, valued in dollars, is practically the calendar of receivables and payables: it tells you how much you'll bill and how much you'll spend each month. Periodic payment applications are built on the physical progress you measure against the schedule, and the project log is where you document the events that explain the slippage — rain, missing material, design changes.
Seen this way, the schedule is the thread that connects planning and control: it is born from the budget, directs the execution, feeds the payment applications and closes by comparing actual against scheduled. Neglecting it breaks the chain; keeping it alive is what lets you see the whole project — time, cost and progress — on a single dashboard.
The most common scheduling mistakes
These are the mistakes that cause the most delays and penalties, and almost all of them come from treating the schedule as a startup formality and not as a living tool:
- Estimating durations by eye, without starting from the work quantity and the crew's real output rate.
- Not defining dependencies: a Gantt of loose bars reveals neither the critical path nor the domino effect of a delay.
- Ignoring the critical path and accelerating activities with float, which don't move the project forward.
- Scheduling with calendar days instead of working days, and leaving no margin for weather, material deliveries and contingencies.
- Not setting a baseline, so the plan is redrawn every week and the delay never shows up.
- Building the schedule once and not controlling it: not comparing physical progress against the plan at each cutoff or recalculating the critical path.