Scheduling Rules

Scheduling Rules

Scheduling Rules
Scheduling Rules
 

 
This document I wrote for a team I was leading in a past. I believe it might be helpful to share to other project planners as well. Applying the rules desribed below might increase the length and effort of your initial planning, but certainly it will buy you back a lot of time in schedule maintenance and control. I hope you will find this document helpful.
If you want to access full document please email me. 
Rule No.1  
The Schedule Should Have a Complete Scope  
Your schedule should reflect the whole scope of the work of the project, nothing less and nothing more. When we are talking about project scope, this is not limited to work needed to produce deliverables of the final product; we also need to do some extra work to ensure that we will have what we are expecting (quality activities), we will not miss opportunities and we can face threats, and so on. 
 
Download Also:
Let review the whole scope planning process:  
We start by identifying goals. We then go for the requirements; requirements tell us how we expect to reach the goals. The next step is to define the product scope and product breakdown structure; this will give us a complete view of the final product and all its elements. The last step is to convert product elements into work needed to create them, and add the extra work (e.g. quality and risk response work) which produce our project scope and work breakdown structure. The work breakdown structure is a hierarchical structure of project deliverables.  At the end, we should ask ourselves what kinds of work we should do to produce each deliverable and the answer is our activity list. 

There are two rules for creating WBS:      
  • it should be based on deliverables (and not the work)     
  • it should cover 100% of the scope, nothing less and nothing more
The items in the lowest level of WBS - which host the activities - are usually called work packages. When you are about to break down a work package to actives you should be careful to add every work needed to produce that very deliverable.  This rule applies to all situations. For example, if stakeholders agree on some strategic changes and ask you to prepare a new plan for the remaining of the work, what should you do?  
 
Some planners prepare a new plan which covers only the remaining parts. This is not a good choice. As long as you are working under the same old contract, your schedule should cover all of its scope. You should reschedule the remaining parts based on the new strategy instead of creating a new incomplete plan. If you need to report the performance of the remaining parts, you can easily calculate them within that complete plan. 

Rule No.2  
Level-of-Efforts Should not Be Critical and Should not Have Variance
There are some special activities in every project that do not produce any product by themselves and just support other activities to fulfil their job; project management, supervision, and accounting are examples of this kind of activity. These activities are called Level-of-Effort or LOE for short.  Hosting LOEs in schedules is not as easy as normal activities and they barely make any difference in the monitoring and controlling processes. That is why some planners prefer not to include them in their schedules.  
If you insist on having a complete scope in your schedule, you have to enter LOEs; that is why PMI does not forbid them, but states that you should be careful with LOEs because they should never be critical and should not report any variances.  LOEs do not have any specific and independent duration; their start and finish are based on other activities. You will never be behind schedule in LOEs as they are ongoing everyday work. That is why it is not acceptable for them to be critical or have variance. 
 
In addition, if your LOEs become critical, some other really critical activities will become non-critical, and that is the main problem.  Primavera P6 uses predecessors and successors for scheduling LOEs, but you do not need to worry about it, because they are not real relationships that PMI recommends you to avoid using for LOEs. You actually do not need to worry about LOEs in P6 at all; you just define them as LOEs and the software handles them as they should be (e.g. they will never become critical).

Rule No.3  
Activities Should Have Unique Names
When you are naming activities, you should do it in a way that anyone in any situation can understand it. Select an activity, take it out of the WBS and see if you can understand it. The most important rule in this area is to have unique names. Take a look at this table:
Names are not unique                                 Names are unique  Fifth floor                                                      Structure of the fifth floor  Build columns                                               Build the columns of the fifth floor  Build sheer-walls                                           Build the sheer-walls of the fifth floor  Build slab                                                       Build the slab of the fifth floor  Sixth floor                                                       Structure of the sixth floor

It takes more time to enter the complete and unique names, but believe or not, it is worth the effort. You can easily make a mistake and link the sixth floor slab to another activity instead of the fifth floor slab. But if you use unique names, you will easily find these kinds of mistakes.  There are always many different ways of showing the activities. You can make alternative breakdown structures for your different needs, and in their corresponding views you do not have WBS elements anymore. If activity names are unique, you can understand them outside the WBS, but otherwise, you will not be able to use any alternative breakdown structures in an efficient way.

Rule No.4  
Activity Names Should Have a Verb
Work Breakdown Structure represents the scope of the project. WBS elements are deliverables and you decompose them into different kinds of work (activities) needed to produce those deliverables.  As you can see, WBS elements and activities are two completely different entities. This difference should be also reflected in their names.
Check these two names:      
  1. prepare shop-drawing for the structure of the second floor     
  2. shop-drawing of the structure of the second floor
Which one is suitable for WBS elements and which one is suitable for activities?  The first one is an action and shows a work; therefore, it can be used for activities. The second one points to a thing (the drawing), to a deliverable; therefore, it can be used for WBS elements.  In order to show a work, you usually have to use a verb or something equivalent. This rule is not just a formality, but helps you and your audience better understand the activity. If we only say "shop drawing", it does not show the act; is it supposed to prepare it? To check it? To approve it? Or even to execute it? This name just does not answer any of these questions.
 
Rule No.5   
Each Activity Should Have at Least One Predecessor and One Successor
Most planners know this rule:  Each activity or milestone should have at least one predecessor, except for the first one  And  Each activity or milestone should have at least one successor, except for the last one 

If you do not imply this rule, some of the activities or milestones will be out of the network and will not have an effective role in the total schedule; this is against the reality of the project.

If you do not follow this rule, these will be the least problems you will encounter:       
  • your future schedules will not be realistic     
  • your performance information and delays analysis will not be realistic
It is recommended to have at least two contractual milestones in every schedule: the start milestone and the fish milestone. In most cases "The effective date of the contract" is the start milestone and "The provisional acceptance" or "The final acceptance" is the fish milestone. The start milestone does not have a predecessor, and the fish milestone does not have a successor; all other activities and milestones need at least one predecessor and one successor.  Always check the integrity of your network logic by this rule. If it fails, you will realise that you have missed some of the relationships. It is common for planners to miss non-driving relationships and you should be careful with them. 
 
When you have more than one predecessor, one of them influences the successor the most, in a given time, and it is called the driving predecessor. If you remove all the other predecessors, the schedule remains the same. The point is that each non-driving predecessor has the capacity of becoming driving one day, so you should keep them all. Most of the activities which do not have a successor are actually non-driving predecessors and you should fix them.  
 
In the end: 
  • If you believe that a specific activity or milestone does not have any predecessor at all (it can start on the first day of the project), make the start milestone its predecessor.     
  • If you believe that it has no successor at all (it can potentially fish on the last day of the project, and no other work will get into problem), make the fish milestone its successor.
Unfortunately, although some planners know this rule, the only thing they do is making the start milestone (or another early activity/milestone) the predecessor of all activities that do not have other predecessors and make the fish milestone (or another late activity/milestone) the successor of all the activities that do not have other successors. This is cheating! You should always analyse and find the missing relationships. If you are about to review a plan you can easily check to see if some items have too many predecessors or successors; they usually show this kind of cheat.
 
All that mentioned before in this rule is the PMI way.
 
Related Topics:

                                              Dariusz Wolejszo
About:
Project Control specialist offering more than 15 years of leadership in design, construction, project development, and commissioning of high-profile oil, gas, petrochemical and power facilities.  Strong experience in a project controls management role, working for international construction companies.  G
reat understanding of Planning, Cost, Estimating, and document control. Excellent communication and interpersonal skills. Team player, self-driven and good in high pressure dynamic situations.  People and result orientated individual with strong understanding the motivational requirements whilst working in projected organizations. 
 
 Industries: 
Oil & Gas (Onshore & Offshore), Power Plants, Shipyards, Railway – ERTMS
Previous Post Next Post

Comments