Planning, Scheduling & Programming

You cannot schedule what you have not defined, and the tool for defining the whole of the work is the work breakdown structure (WBS). A WBS is a hierarchical decomposition of everything the project must deliver, broken down from the top - the whole building - into progressively smaller, manageable chunks: phases, then packages, then individual tasks small enough to estimate, assign and track. The discipline is simple but transformative: you keep subdividing until each bottom-level item is a piece of work someone can own, size and complete, typically something that takes days or a couple of weeks rather than months.

The great virtue of a WBS is that it makes the invisible visible. A project stated as 'design and build a house' is impossible to plan; the same project decomposed into briefing, concept design, statutory approvals, detailed design, tender, substructure, superstructure, services, finishes, external works and handover - each of those broken down again - becomes a list you can actually reason about. The classic rule is the hundred-percent rule: the WBS should capture one hundred percent of the scope, no more and no less. If work is not in the WBS, it will not be planned, resourced or costed - and forgotten work is where budgets and programmes quietly haemorrhage.

A good WBS is also the backbone of everything downstream. The same breakdown that structures the programme structures the cost plan (Lesson 6.3), the risk register (Lesson 6.4) and the responsibility matrix. Building it well, once, early, and getting the whole team to agree it, is one of the highest-leverage half-days on any project. In practice architects often organise the WBS by design stage and then by building element - a natural fit with both the RIBA Plan of Work stages and the elemental way buildings are costed.

Once the work is broken down, planning turns it into a programme - a model of the project laid out in time. The universal way to draw a programme is the Gantt chart (or bar chart): a table of tasks down the left, a calendar across the top, and a horizontal bar for each task showing when it starts, how long it runs, and when it ends. Simple to read and quick to grasp, the Gantt chart has been the workhorse of construction planning for a century, and every scheduling tool from a spreadsheet to specialist software produces one.

But a row of bars is only a picture until you add the two things that make it a model. The first is duration - an honest estimate of how long each task really takes, drawn from experience, from similar past projects, or from the people who will actually do the work, not from wishful thinking or from working backwards from a deadline. The second, and more important, is the relationships between tasks - which we come to next. A Gantt chart whose bars are just placed by hope, with nothing connecting them, cannot tell you anything useful when reality shifts. A properly linked one recalculates: move one bar and everything that depends on it moves too, so the chart becomes a live instrument rather than a static poster.

In practice, keep two versions in your mind and your files. The baseline programme is the agreed plan, frozen at the start, against which progress is measured - the reference that lets you say, honestly, whether you are ahead or behind. The live or current programme is that baseline updated with what has actually happened and re-forecast forward. Comparing the two - baseline against actual - is the heart of programme control, and it is what turns 'I feel like we're behind' into 'we are eleven days behind on the critical path, here, and here is the recovery.'

The reason some tasks cannot simply be done in parallel is dependency: you cannot build walls before foundations, cannot plaster before the services are in the walls, cannot paint before you plaster. The commonest dependency is finish-to-start - task B cannot start until task A finishes - but there are others: start-to-start, finish-to-finish, and lagged relationships where B starts a set time after A. Mapping these dependencies across the whole project produces a network, and running the logic through that network reveals the single most important concept in scheduling: the critical path.

The critical path is the longest chain of dependent tasks through the project - the sequence that determines the shortest possible overall duration. Its defining feature is that the tasks on it have zero float (also called slack): if any one of them slips by a day, the whole project finishes a day later. Tasks off the critical path have float - room to move without affecting the end date. This distinction is pure gold for a manager, because it tells you where to spend your attention. A delay to a task with two weeks of float is a shrug; a delay to a critical-path task is an emergency. The critical path method (CPM) is the technique for finding and tracking this chain, and even a rough, hand-drawn version of it changes how you run a job.

The practical wisdom is to know your critical path and guard it ferociously. Identify the handful of tasks that truly drive the end date - often the long-lead items (a bespoke facade, an imported lift, a slow statutory approval), the structural sequence, and the wet trades that must dry. Protect those with buffer, chase their inputs early, and never let a critical-path decision wait on someone's convenience. Meanwhile, do not waste anxiety on tasks with generous float. Managing by the critical path is how experienced planners stay calm: they are watching the few things that matter, not drowning in the many that do not.

Buried in every programme are a few dates that matter more than the rest - the ones the client, the bank, the authorities and the team genuinely care about. These are milestones: significant, zero-duration markers of a key achievement or decision point. Common building milestones include design freeze, submission for statutory approval, approval received, tender issued, contract signed, site possession, foundations complete, structure topped out, watertight (the building envelope closed), services commissioned, and practical completion or handover. A milestone has no duration of its own; it is a flag planted at a moment that says 'this must be true by now.'

Milestones do three useful jobs. They give the whole team a shared set of targets to steer by, cutting through the detail of hundreds of tasks to a handful of memorable dates. They are the natural points for reporting progress to the client and for triggering payments - contracts and cashflows are often structured around milestone achievement. And they are early-warning devices: missing an upstream milestone, or seeing it about to slip, is your earliest honest signal that the end date is at risk, long before the final bar moves. A programme with well-chosen milestones is far easier to communicate and to control than one that is just a thicket of tasks.

Choose them deliberately. Too few and the programme has no intermediate checkpoints, so problems hide until late; too many and they lose their meaning and nobody watches any of them. Aim for a manageable set - perhaps one or two per stage - that mark genuine transitions where something real must be complete before the next phase can safely begin. And tie each milestone to a clear, objective definition of done, so 'design freeze' or 'watertight' is a fact you can verify, not a matter of opinion that dissolves under pressure.

A programme can be logically perfect and still be pure fantasy if it assumes more people, or more hours, than actually exist. Resource loading - assigning the people, hours, equipment and money each task needs, then summing them across the timeline - is the reality check that a schedule too often skips. Lay a programme out and load it, and you frequently discover an impossible peak: three tasks that each need your one detailer, all scheduled for the same fortnight. The logic said it was fine; the resources say it is not.

The fix is resource levelling: smoothing the peaks and troughs by shifting tasks within their float, resequencing, or accepting a longer duration so the work fits the people you have. This is where the abstract programme meets the human reality of a design studio or a site - a studio with four architects cannot draw as if it had ten, and a site with one crane cannot pour as if it had three. Good planners load the programme honestly and adjust it until the resource profile is achievable and reasonably even, because a lumpy profile - famine then a brutal crunch - burns people out and drives the errors that cause rework.

For an architectural practice this matters twice over, because the same people are usually spread across several projects at once. A programme that looks fine in isolation collides with the practice's other commitments; a task that has float on this job has none once you remember the same person is flat out on another. This is why programming a single project well requires a view of the whole studio's workload - a resourcing conversation as much as a scheduling one - and why the practice's overall resource plan and each project's programme have to be reconciled, not drawn in separate rooms.

Programmes slip for reasons that are depressingly predictable, which is exactly why they can be defended. The first cause is optimism: durations estimated by hope rather than history, with no allowance for the friction of real life. The second is the missing dependency - work that could not start because something upstream was not ready, unforeseen because nobody mapped the link. The third is scope creep - the steady accretion of 'small' additions, each unpriced in time, that collectively push the finish out. The fourth is late decisions - the client, the authority or the design team not deciding when the programme needed them to, starving the critical path of its inputs. The fifth is the external shock - monsoon, a labour shortage, a delayed approval, a supply problem.

The defences follow directly from the causes. Estimate durations honestly, from experience and from the people doing the work, and add sensible buffer - not padding hidden in every task, which gets consumed by Parkinson's law, but a visible, protected contingency on the programme as a whole and around the critical path. Map dependencies properly so nothing is a surprise. Control scope through a formal change process (Lesson 6.4), so every addition is a conscious decision with its time cost named. Force decisions to happen on time by making the programme's need for them explicit and visible - a decision-required-by date is as real a deadline as any task. And build resilience for the shocks you cannot predict by keeping float on the critical path and long-lead items ordered early.

Above all, protect the programme by using it. A programme drawn once and filed is worthless; a programme reviewed every week - actual against baseline, critical path re-checked, next milestone in the crosshairs - is the single most powerful control tool a project has. Slippage caught early is recoverable with a small correction; slippage discovered late is a crisis. The whole discipline of programming comes down to that: build an honest model, then keep looking at it.