Leading Practices used when creating a Project Schedule – 2

This is the second blog to a series of blogs I intend to post covering some of the most important aspects of scheduling. These are some leading practices that are applied by many seasoned Project Managers, but are often missed by someone new to the world of Project Management.

These are just some of the recommendations which are helpful to the planning staff, but there are other rules and recommendations that should applied to your schedule depending on the complexity of your project. All the recommendations provided here are of equal importance and I am not following a structure when numbering them.

In the previous blog I talked about

1. All tasks should have a unique Name

2. Task Names should have a Verb

In this Blog I will cover 2 more topics –

3. Most task dependencies in your project must be Finish –> Start

Initial scheduling models only allowed Finish –> Start dependencies. The other three kinds of dependencies were incorporated later. The fact is most real world task dependencies are still best modeled by Finish –> Start.

Some non-seasoned Project Managers will try to use all the dependencies in their schedule, especially Start –> Start. Start –> Start is usually applied when a planner comes across statements such as: …. and activity X starts at the same time as activity Y … In this case, a Start –> Start dependency is likely to be chosen, even though it is usually not the right choice.

For example – Consider the following

When you choose Start –> Start, it means that Task 5 cannot start unless Task 4 has started. But is this really the case? Usually, when people say Task 5 starts at the same time as Task 4, they usually mean that Task 5 has the same predecessors as Task 4. In such cases the following would be the correct way to show

You will need to enter the same set of predecessors for Task 5 instead of using Start –> Start relationship. But there are instances where you have a lot of predecessors to these tasks and it is painful to enter the same set of predecessors for the second task. When you have a lot of successors based on a lot of predecessors, you actually have an important event that happens between them, so you should ideally have a milestone. In such cases you can make both the tasks successors of that milestone.

4. Start –> Finish task dependencies must be avoided as much as possible.

The first impression of a Start –> Finish dependency is that this puts the activity before the predecessor. For example

So what happens if we have more than one predecessor?

What some expect

What really happens

Some people expect Task 4 to finish before the earliest predecessor, but it finishes before the latest predecessor. A Start –> Finish means that the successor should not finish unless the predecessor has started. When you have multiple Start –> Finish, it means that your successors should finish when all three predecessors have started, which means the start date of the latest predecessor.

So when should we use Start –> Finish dependency? Most give an example of Buying materials before beginning construction. You normally would like to buy material right before you start construction so you can avoid storing the materials.

This is good if everything works as planned, but what happens if we start Material Buying process on time, but realize that it is going to take a lot longer than planned. This is how the schedule will look like-

In this case the schedule does not change, but is it right? Of course not, we cannot start the construction unless the materials have arrived. So a Start –> Finish dependency is not the right choice in this case. So what is a good case for the Start –> Finish dependency? Well Nothing