Article by Andrew McKenna, Director of Delay and Planning
Download a PDF version here
What is Planning & Programming?
The words planning and programming are often used interchangeably to describe two distinct functions of project management. Planning constitutes how the project will be executed (the plan), whilst programming concerns the communication of the plan.
Planning starts at the time of tender and continues through to completion. The plan constantly evolves as the project progresses, as should the program.
The program consists of a sequence of logic-linked activities in line with the project plan of varying duration from commencement to completion, typically in the form of a Bar (Gannt) Chart. A good plan is constantly updated to reflect change and progress. A planner manages this process and its communication through the program. However, to successfully execute the plan, the project must “own” the program.
“If you fail to plan, you are planning to fail!” - Benjamin Franklin
The Critical Path
The project critical path is usually determined through programming software using the critical path method (CPM). Simplistically, the critical path identifies the most time (or resource) sensitive sequence or “path” of activities through the program from start to finish. The CPM is also widely accepted as the preferred method of demonstrating the causation and effect of delaying events.
The baseline master program or “contract” program is a static document
Whether it be due to a delaying event, subsequent mitigation strategy, or work not captured in an earlier revision, for a program to be a useful project management tool it must be updated to reflect any significant deviation from the originally intended plan. Otherwise, the program will become irrelevant.
No matter how robust and detailed the original plan is, it will invariably change throughout the course of a project. An accompanying basis of schedule document which substantiates and justifies the changes must be submitted with the revised baseline, and its approval sought from the clients representative or otherwise.
The program is solely used for the purpose of monthly reporting
It is often a requirement that projects status be reported against the baseline or “contract program” to demonstrate progress. The planner or program operative often only considers the works planned to have been undertaken in the previous nominal time frame (typically a month) between reporting periods. Activity commencement and completion dates or a perceived percentage complete of activities in progress are simply input, overriding the planned logic. The activities after the update are rescheduled in accordance with the preceding activities’ anticipated completion date based on a software algorithm. This is “programming”, not planning.
The planner or program operative should instead update the program contemporaneously by modifying the as-planned logic and activity durations to reflect what occurred more frequently than the nominal reporting period. Additional activities (or “fragnets”) should be added where necessary to rationalise a change to activity duration. Similarly, future activity logic and durations should be reviewed and any changes noted in the basis of schedule document, and be accompanied by substantiating records. This way, a “live” (as in it has a historical critical path) as-built program is maintained and a more robust forecast is communicated.
A project should have a single master program that incorporates the intent of the entire construction process from commencement to completion in an appropriate level of detail. Short-term (look-a-head), detailed programs should be developed by the respective contributor. However, their content must relate directly to the master program, which is managed solely by the planner or program operative.
Managing and controlling multiple programs is difficult and time consuming. Often contractors see it as prudent to have two master programs: A “contract” program for reporting and a “target” program to actually work to. This approach is fraught with trouble since the project will have a different status for each program for the same works in the same respective period. Therefore, making it difficult to prove causation in the event of delay and for the party privy only to the “contract” program to understand their key interfaces and deliverables.
Planning and programming are not the same. The program is the “vehicle” by which to communicate and update the plan. It should not be seen as just a contractual obligation, but an essential tool in the management of projects. Join us for Part 2 of the Planning & Programming Pitfalls series of articles where we will discuss the following salient issues:
- The baseline level of detail;
- Updating programs without the support of contemporaneous records or justification and “Actualizing” programs;
- Contingencies and delay allowances and;
- Demonstrating cause and effect.
Disclaimer: This paper does not in any way constitute any type of legal or professional advice whatsoever and in no way should be relied upon by any party whatsoever in any jurisdiction.