The Critical Path Plans the Job: Using Networks Before the Site Starts

Every construction project, wherever it is built, is a web of dependent activities. Foundations must be cast before the frame can rise; the frame must be weathertight before finishes begin; services must be tested before ceilings close. Some of those activities can slip by days or weeks without anyone noticing at completion. Others cannot slip by a single day without the whole job finishing late. The difference between the two is rarely obvious from a list of tasks or a bar chart drawn by eye. It becomes visible only when the logic of the job is set out as a network and analysed.

Critical-path analysis is the technique that makes that distinction explicit, and it does its most valuable work before the site starts. It shows the project team where delay is unforgiving, where there is room to manoeuvre, and where resources are likely to be stretched.

This comprehensive blog will explore why network planning became an ordinary part of construction, how a network is built from a chosen level of detail through activity logic to durations, how forward and backward passes reveal the critical path, how uncertain durations, limited resources, lags and repetitive work are handled, and why a programme later becomes a baseline against which progress and delay are judged. Whether you are a planner, project manager, contractor or client adviser, understanding why the critical path plans the job is key to starting the site with a programme that can be explained rather than merely displayed.

1. Why Networks Became Ordinary in Construction

Construction has always been planned in some form, but formal project management, with its networks, critical paths and specialised terminology, has a more specific history. It is generally traced to the 1940s and the effort to deliver the Manhattan Project, the wartime programme to develop the first atomic bomb. The management systems used for that work were largely developed by the American military and drew on existing military strategic and operational planning. Much of the vocabulary that project managers still use, including the distinction between a programme and a project, carries traces of that origin.

From that beginning, network techniques spread into engineering and then into construction, until critical-path analysis became the one modern management technique that most construction firms could claim to use. The assessment noted at the outset carried an important qualification: the technique had proved successful in some forms as a planning tool, but its use as a means of controlling operations had generally been disappointing. Both halves of that judgement matter. The first explains why networks became ordinary. The second explains why a network alone does not guarantee that a job finishes on time.

Definitions of project management have always varied. Some describe it broadly as the management of change; others emphasise co-ordination, logistics, or the delivery of defined objectives within constraints of time, cost and quality. For construction and development, the Chartered Institute of Building has published its own definition and a Code of Practice for Project Management in Construction and Development, which became a common reference point for the discipline in the UK. Readers who need the precise wording should consult the current edition of that Code directly.

Two institutional features of construction help explain why planning matters so much. The first is that the project organisation is temporary. It is assembled for one job from several firms, such as designers, contractors, specialists and consultants, and conventionally it has sat outside those constituent firms with a large degree of autonomy. That autonomy has advantages, but it also means that no single firm necessarily feels ownership of the overall plan. A network gives that temporary organisation a shared statement of what must happen, in what order, and by when.

The second feature is the supply chain. Management of the project supply chain was historically regarded as the project manager's responsibility, working together with the main contractor. Many parties contribute activities to the network, and the critical path frequently runs through work carried out by firms other than the one that drew it. A plan that is understood only by its author cannot co-ordinate those contributions.

This is also why the network has value beyond the arithmetic it supports. Drawing the logic forces the parties to state assumptions that would otherwise remain implicit: when a specialist needs access, which design information must be released before procurement can proceed, and which approvals sit outside the project team's control. A disagreement exposed on a network before the site starts is far cheaper to resolve than one discovered when two trades arrive at the same place on the same day. In that sense, the network is as much a communication tool as an analytical one.

For these reasons, networks became an ordinary part of construction practice. They give a temporary, multi-firm organisation a common logic. The caution that accompanied their spread, that they plan better than they control, is the theme that runs through every stage of the method described below.

Figure 1: Better at planning than at control. A network is strongest before the site starts, when it sets out logic, durations and the critical path. Once work is under way, it controls the job only if it is kept current and pitched at the level of the decisions being taken. The figure illustrates the principle, not a measured comparison.

2. Building the Network: Detail, Logic, and Durations

A network is built in a deliberate sequence. The planner first chooses the level of detail, then compiles a list of activities, then decides the logic that links them, then represents that logic as a network diagram, and only then assigns durations. Each step depends on the one before it, and taking them out of order is one of the commonest sources of a programme that looks precise but cannot be trusted.

The level of detail is a decision, not a default. The same project can be described in a handful of broad activities or in many thousands of small ones, and one broad activity may stand for a very large number of fine ones. Neither is right in the abstract. The appropriate level depends on the purpose of the analysis, the time available to prepare it and the benefit that more detail would bring. Within any one network, activities should be of broadly similar weight and logical grouping, so that the diagram does not mix strategic packages with minor tasks. Too coarse a network hides dependencies that matter; too fine a network buries the critical path under detail that nobody can maintain.

The activity list follows. At this stage the order of the list is not especially important, although it helps if it roughly follows the sequence in which the work will be done. What matters is completeness: an activity that is missing from the list will be missing from the logic and from the critical path.

Logic comes next, and it is the heart of the method. The planner decides, for each activity, which others must be completed before it can start. In principle the logic should be decided as though resources were unlimited, so that the network shows the true technical dependencies of the work. In practice it is difficult to set aside known constraints. A planner who knows that only one excavator will be available may find it hard to draw a logic in which several excavation activities start together. The discipline is to recognise resource restrictions as a separate question, to be addressed later, rather than to build them silently into the logic.

The network diagram then represents that logic visually, and many planners find that drawing the diagram and deciding the logic happen together, because the picture clarifies relationships that are hard to see in a table. Two main forms of diagram exist, one showing activities on arrows and the other showing activities on nodes; the differences between them are discussed later.

Durations come last. Logic before duration is the essential order: the network is first a statement of what must precede what, and only then a statement of how long each activity is expected to take. Durations themselves depend on decisions about method, such as the type of plant, the size of gang and the expected output, and those decisions may be revisited once the network has been analysed. A duration is therefore an estimate tied to a method, not a fixed property of the activity.

Consider a planner preparing the programme for a small single-storey building. At a coarse level, the job might be described as site set-up, substructure, frame and envelope, services, finishes, drainage, external works and handover. The planner decides that drainage needs more detail, because its connection to the public sewer depends on an outside party, and splits it into manholes, drain runs, testing and connection. That choice of detail is driven by where the risk lies, not by a desire for a longer list. Only once the logic is agreed, so that testing follows the runs and connection follows testing, does the planner begin to assign durations.

Figure 2: Detail, then logic, then time. The planner chooses a level of detail, lists the activities, decides the logic that links them, draws the network, and only then assigns durations that depend on method, gang and output. Duration comes after logic. The sequence describes the planning discipline, not the steps of any particular software.

3. Forward Pass, Backward Pass, and the Critical Path

Once durations have been assigned, the network can be analysed. Two passes through the network do the work, and together they reveal the critical path.

The forward pass works from the start of the project to its end. The start is taken as time zero, and the analysis establishes, for each event in the network, the earliest time at which it can occur given the logic and the durations of the activities leading to it. Where several activities lead into the same event, the latest of them governs, because the event cannot occur until all of its predecessors are complete. At the end of the forward pass, the earliest finishing time of the project as a whole is known.

The backward pass works in the opposite direction. Starting from the project's finishing time, it establishes, for each event, the latest time at which it can occur without delaying completion. Where several activities follow from the same event, the earliest of their latest start requirements governs, because the event must occur in time for all of them.

The critical path follows from those two passes. It is the chain of activities on which the earliest and latest times leave no spare time at all. Every activity on the critical path must be completed within its estimated duration if the project is to finish on time; any delay to one of them delays completion by the same amount, unless something else changes. That is why delay on the critical path is unforgiving. Activities off the critical path have float: spare time that they can use without affecting the overall completion date. Float is not a uniform quantity, and there are several kinds of float and slack, defined in different ways for different purposes; the details belong to a fuller treatment of network analysis.

The order of the three results matters. The forward pass sets the earliest times. The backward pass sets the latest times. Only then can the critical path, and the float on every other activity, be identified. A programme that marks a critical path without having carried out both passes has merely asserted one.

An interpretation helps to place the critical path in the wider practice of project control. It can be seen as the time equivalent of a cost plan. Just as a cost plan shows where money is committed and where there is room to adjust, the critical path shows where time is committed and where float allows some flexibility. Neither is a guarantee of the outcome. Both are tools for directing attention to where it is most needed.

Consider a planner reviewing a programme for a refurbishment project with three activities running in parallel after the strip-out: the replacement of mechanical services, the repair of windows and the redecoration of a reception area. All three must be finished before handover. The client asks which of them can be allowed to slip if a supplier is late. The planner's answer depends entirely on the two passes. If the services work lies on the critical path, any delay to it delays handover, whatever happens to the other two. If the windows and the reception have float, they can absorb a modest delay without consequence, up to the limit of that float. The planner's question is never simply "is this activity late?" but "is this activity on the critical path, and if not, how much float does it have?" Without the analysis, the answer would be a guess, and a guess is a poor basis for deciding where to spend money on acceleration.

The same analysis also warns against complacency. An activity with float is not an activity that can be ignored. If it slips far enough to consume its float, it becomes critical itself, and the critical path moves. A network is therefore not analysed once and filed; it is re-analysed whenever progress or circumstances change materially.

Figure 3: Earliest, latest, and the path between them. The forward pass sets earliest times from zero; the backward pass sets latest times that still finish on time; the critical path is where the two leave no spare time. A side activity with float can slip within that float without moving completion. The figure illustrates the idea of the two passes and carries no calculated times.

4. Uncertain Durations, Limited Resources, and Other Diagrams

Real networks rarely deal in certain durations. Even the most familiar activities are subject to weather, supply, productivity and the unexpected. Network analysis therefore includes a way of handling uncertainty: rather than offering a single completion date as though it were certain, the planner estimates a confidence interval for the overall project time. That interval expresses a likely range within which completion is expected to fall, and it focuses attention on the activities whose uncertainty contributes most to the range. The statistical method used to produce such an interval is a specialist matter. What matters for planning is the principle: a single date conceals uncertainty, while a range makes it visible and discussable.

Resources are the next constraint. Once the critical path is known, the planner can check what each stage of the job will require by preparing a resource histogram. The histogram aggregates demand for a given resource, such as bricklayers, labourers or a crane, across the activities that need it at each point in time. If every activity starts at its earliest possible time, demand tends to bunch towards the early part of the job, producing peaks that may exceed what is available.

Levelling addresses those peaks. Where there is a limit on the amount of a resource available, activities that have free float can be moved, within that float, so that demand stays within the limit. This is where float does a second job. On the network, float is slack that protects completion; in resource planning, the same float becomes a tool for moving work so that the job can be resourced without overloading it. Levelling does not shorten the critical path, and if there is not enough float to accommodate the resource limit, the planner faces a genuine choice between more resources and a later finish. The algorithms used by planning software to perform levelling vary and are not discussed here.

The form of diagram also matters. In an activity-on-node, or precedence, diagram, activities are shown as boxes rather than arrows. Such diagrams are generally regarded as easier to follow, and they avoid the need for the dummy activities that arrow diagrams sometimes require to express logic correctly. They also make it easier to represent lags: periods that must elapse between activities even though no work is being done. Curing is the classic construction example. Concrete must be left to cure before the next operation can proceed, and a precedence diagram can show that waiting period directly as part of the logic.

Some projects call for a different technique altogether. On repetitive work, such as a medium or large housing estate, many similar units are built in sequence by the same trades. The critical issue there is less the relationship between individual activities on one house than the way a delay by one trade affects every following trade across the whole estate. Line of balance is suited to that kind of work. It presents the progress of each trade across the repeated units visually, so that the planner can see whether trades will run into one another or leave gaps. The construction of such charts and the calculation of trade rates are specialist subjects that deserve their own treatment.

Taken together, these tools extend the basic network without changing its foundation. Confidence intervals make uncertainty visible. Histograms and levelling connect the logic to the resources available. Precedence diagrams and line of balance offer clearer ways of representing particular kinds of work. In each case, the logic of what must precede what remains the starting point.

The choice among these tools is itself a planning decision. A short, complex fit-out with many interfaces may be best served by a precedence network with carefully modelled lags. A long run of near-identical units may be better understood through line of balance, with a network reserved for the non-repetitive elements such as infrastructure and enabling works. A project with highly uncertain early stages, such as ground works on a poorly understood site, may justify a range for completion rather than a single date. The planner's skill lies in matching the representation to the risks of the particular job.

Figure 4: Float is also a resource tool. When activities start at their earliest times, resource demand can peak above the available limit; moving an activity that has free float, within that float, brings demand back within the limit. Levelling uses free float; it does not shorten the critical path by itself. The figure illustrates the principle, not a software output.

5. A Programme Is Also a Baseline, and Feedback Matters

The contrast drawn at the outset, that critical-path analysis has been more successful for planning than for control, deserves to be revisited now that the method has been described. A practical interpretation is that the reasons are usually human rather than technical. A plan that is not updated as work progresses soon describes a job that no longer exists. A plan that is too coarse cannot support the decisions now being taken on site; one that is too fine cannot be maintained. A plan that is understood only by the planner does not guide the many firms whose work makes up the critical path. Control requires a network that is kept current, pitched at the right level and shared.

A programme has a second life as well. When delay later arises, the programme is often the baseline against which the delay is judged, and against which arguments about time are made. How delay is analysed and how entitlement to more time is decided are separate subjects with their own principles. The narrower point is that a programme prepared before the site starts may later be scrutinised closely, so its logic and durations should be capable of explanation.

Feedback is the final element, and it is often the weakest. In construction particularly, there has been little post-project review of either the process or the product. As one memorable observation puts it, "like hedgehogs squashed on the road, the lack of evolutionary feedback in the system means mistakes will be repeated." The image is uncomfortable, but the point is serious. A network that was optimistic about durations, or that missed a dependency, will be repeated on the next project unless someone records what happened and why. Learning from previous projects, together with good risk and change control, has been identified as among the most critical factors for project success.

For planners, the implication is practical. Durations that proved wrong, logic that had to be redrawn, resource limits that bit harder than expected and critical paths that moved during the job are all evidence. Captured systematically, they make the next network more realistic. Left unrecorded, they disappear when the temporary project organisation disbands.

A modest discipline is usually enough to begin. At the close of each project, the planner can compare the original network with what actually happened, note where the critical path ran in practice, and record which durations and dependencies were most at variance with expectation. Those notes need not be elaborate. Their value lies in being available when the next network is drawn, so that the level of detail, the logic and the durations reflect experience rather than optimism.

Conclusion

A critical path is a plan that shows where delay is unforgiving. It is built in a deliberate order: a chosen level of detail, a complete activity list, logic that states what must precede what, a diagram that represents that logic, and only then durations tied to method and resources. A forward pass from time zero sets the earliest times; a backward pass sets the latest times that still finish on time; and the critical path is where the two leave no spare time. Everything else has float, which protects completion and, through levelling, helps the job to be resourced within its limits.

The surrounding tools extend that foundation. A confidence interval makes uncertain durations visible as a range rather than a false certainty. Resource histograms show where demand will peak, and levelling uses free float to bring it within limits. Activity-on-node diagrams avoid dummies and represent lags such as curing directly. Line of balance suits repetitive work such as housing estates. The calculations behind each of these deserve proper study, and the principles matter more than any particular software.

The weakness of the technique lies less in its logic than in its use. Networks have planned well and controlled less well because they are too often prepared once, at the wrong level of detail, and left unexplained to the firms whose work they describe. The remedy is not a more elaborate network but a better maintained one: updated as progress is made, re-analysed when the critical path may have moved, and understood by everyone whose activities lie on it.