Programme & Record Maintenance Top 10 Tips

YOU MIGHT OFTEN HEAR that the key to a successful project, especially if it generates into a dispute, is records, records and records. But what does that actually mean? What records should be kept and what information should they contain? In fact, I have often found
that when they are put to the test in a claim situation, many contractors who think they have good records don’t! One area that constantly crops up is programme maintenance.

So what are good records? The following advice is based on my experiences of programme and record keeping, which have proved to be successful within formal proceedings.

1. Keep consistent progress monitoring records that can also be related back to the baseline programme
Progress records should be detailed enough to record the activity being progressed, the labour, plant and materials being used without being too overly burdensome that the foreman and supervisors don’t use the form or process. Delays or events which prevent the works from progressing as planned should also be recorded. Photographs are also very useful but these need to be filed in a coordinated filing system which records the date and time taken, as well as a location which ideally should be reconcilable to drawings and the baseline programme. Progress records should be accurate to ensure that if a retrospective analysis is required, they can be relied upon. Records must be maintained for the duration of the works with no gap periods, i.e. from the day you start the first works to the day you leave site. Consideration should be given to how
records will be kept during leave periods of supervisors and as the site presence decreases. Above all, records should be reconcilable to the baseline programme so that it is clear what aspect of the works they relate to.

2. Don’t change programme task codes and keep philosophy of the programme consistent
If task/activity codes are used, these should be kept throughout the life of the programme and subsequent revisions. Activities should also never be deleted or removed from the project, if the task is genuinely no longer part of the scope of works it should be reduced to 0 days (i.e. a milestone) and marked or coded as such. Ideally, a note should be added as to why the task is no longer required. When the programme is presented in a printed format, a filter can be applied to remove the obsolete tasks. This helps to reduce problems when overlaying (comparing) programme versions when the same activity codes/IDs have been assigned to different tasks.

3. Monitor long lead items and major package works
I often see numerous examples where work packages have not been procured on time; leading to delay which is at best concurrent and sometimes on the main critical path and therefore culpable.

It is essential all lead times for work packages are monitored. In particular, those with long lead times. These need to be monitored against the programme to ensure if there are any changes they filter through to the relevant package.

4. Ensure the programme is properly logic linked with no open ended tasks
All activities should generally have a predecessor and a successor with no open ends, i.e. activities with no logic to a dependency (save for finished milestones/activities). The use of start-tostart and finish-to-finish relationships should only be used where absolutely necessary, as it should be asked whether these accurately reflect the true logic of
the programme. Finish-to-start relationships are much preferable. Start to-finish relationships should be avoided as should negative lags between relationships. Finish-to-finish relationships as the only dependency on an activity should also be avoided. Mandatory finish constraints should also be avoided as they alter the way in which a programme reacts if updated. In large programmes these are often entered but later missed when updates are undertaken. 

By correctly logic linking the programme it should be possible to determine the critical path, even if this is not disclosed externally. Whilst the critical path is important, any focus on it should not be at the expense of other activities by taking the eye off the ball.

Any critical path, indeed any logic path of activities, should be sanity checked for common sense.

5. Keep document registers for all project records
A full document register should be developed to record the existence of all project documentation; dates, to, from, its location in hard and soft copy form, and any necessary actions. As with the progress monitoring records, these need to be kept updated throughout the duration of the project.

6. Don’t use overly complicated calendar allocations
I have often seen the use of multiple calendar allocations to model task specific non-working periods. However, these often get forgotten about when
delay or change occurs, resulting in the task or other tasks falling in or outside the non-working period.

If you do use calendar allocations, remember to monitor and update these as you would other aspects of the programme. Also ensure that the correct tasks are assigned the correct calendar allocation, otherwise you will potentially end up with an unrealistic programme.

7. Ensure the baseline programme is robust and achievable
A robust and achievable baseline programme is the optimal way to commence the works. Activity durations should be achievable and logic should be sensible and genuine.
Links should not be added just to hold activities in place. Logic should be tested to ensure that the programme reacts to delay and change in the manner in which common sense would suggest it should.

8. Be aware of progress on all floors, levels and areas
A potential defence to an extension of time claim is that the contractor is in concurrent delay. Whilst the contractor may still be entitled to an extension of time, if there is genuine concurrent delay this may affect any loss and expense costs which may be recovered. 

Progress should be carefully monitored to ensure that any concurrent culpable delay is identified early and mitigated or dealt with, rather than discovering the problem later on when there are no solutions available. Remember not to take your eye off the ball in other areas even when a specific area has excusable delay. You may still be at risk, even if that risk is cost not time.

9. Monitor programme risk and make allowances where necessary for time risk items
Too often risk registers are drafted during the tender stage to satisfy the requirements of a bid and then the document discarded or not updated once the works commence.

The risk register is a powerful tool that, if used correctly, can help the management of a project. It should be updated and scenarios modelled to ensure should the risk event occur the solution has been rehearsed rather than reacting to it.

10. File email correspondence on the project server
Email is becoming the predominant form of communication on construction projects and whilst this is not necessarily a problem in itself, it can become a big issue if staff do not file the communications on a central available workspace. We have seen many instances of lost records when members of staff delete emails without considering the significance.

A similar issue arises where there is not a proper filing structure or convention. If a central archive software system is not used, all should follow the same convention which should make it as easy as possible to retrieve the necessary email communication. Multiple versions of the same message should also be avoided. This is by no means exhaustive but should go some way to improving the administrative performance of projects, especially if the records are tested in a dispute forum.

Records and programmes are important but there’s no point in keeping records for records sake. Make sure they are useful!

Tim Ellis
BSc(Hons) MRICS ACIArb
Director, MBM Consulting