Let us first understand the terms i.e., planning & scheduling:

Planning is control of time on a project by:

·         Project Plans which optimise expenditure of time, recognise cost implications and reflect the contractual obligations for the design, procurement, construction and commissioning of plant facilities.

·         Regular updates of all project activities and their inter relationships.

·         Early indication of deviations from the approved project programme so that action can be taken to minimise their effect.

It is to be noted that key elements of plans are Scope of work and Method of execution including WBS.   

With regards to Scheduling, it is a determination of timing of events in the Project i.e., When tasks will be performed and its a reflection of plan. Here are main features of scheduling :

·         Provides comparison of actual progress against plan

·         Identify deviations from plan (problem areas)

·         Enables early corrective actions and adjustments to plan

In other words, scheduling is the science of using mathematical calculations and logic to predict when and where work is to be carried out in an efficient and time-effective sequence.

Here are some rules to minimise the chances of your plan to get failed and ensure project completes before or on time.

Ø   Most importantly, Project Planning & Scheduling must involve decisions concerning :

·         the overall strategy of how the work process is to be broken down for control;

·         how the control is to be managed;

·         what methods are to be used for design, procurement & construction;

·         the strategy for subcontracting and procurement;

·         the interface between the various participants;

·         the zones of operation and their interface;

·         maximising efficiency of the project strategy with respect to cost and time;

·         risk and opportunity management.

Ø   In the process of converting the plan into a schedule  the scheduler should determine:

·         the duration of the activities;

·         the party who will perform the activities;

·         the resources to be applied to the activities; and

·         the method of sequencing of one, or more activities in relation to other activities.

Ø   Depending upon the density of the schedule, the purpose for which it is to be used and the information available, an activity duration must be derived from following only. Any assumptions must be documented in case needs to be validated in future.

·         experience

·         industry standards

·         benchmarking

·         comparison with other projects

·         calculation from resources

·         specification.

Ø   The schedule must illustrate a realistic and practical project plan showing how the project is intended to be, in a form that is sufficiently accurate for its identified density.

Ø   Schedule must be capable of identifying the following:

·         the longest path to completion;

·         the longest path to intermediate key dates, or sectional completion dates;

·         logic and activities, which are critical from those, which are not critical to one, or more completion dates;

·         total float on each path;

·         free float on each activity, on each path;

Ø   The strategy for schedule review must take account of the development of the schedule as better information becomes available and, as the project proceeds, the increasing density of the schedule as it develops from initiation through the work on site to commissioning the completed project.

Ø   When change is imposed, scheduler must be able to identify it contemporaneously, the effect of delaying and disrupting causal events on the planned sequence and to advise team members on the likely effect of possible recovery strategies.

Ø   Risk is inevitable part of any program however if dealt well, can be brought under control. Contingency period to deal with risks should be designed to be identified separately for both the employers and the contractors risks and for those risks which are related to:

·         an activity, or chain of activities

·         a contractor, subcontractor, supplier, or other resource

·         an access, or egress date, or date of possession, or relinquishment of possession

·         the works, any defined section, and any part of the works.

Ø   For Schedule reporting , it is impracticable to use the whole of the schedule at any one time in its detail. For effective reporting it should be summarised to different degrees of summarisation for differing purposes. Most project scheduling software packages facilitate this hierarchical structuring by virtue of a summarisation, or roll-up facility.

Some basic tips:

• Do not use Mandatory Constrained dates. If a constraint has been used, then "Start on or After" can be opted. Keep use constraints as minimal as possible.
• Adopt Finish to Start logic as much as possible. Avoid SF links completely.
• No "Dangles" at all in schedule. LOE tasks could be an exception here.
• Avoid use of lags, especially long duration lags
• Keep Level 3 activities to similar levels of detail whenever possible
• Roll-ups from Level 3 to Level 2 must be "many to one" with no splitting of level 3 activities into individual level 2's
• Status activities only after confirming its reliability & source
• Make your activity ID's intelligent to identify where it belongs to.
• WBS development is must before the creation of schedule
• Avoid changing RD just to keep the activity out of critical path
• Identify Key Events and Drop Dead Times before developing the plan
• Schedules needs not to be way too detailed.
• Be realistic irrespective of pressure from Client, Project Managers and Engineering/Construction leads.
• Avoid "tweaking" of the logic to "make it fit."
• Activities must be linear and sequential (Finish-to-Start), instead of being overlapped, i.e., successor starts before the predecessor - a version of "fast-tracking" at the molecular level.
• Planning procedure should encompass familiarisation, outline plan, strategic plan and detailed plan along with planning method statement
• Do not deceive (to mislead by a false appearance or statement). Don't mislead the schedule by false appearance
• Get buy-in from the responsible owners of the plan. In absence of this, plan is no more than a worthless piece of paper.
• Ensure the calendars are set before developing the plan to includes the holidays and working hours restrictions, if any.
• Activity codes should identify the various attributes of the schedule as fields, the values of which will facilitate organisational changes, and facilitate filtering of important parts of the schedule.
• Schedule review must check for buildability, content, integrity, constraints, open end tasks, long lags, negative lags, ladders and critical paths to name a few.

Summary:

Don't twist the plan, contort the plan, reduce the plan, expand the plan, modify the plan, distort the plan, adjust the plan, change the plan.. Instead, follow the plan..

For example, this month is December, most of activity they update start and finish within December but there are always some activities which is updated in November or even in October. (They said they forget to update those activities in November so now they update it this month).

In this case P6 will add some more units to November and make your November report wrong. You have sent November report to other parties and it can not be edited. So, the only solution is you move all November "mistake" unit to December.

You can use Excel to save figure of November and December. Then we can have Actual this month by taking December minus November.

However, we can do this right in Primavera.

First in November you need to run Tool -> Store period performance, to storage Actual Units (in fact this is the cumulative actual unit) to November period.

In December you just update as normal. Now you can show the "Actual This Period Units" column. And that's the data we need.

We are often asked about what are criteria for building Risk schedule. In other words, what factors needs to be taken into consideration while building a risk schedule on which risk analysis will be performed. Here is the plan check list which you may find it helpful - Be between 50 and 200 activities (the smaller the better).·         Have only finish to start relationships. If not possible then start-to-start orfinish-to-finish should be kept to the very minimum but never on the critical or near/sub critical paths.·         The plan must have no constraints e.g. Must Start On Date, Cannot Finish Later Than Date etc. The only acceptable constraint is the start date for the first activity.

 However, if there is some doubt about when the project will start then it is recommended that an activity prior to start is put into the plan, this can be constrained to say current date. Another activity called something like duration to start of project then follows and the actual start of the project links to this. This will allow a variation in the actual start of the project to be considered in the analysis.The plan should only contain future and current (remaining scope) activities. Completed activities are not required. No progress should be shown against an activity only the remaining work for that task.·         Lags and leads should also be avoided. If you want to start an activity say three weeks after 'Design' starts then it is better to split the Design activity into two calling the first part something like Design to requisition stage, this would then become the finish to start to the activity that you wanted to delay.Ideally the plan should have one start and one finish. However, if the plan has more than one end then multiple ends are possible. If this is the case then thought must be given to structuring the plan so that activities can be deleted to review each end separately, if required. This may be needed as the analysis will show the critical path for the last/longest activity/path and therefore, shorter paths (to the other ends) will not show up as critical. To show these as critical the other ends and their associated activities can be deleted and separate runs carried out.

        Titles should be self-explanatory and not reliant on summary level descriptions e.g. the plan may have various sections the first called Design. The activities within Design relying on the reader to see the Design section heading. This is required as the risk analysis will likely sort the activities in a different order and therefore, the descriptions must stand alone. Summary level titles should be avoided.Ideally the plan should be developed using a single calendar. Weather modelling and non-productive time will be modelled within Primavera Risk Analysis (PRA).

We are often asked about what are criteria for building Risk schedule. In other words, what factors needs to be taken into consideration while building a risk schedule on which risk analysis will be performed. Here is the plan check list which you may find it helpful - Be between 50 and 200 activities (the smaller the better).·         Have only finish to start relationships. If not possible then start-to-start orfinish-to-finish should be kept to the very minimum but never on the critical or near/sub critical paths.·         The plan must have no constraints e.g. Must Start On Date, Cannot Finish Later Than Date etc. The only acceptable constraint is the start date for the first activity.

 However, if there is some doubt about when the project will start then it is recommended that an activity prior to start is put into the plan, this can be constrained to say current date. Another activity called something like duration to start of project then follows and the actual start of the project links to this. This will allow a variation in the actual start of the project to be considered in the analysis.The plan should only contain future and current (remaining scope) activities. Completed activities are not required. No progress should be shown against an activity only the remaining work for that task.·         Lags and leads should also be avoided. If you want to start an activity say three weeks after 'Design' starts then it is better to split the Design activity into two calling the first part something like Design to requisition stage, this would then become the finish to start to the activity that you wanted to delay.Ideally the plan should have one start and one finish. However, if the plan has more than one end then multiple ends are possible. If this is the case then thought must be given to structuring the plan so that activities can be deleted to review each end separately, if required. This may be needed as the analysis will show the critical path for the last/longest activity/path and therefore, shorter paths (to the other ends) will not show up as critical. To show these as critical the other ends and their associated activities can be deleted and separate runs carried out.

        Titles should be self-explanatory and not reliant on summary level descriptions e.g. the plan may have various sections the first called Design. The activities within Design relying on the reader to see the Design section heading. This is required as the risk analysis will likely sort the activities in a different order and therefore, the descriptions must stand alone. Summary level titles should be avoided.Ideally the plan should be developed using a single calendar. Weather modelling and non-productive time will be modelled within Primavera Risk Analysis (PRA).

<p