Most construction projects have a design programme. Very few have one that the team actually uses. The document is produced — often at speed to satisfy a pre-contract requirement — issued once and then quietly abandoned as the project gets underway and reality diverges from the original assumptions. By the time the programme matters most, it is months out of date and nobody can remember what the original logic was.

This article explains what separates a useful design programme from a shelf document, and how to build one that the team will actually work to.

Why Most Design Programmes Fail

The failure is almost never about the tool. Whether you build a design programme in Microsoft Project, Asta Powerproject, Primavera or a well-structured spreadsheet, the outcome depends on the quality of the thinking that goes into it — not the software. Most design programmes fail for one or more of the following reasons.

The activities are too high-level to be meaningful. A single line that says “RIBA Stage 3” covering twelve weeks tells the team nothing about what needs to happen, in what sequence, by whom, and by when. It cannot be reported against, monitored or recovered when it slips.

The programme is built without consultant input. A design programme produced by one party and imposed on the others will not reflect the realistic resource and delivery capacity of the team. Consultants who have not been involved in building the programme feel no ownership of it and treat it accordingly.

There are no logic links. Activities that are shown as independent when they are actually dependent create a false picture of float and sequence. When one activity slips, the knock-on effect is invisible until it is too late to recover.

Submission and approval periods are not included. The design programme shows when a drawing will be issued but not how long it will take to be reviewed and approved. On projects where approval cycles run to three or four weeks, omitting this from the programme is a significant error.

Nobody updates it. A programme that is issued once and never revised is not a programme — it is a historical record of aspirations.

The Anatomy of a Good Design Programme

Activity Definition

Every activity in the programme should be specific enough that everyone knows exactly what it means and who is responsible for it. “Issue structural drawings for comment” is a meaningful activity. “Design development” is not. The level of detail should be proportionate to the programme period — activities in the near term should be broken down more finely than those further out.

Discipline Breakdown

The programme should be structured by discipline so that each consultant’s deliverables are visible and can be tracked independently. Architect, structural engineer, MEP, civil, landscape, specialist subcontractor design packages — each should have their own swim lane or section within the programme. This makes it possible to identify which discipline is on the critical path at any given point and where the delays are coming from.

Logic Links and Dependencies

A design programme without logic links is a list of dates, not a programme. Logic links define which activities must be completed before others can start, which can run in parallel and where the true float lies. Getting the logic right requires a detailed understanding of the design process — which information each discipline needs from the others, and in what sequence design decisions must be made. This is where an experienced Design Manager adds the most value in programme preparation.

Submission and Approval Windows

Every submission should show not just the issue date but the review period, the expected approval date and the date by which the approved information is needed for the next stage of work. Where the client, planning authority or contractor has a defined review period under the contract or agreed procedures, that period should be built into the programme explicitly. Surprises about approval timescales are almost always avoidable.

Key Milestones

The design programme should be anchored to the project’s key milestones — planning submission, contractor tender, contractor start on site, key construction milestones and practical completion. These milestones create the fixed points that everything else works back from, and they provide the basis for reporting progress to the client and the wider project team.

Float and Risk Allowance

A realistic design programme includes float. Not hidden float that the Design Manager keeps in reserve, but transparent contingency that is acknowledged and understood by the team. Where particular activities carry higher risk — complex interfaces, long-lead specialist design, planning uncertainty — additional allowance should be built in and the rationale recorded. A programme with no float is not efficient; it is fragile.

Building the Programme With the Team

The most effective design programmes are built collaboratively. That does not mean designing by committee — it means the Design Manager preparing a draft structure and then workshopping it with each discipline lead to validate the activity sequence, resource assumptions and duration estimates. Consultants who have contributed to the programme understand it, feel ownership of it and are more likely to raise concerns early when their section is at risk.

This workshop process also surfaces conflicts and constraints that would not otherwise be visible. A structural engineer who knows they are also committed to three other projects during a particular month will say so in a programme workshop. They are unlikely to say so unprompted when a programme is simply issued to them for comment.

Maintaining and Reporting the Programme

A design programme that is produced once and never updated is worse than no programme at all — it creates a false sense of control. The programme should be updated on a regular cycle — typically monthly, or more frequently when the project is in a critical phase — with actual progress recorded against the baseline and a forecast completion date for each activity.

Progress reporting should be honest. A programme that shows everything green when the project is clearly slipping is not a management tool — it is a liability. The Design Manager’s role is to report accurately, identify the activities at risk and present the client with realistic recovery options when the programme is under pressure.

How JC Virtual PMs Can Help

Our Design Managers prepare design programmes that are built to be used, not filed. We work with the full design team to develop programmes that reflect realistic delivery assumptions, include proper logic links and submission periods, and provide the basis for meaningful progress reporting throughout the project. If your design programme needs to be built from scratch or brought back under control, get in touch to discuss how we can help.