Developing a master programme can be a challenge. More often than not, it is like the planner's craft work to satisfy all parties' requirements, be it contractual key dates, sequence of work, cost and resource balance. When it comes to evaluating a construction programme, the planner must be able to present his works in a clear, concise and understandable terms to the Project manager as well as project supervisors.
Programme must meet the requirements
A programme is a model of the construction activities relative to time. So the primary purpose of the programme is to reflect the construction sequence that is, scheduling. Resource and costing are the by-products based on the schedule. Activities should be coded, duration should be worked out and sequence of work must be logically linked in line with the method statement and sequence of work.
As a result of complexity computer aided planning software are commonly used as programmes are getting increasingly more detailed. As a rule less-detailed programmes are only used for tendering or preliminary phases. For the actual project, the number of activities for a baseline programme can easily exceed more than 1000, and sometimes up to a few thousand activities. A detailed programme makes tracking the progress easier during project execution. Also, since the activity duration shall reflect the quantity, production rate and resources, a reasonable detailed programme is needed.
Generally, the more detailed the programme, the more confidence the planner and other project players have. That said, too detailed programme will also make progress updating troublesome and difficult to follow. Generally, the level of the detail shall not be more than the BoQ items (you may take the programme as another version of the BoQ). Level 4 is usually enough.
The traditional CPM based programming software is effective in modelling the physical works with strong logical relationships. However, this model has shortcomings to simulate the not-so logical relation type of activities, for example, architectural finishing works, submission and approval procedures (whether to the client or the relevant authorities). For this, establishment of milestones, or constraint analysis or a typical checklist will be more useful.
As a result of complexity computer aided planning software are commonly used as programmes are getting increasingly more detailed. As a rule less-detailed programmes are only used for tendering or preliminary phases. For the actual project, the number of activities for a baseline programme can easily exceed more than 1000, and sometimes up to a few thousand activities. A detailed programme makes tracking the progress easier during project execution. Also, since the activity duration shall reflect the quantity, production rate and resources, a reasonable detailed programme is needed.
Generally, the more detailed the programme, the more confidence the planner and other project players have. That said, too detailed programme will also make progress updating troublesome and difficult to follow. Generally, the level of the detail shall not be more than the BoQ items (you may take the programme as another version of the BoQ). Level 4 is usually enough.
The traditional CPM based programming software is effective in modelling the physical works with strong logical relationships. However, this model has shortcomings to simulate the not-so logical relation type of activities, for example, architectural finishing works, submission and approval procedures (whether to the client or the relevant authorities). For this, establishment of milestones, or constraint analysis or a typical checklist will be more useful.
Programme must be practical and useful
How many times have you seen an A1 bar chart pasted on the meeting room wall for months, and in the end nobody bothers to look at it? To make the programme useful, the management system shall be set up first. The programme fundamentally shall be from the managers / supervisors who will use the programme and who are to implement it. The planner is merely the "facilitator" from this point of view. With so different views of supervisors / manager focusing on different disciplines and with different background, the planner has the challenge to resolve, organise, implement logic and present the plan to achieve a common understanding. Also, before the programme is ready to go, all concerned parties must sign off the programme to commit it. Proper documented procedures must be established to make this happen.
Criteria to evaluate a programme
- The programme shall be developed from the framework of the contractual key dates. If the contractor's key dates are planned earlier than the contractual key dates, no critical path appears (the critical path is on the contractual key dates which are assigned "finish no early than" and "finish no later than" constraints).
- The programme shall be complete. From the view of the project life, it shall include submission and approval (shop drawings, method statement and relevant approving authorities), procurement / manufacturing / fabrication / delivery, mobilization, construction and installation, testing and commissioning.
- No negative float at all during planning stage.
- Is critical path or near critical path make sense based on past experience, method statement and common sense? Here the judgement plays a role because we know before programming that some area of works falls on the critical path.
- Are there artificial leads or lags and constraints? User assigned lead / lag time and constraints override the network logic in calculating early and late dates and float. Constraints are only used when the contract specifies.
- Theoretically, there shall be no open activities except for the start and finish key dates. That is to say, only one entrance and one exit to go through the programme. In other words, the very start activity has no predecessor, and the last activity has no successor. All activities but the very first and last shall have both predecessor and successor. In actual job, this rule is sometimes difficult to follow unless the programme is pretty small. Early start constraint has to be assigned to the "very hard to decide" activity where its predecessor is difficult to define.
- Most activities shall have only one predecessor and one successor, or in some cases, only have soft (resource constraint) and hard (logic constraint) links. Too many predecessor and successor tend to confuse the logic.
- Most activity relationships shall be in FS (the conventional way) and it depicts the sequence of works in the network. The more detailed the programme is, the more activities rely on a FS relationship.
- Grouping under one activity code's value by summarizing (eg. "location" or "area") shall not have unnecessary gap. This means, the work shall be carried on smoothly without interruption.
- Durations cannot be too long or too short. This means that the programme shall have reasonable degree of detail. Similarly to the resource and cost allocation.
- Total float shall make sense and explanatory.
- Resource curve shall maintain in a normal distribution pattern.
- The resource envelope formed by planned early and late curve shall be typical, meaning, cannot be too "fat" or too "thin". This is controlled by duration and total float.
- Description shall be specific enough, that is, not relying on the activity code, one can understand the scope of work.
- Use the milestone to transfer the interface key dates from one stage to another or for different areas of work.
- Add log notes after description on the bar to explain the planner's intention.
All these criteria are a guideline only. Sometimes the planner must compromise one aspect of criteria in order to meet the other, it is like a work of art in a sense.
RSS Feed
