Programme Review Preparation Checklist

Ask what the document is for, who else has seen it, and whether it is a working tool or a summary prepared for you.

A summary prepared for an owner and the plan actually being worked to are frequently different documents.

Ask how often it is updated, by whom, and whether you will be sent each revision or only asked about specific dates.

A programme that is never reissued becomes a description of an earlier intention within a few weeks.

Note the version and date of the document you hold, and ask whether an older one is still circulating with anybody else.

Superseded programmes circulate for a long time and are the source of most disagreements about what was agreed.

Ask what the programme covers and what it leaves out, including any work by parties the contractor does not control.

Work outside the contractor's scope frequently does not appear at all, even though it has to happen somewhere in the sequence.

Ask whether any of the dates have significance in your arrangement, and take that question to your own legal adviser rather than settling it yourself.

Dates in a programme and dates in an agreement are not automatically the same thing.

Whether a date carries any obligation is a legal question about your arrangement and belongs with your own legal adviser.

Ask what physically happens on the start date, and whether it means people working continuously or an initial visit followed by a gap.

A start can mean setting up, an enabling visit, or full working, and owners usually assume the last of these.

Ask what has to be in place before the start date, including anything that is your responsibility, and when each of those is needed.

Preconditions owned by the owner are the commonest reason a start date moves and the least often stated clearly.

Ask when you need to have moved out or cleared areas, and whether that is the start date or earlier than it.

Clearance is frequently required before the start, which is an uncomfortable thing to discover late.

Ask whether work is continuous throughout, or whether the programme contains periods where nobody is expected to be on site.

Planned gaps look like inactivity to an owner and are often entirely intentional.

Ask what the completion date describes, and whether anything is expected to continue after it such as making good or returning items.

Completion in a programme rarely means the last person leaving the property for good.

Ask which items have to follow one another and which are expected to happen at the same time, and mark the chains on your copy.

A chain is where a delay travels, and it is usually visible in the layout once somebody has pointed it out.

Ask which chain of work is the one that decides the overall duration, since that is where a delay has the widest effect.

Delays in items outside that chain may absorb without affecting anything else, and the distinction is worth knowing.

Ask where two things are shown happening at the same time in the same space, and whether that is realistic or a drawing convention.

Parallel work in one room is sometimes genuine and sometimes an artefact of how the programme was drawn.

Ask which items depend on weather or on a drying period, and what happens to the sequence if conditions do not allow them.

Items with a waiting period built into them behave differently from items that simply take time to do.

Ask where in the programme the moments sit that cannot be revisited once covered, and mark them so you can see them coming.

Reading the programme for cover-up moments is what makes notice arrangements workable in practice.

Ask what is not shown on the programme at all, such as deliveries, surveys or third-party visits that still have to happen.

Events outside the contractor's own work are frequently absent and are exactly the ones an owner has to arrange.

For the few dates that matter most to you, ask what has been assumed for them to hold, and write the assumptions down beside them.

Assumptions are usually stated readily when asked for and almost never volunteered.

Ask which dates depend on something being delivered, and check those against what you know about the orders behind them.

A date that assumes a delivery is only as firm as the order behind it, which may not have been placed.

Ask which dates depend on something from a third party, such as an authority, a utility, a neighbour or an inspector.

Third-party dependencies are outside everybody's control and are the ones most likely to be optimistic.

Timescales involving an authority or a utility are confirmed with that body directly rather than assumed from a programme.

Ask which items depend on a specialist attending, and whether that attendance has actually been booked with them or is only anticipated at this stage.

The difference between booked and anticipated is invisible on a programme and decisive in practice.

Ask where the programme has room to absorb a delay and where it has none, in plain words rather than in programme terminology.

Knowing which parts have no room tells you which news is serious when it arrives.

Ask for a list of the decisions the programme needs from you, with the point at which each one is needed, as a separate short list.

Extracting the owner's own dependencies from a programme is the single most useful thing an owner can do with it.

Ask whether any of those decisions are needed earlier than the work they relate to, because of ordering or manufacture.

Decisions behind made items are needed long before the work appears on the programme.

Ask what happens if a decision is late, and whether it stops that item only or reaches other work as well.

The consequence of lateness varies enormously by item and is the information that makes a decision feel urgent or not.

Say plainly which decisions you are not yet in a position to make, and ask what the latest sensible moment for each one is.

A stated constraint can be planned around; an unstated one appears as a delay attributed to you.

Tell them when you are unavailable, since a decision needed while you are away is a delay that could have been avoided.

Owner availability is an input to the programme and is almost never asked for.

Check whether work by a company you appointed yourself appears on the programme at all, and ask for it to be shown if it does not.

Work that is not on the programme has no slot and will collide with something.

Ask what has to be complete before your installer can start, and check that against what the installer says they need.

These two lists are produced independently and are the place the two programmes actually join.

Ask what work follows your installer, and whether that following work is being held for them or is scheduled regardless.

Following work scheduled regardless is what turns a small installer delay into a wider one.

Agree who tells your installer when the date moves, and confirm you have not left that job with nobody.

The installer has no relationship with the main programme and will not learn of a change unless somebody tells them.

Passing on a date change is a message, not an instruction; avoid committing either party to anything on the other's behalf.

Check that your installer's own lead time fits the slot on the programme, working backwards from the installation date.

An installer available on the date may not be able to have the item made in time for it.

Ask what else moved as a result, rather than accepting a single revised date in isolation from the rest of the sequence.

One item rarely moves alone, and the rest of the movement is what affects your own arrangements.

Ask for the reissued programme rather than a verbal summary of what changed, and keep the previous version alongside it rather than replacing it.

Comparing versions is how the shape of a change becomes visible, which a summary cannot show.

Work out which of your own arrangements are affected by the change, including deliveries, installers, accommodation and anybody who was expecting to visit.

Your arrangements are not on their programme and will not be reconsidered unless you do it.

Ask whether the change brings any decision of yours forward, since a resequenced programme can make something urgent that was not.

Resequencing changes which decisions are next, and that shift is rarely communicated.

Note what you were told about why the date moved, in the words used, without converting it into a conclusion of your own.

A factual record of explanations given over time is useful; an accumulation of your own interpretations is not.

Keep your questions about what follows what rather than about going faster, since sequence is the part you can usefully discuss.

Questions about speed rarely produce information, while questions about dependency almost always do.

Asking about sequence is preparation for reading a document somebody else produced; deciding or changing the order in which work happens is professional coordination and is not an owner's decision to make.

Keep your own marked-up copy separate from the issued one, so that notes you make on it are never read as changes to their document.

Notes written on a shared copy are easily mistaken for instructions by somebody who was not part of the conversation that produced them.

Record the date each issue reached you and by what route, so a later conversation can establish which version each of you was reading.

Most apparent disagreements about a date turn out to be two people reading different issues of the same programme.

When a new issue arrives, read it against the previous one rather than only reading the new one, and note what has moved.

The shape of a change is only visible in the comparison, and a reissued programme rarely says what is different from the last one.

Where a revision arrives with nothing said about what changed, ask what changed and why, rather than assuming it is a tidying-up of the previous issue.

A silent reissue is the ordinary way a date moves without anybody having had a conversation about it.

Tell anybody else in the household who is planning around these dates, since they may still be arranging things from a version you have replaced.

Household arrangements are made quietly from whichever version somebody last saw, and nobody reissues a programme to them.

Ask whether a final version will be issued at completion, and decide whether it is worth keeping with the project papers or simply archiving.

A programme read afterwards explains the order things were built in, which is occasionally useful and easy to discard by default.