Key takeaways
- The Question: How is a construction schedule put together, how is it run during the job, and why does it so often stop matching what is happening on site?
- The Answer: A schedule is built by breaking the scope into measurable activities, giving each a duration based on quantities and output rates, linking them with logic, calculating the critical path and float, and freezing the result as a baseline. It stays useful only if it is updated with real site status and re-planned when the logic changes.
- The YelloSKYE Angle: A programme is only as good as the progress fed into it. Construct IQ gives planners dated imagery of the site, captured by drone, fixed camera and 360° camera, so activity status can be checked against what is physically in place.
Construction scheduling is the process of converting a project's scope into a sequence of activities with durations, dependencies, resources and milestones, then using that model to coordinate the work and forecast the finish date. A good schedule answers three questions at any point in the job: what should be happening now, what must happen next, and which activities decide when the project will be complete.
This guide is written for project managers and planners. It walks through how a programme is built, from work breakdown to baseline, with a small worked critical path example, the levels of detail different audiences need, and the reasons a schedule drifts away from the site. Keeping the programme anchored to physical progress is the part Construct IQ, YelloSKYE's monitoring solution for construction sites, is designed to support.
What a schedule is for
People often treat the programme as a contract document to be produced at tender and defended later. It does much more than that, and a planner who keeps all of its jobs in mind builds a better one.
| Purpose | Who relies on it | What it needs from the schedule |
|---|---|---|
| Coordinating trades | Site managers, foremen, subcontractors | A clear sequence and realistic start dates by area |
| Procurement | Commercial team, suppliers | Required-on-site dates for materials and plant, worked back to order dates |
| Cash flow | Owner, contractor finance | A spend profile tied to activities, not to calendar months |
| Contract baseline | Owner, project manager, claims advisers | A frozen, logic-linked version to measure delay against |
| Forecasting | Leadership, lenders, end users | A credible completion date that moves when the site does |
| Communication | Everyone | Summary views that people outside the planning team can read |
A schedule that serves only one of these purposes tends to fail the others. A tender programme drawn to impress, for instance, rarely has the logic needed to calculate delay later.
Building the schedule, step by step
Most planning software follows the critical path method, developed in the late 1950s by engineers at DuPont and Remington Rand. The steps below apply whichever tool you use.
1. Break the scope into a work breakdown structure
The work breakdown structure (WBS) divides the project into deliverables and then into smaller packages: site, substructure, frame, envelope, services, finishes, external works. A useful WBS also follows location, such as building, level and zone, because site teams think in places, not in cost codes. Agree the WBS with the estimating and commercial teams early so cost and time can be compared on the same structure later.
2. Define activities that can be checked
An activity is a piece of work with a clear start, a clear finish and one responsible party. "Level 3 east: install partition framing" is an activity; "Level 3 internals" is a summary. The test is simple: could someone walk onto the floor, or look at a photograph, and say whether this activity has started and whether it has finished? If not, split it until they can.
3. Estimate durations from quantities and rates
Durations should come from the quantity of work divided by a realistic output rate for the crew size you expect, not from a feel for how long things usually take. Two hundred tonnes of steel at an assumed rate per crew-day gives a number you can defend and later test against what the site achieves. Record the assumptions next to the activity; when the duration is challenged, the assumption is what you discuss.
4. Link the logic
Each activity needs at least one predecessor and one successor, apart from the start and finish milestones. Four relationship types are available:
- Finish to start: the next activity starts once this one finishes. The default and the easiest to read.
- Start to start: the next activity can start once this one has started, often with a lag, for example boarding beginning two days after framing starts on the same floor.
- Finish to finish: the two activities finish together or with a set gap.
- Start to finish: rarely needed and best avoided.
Avoid hard constraints such as "must start on" dates unless a real external date exists, for instance a road closure permit. Constraints override the logic and hide the true critical path.
5. Calculate the critical path and float
The software runs a forward pass to find the earliest start and finish of every activity, then a backward pass from the finish date to find the latest dates each can occur without delaying completion. The difference is the float. Activities with zero total float form the critical path.
6. Load resources and test feasibility
A logically correct schedule can still ask for three tower cranes on a site with room for one. Assign the main resources, such as crews, cranes and hoists, and check the peaks. Where demand exceeds what the site can hold, either move work within its float or change the logic.
7. Review, agree and baseline
Walk the programme with the people who will build it. Foremen spot missing activities and unrealistic sequences that look fine on screen. Once agreed, save a baseline copy that is never edited. Every later update is measured against it.
A worked critical path example
Here is a simplified sequence for a small steel-framed building, with durations in working days and finish-to-start links.
| Activity | Duration | Predecessors | Early start | Early finish | Late start | Late finish | Total float |
|---|---|---|---|---|---|---|---|
| A. Site set-up | 5 | None | 0 | 5 | 0 | 5 | 0 |
| B. Foundations | 15 | A | 5 | 20 | 5 | 20 | 0 |
| C. Steel frame | 20 | B | 20 | 40 | 20 | 40 | 0 |
| D. Roof deck | 10 | C | 40 | 50 | 40 | 50 | 0 |
| E. Cladding | 25 | C | 40 | 65 | 55 | 80 | 15 |
| F. Ground floor slab | 8 | B | 20 | 28 | 42 | 50 | 22 |
| G. Services rough-in | 30 | D, F | 50 | 80 | 50 | 80 | 0 |
| H. Internal finishes | 20 | E, G | 80 | 100 | 80 | 100 | 0 |
The project takes 100 working days, and the critical path runs A, B, C, D, G, H. The roof deck matters more than the cladding because services cannot start inside until the building is covered, and services are the longest single activity. Cladding has 15 days of float and the ground floor slab has 22.
Two lessons follow from even this small example. First, the critical path is not always the work that looks most important on site: a slow roof deck delays the job, while a slow envelope does not, at least until its float is used up. Second, float is shared. If the slab crew uses all 22 days, the slab joins the critical path and any further slip moves completion.
Schedule levels: one model, several views
Different audiences need different amounts of detail. AACE International describes five commonly used levels, and most large projects use something similar.
| Level | Typical content | Main audience | Update rhythm |
|---|---|---|---|
| 1 | Key milestones and major phases on one page | Owner board, lenders | Monthly |
| 2 | Phases by area or facility, with main interfaces | Executives, owner's representative | Monthly |
| 3 | The full logic-linked contract programme | Project manager, planner, owner's project manager | Weekly to monthly |
| 4 | Detailed activities by area and trade | Site managers, package managers | Weekly |
| 5 | Short-term task lists for a few weeks | Foremen and crews | Daily to weekly |
The rule that keeps these honest is that every level rolls up from the same logic. When the board sees a Level 1 milestone holding while the Level 4 programme shows the trades behind, the levels have been maintained separately, and trust in all of them falls.
Float: who owns it and how to spend it
Float is time, and time has value, so contracts increasingly say who may use it. Some allocate it to the project, meaning whoever needs it first can use it; others reserve it for the contractor or the owner. Know which applies before you rely on it.
In practice, three habits protect float. Do not hide contingency inside activity durations, where nobody can see it being consumed; show it as an explicit buffer before key milestones instead. Watch the near-critical paths, those with only a few days of float, because they become critical quickly. And track how much float the project has lost each period, since a steady decline is often the earliest sign of trouble.
Why the programme drifts from the site
According to Reinventing Construction, published by the McKinsey Global Institute in 2017, large projects usually finish about 20 per cent later than their schedules allow. Very little of that drift arrives as one dramatic event. Our guide to construction delay statistics looks at the wider research; from the planner's seat, the causes usually look like this.
| Cause | How it shows up | What helps |
|---|---|---|
| Optimistic durations | Activities routinely overrun by similar amounts | Base durations on measured output rates from the site and earlier projects |
| Missing or wrong logic | Work starts that the programme says cannot | Review logic with foremen and fix it at each update |
| Out-of-sequence progress | Trades jump ahead in some areas and leave gaps in others | Record actual sequence and re-plan the remaining work |
| Status based on opinion | Activities shown as 90 per cent complete for weeks | Define completion so it can be seen and check it against evidence |
| Infrequent updates | Slippage discovered a month after it started | Shorter update cycle on critical areas |
| No re-planning | The baseline is patched instead of re-sequenced | Re-plan the remaining work when the logic no longer reflects the site |
The common thread is that the programme is only refreshed with what people report. A foreman who is behind has little reason to say so early, and a planner working from a desk cannot easily check. The gap between as-reported and as-built is covered in our guide to as-built vs as-planned.
Keeping the schedule tied to physical progress
The schedule does not need more effort at the planning stage so much as better information during the job. Three practices make the biggest difference.
Status from evidence, not memory
When every activity has an observable start and finish, status can be checked from dated images instead of collected in a meeting. Construct IQ captures the site with drones, 360° cameras and fixed cameras, and the DEX platform's Progress vs. Plan overlay compares what has been built with the planned 4D schedule. On our construction progress capture projects, flying the site once a week saved each site manager over 15 hours of weekly reporting.
Seeing work stop as well as start
A programme marks activities started and finished, but it rarely notices when an area goes quiet in between. Fixed cameras watch chosen zones continuously in the gaps between drone captures, and DEX sends a notification if a high-priority zone falls idle or a milestone is reached. Teams using fixed-camera monitoring have cut physical site visits by as much as 80 per cent.
A shared record for disputes
When the programme becomes the basis for a payment claim or a delay claim, both sides need to agree what was built when. DEX's Time Travel Playback steps back through the site day by day, and the contractor billing disputes use case shows how dated aerial records support progress payment claims.
YelloSKYE does not write or run your schedule; your planning software does that. Its role is to provide the physical record that checks the status fed into the schedule, and progress reports can be exported to Procore, Autodesk and MS Project.
A practical scheduling checklist
- Build the WBS by location as well as by package, and agree it with the commercial team.
- Make every activity small enough that its start and finish can be seen on site or in a photograph.
- Derive durations from quantities and output rates, and write the assumptions down.
- Give every activity a predecessor and successor; remove constraints that have no real external cause.
- Check resource peaks against what the site can physically hold.
- Walk the draft programme with foremen before baselining it.
- Hold contingency as visible buffers, not inside activity durations.
- Track lost float and near-critical paths at every update, not only the critical path.
- Status activities from dated site evidence and re-plan when the sequence on site no longer matches the logic.
