Working out a master programme is a challenge. More often than not, it is like the planner's craftwork to satisfy all parties' requirements, be it contractual key dates, sequence of work, cost and resource balance. When it comes to evaluate the programme, the planner must be able to present his works in a clear, concise and understandable terms to his bosses as well as co-workers.  Since programming is a highly specialized work, communication is important to get common understanding among all team players. Though there is no such standard to evaluate a programme, still there is some kind of normal practice around in this field. The followings are the writer's views.


Just as the drawing is the product on the paper, the programme is the model of the construction relating all activities with 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 shall be coded, duration shall be worked out and sequence of work shall be logically linked in line with the method statement and sequence of work.

With widely use of the computer aided planning software, the programme is getting more detailed. Less-detailed programme is only used for tendering or the preliminary use. For the actual project, the number of activities for a baseline programme can easily exceed more than 1000, and sometimes up to a few thousands. Detailed programme makes tracking the progress easier when the job is on the road.  Also, since the activity duration shall reflect the quantity, production rate and resources, a reasonable detailed programme is needed. Generally, the more detail the programme is, the more confidence the planner and other project players have. On the other hands, too detailed programme will make progress updating troublesome and not practical when the project is underway. Generally, the level of the detail shall not be more than the BQ items (you may take the programme as another version of BQ). Level 4 is usually enough.

The modern way of programme is built on top of the 3D drawings. Imagine to lego a simplified building. Components of building are erected according to the sequence of work with resource / cost built in. This will greatly impress the client and we may call it 4D model.

The traditional CPM based programming software is effective in modeling 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.


How many times have you seen the A1 sized 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 guys who will use the programme and who are to implement it. The planner is merely the "facilitator" from this point of view.  Since there are so many guys with different disciplines and background, the planner shall be able to sort the thing out, organise the thing in logic order and present the thing to get 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.


-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, 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 judgment 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 activites relationship 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 activites use 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.

-Duration can not 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, can not 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 guidelines only. Sometimes the planner must compromise one aspect of criteria in order to meet the other. It is like artwork in this sense.