Project Scheduling Best Practices

This article builds on our Project Planning guide - Stage 3 Estimate effort and schedule

Why you should avoid fixing start and finish dates in project scheduling

Arbitrarily setting start and finish dates for tasks on a project plan can spell disaster for your
Why? Well there are three reasons why a Project Manager would fix start and finish dates:
  1. Senior Managers or the Customer are forcing the project manager to make the plan fit a predefined timeline
  2. The Project Manager doesn't understand Critical Path analysis or has decided not to use it,
  3. The Project Manager hasn't been trained on MS Project and don't fully understand the impact of fixing start and finish dates.

Reason number 1: The Project Manager is forced to make the plan meet predefined timescales

Every Project Manager has been asked to make a plan fit a particular end date. Hopefully they will be able to use their skills to establish if it is possible and if it isn't, explain why not. They must never be persuaded to simply reduce estimates.

The problem is that very often those asking for a shorter timeline are senior managers and/or Clients who are used to getting their way. But if shortening the timeline is not possible it is our job as Project Manager to be brave and say "no".

The following quote should provide some comfort next time you are in this situation. I have actually shared this quote with managers to back up my position.
“never must the Project Manager allow himself to be persuaded or coerced into trying to expedite a plan simply by ‘marking down’ estimates without any justification [....] Such optimistic plans can gain a temporary advantage by serving to pacify higher management or by deceiving a trusting customer into placing an order. Unfortunately the truth is bound to emerge sooner or later, bringing consequent discredit on the company”
Dennis Lock 1996

Reason number 2: The Project Manager doesn't understand or is not using Critical Path Analysis (CPA)

Critical Path analysis was developed in the 1950s. Various methods of project planning were developed that enabled Project Managers to map and understand the relationships between tasks. These methods include precedence diagrams, network on arrow, PERT and others. They used different notation, but they enabled the planner to identify the Critical Path through a project.

The Critical Path is the series of tasks that must finish on time for the entire project to finish on schedule. Each task on the critical path is a critical task. You can also think of it as:
  • the longest path from start to finish
  • or the path without any slack,
  • the path corresponding to the shortest time in which the project can be completed.
Let me explain this using a simple example:

the image below is a precedence diagram which shows the order in which tasks must happen to get to project completion.
simple precedence diagram used in critical path analysis
There are three streams of activity happening in parallel if you add up the duration of each workstream you can easily spot the critical path.
  1. Workstream 1 - A2, B5, F2, G1, H1 = 11
  2. Workstream 2 - A2, C2, I6, G1, H1 = 12
  3. Workstream 3 - A2, D2, E1, J3, H1 = 9
If any tasks on workstream 2 take longer than expected there will be an immediate impact on the project end date. However, if task D on workstream 3 took 4 days instead of 2 days there would be no impact.

We can now see how important the critical path is to understanding the relationships within a project and to get you to the correct project end date.

CPA is also vital in calculating the impact of changes during your project for example, if task I in Workstream 2 is delivered in 4 days CPA enables you to immediately see the improvement in the project end date, but also to see the new critical path, which would be workstream 1.

Let's look at why fixing start and/or finish dates is a problem for CPA. Put simply,
fixing start and/or finish dates breaks the Critical Path because it prevents the project manager from seeing the impact of changes in duration.
For example: if the finish date of G is fixed and A, B, C, F or I reduce in duration there won't be any impact on the project end date. On the other hand if A, B, C, F or I increase in duration there also won't be any impact on the end date.

Basically if a Project Manager fixes a task date their plan could quickly show an inaccurate end date.

Reason number 3: The Project Manager doesn't understand how MS Project handles fixed start and finish dates

If you manually set a start or finish date MS project will create a constraint against the task.
Constraints fix a task in relation to a particular date.
There are eight constraint types in Microsoft Project. The default type is 'As Soon As Possible'. This is the only constraint type that allows a task to be scheduled basis of its duration, resource(s) and dependencies, rather than against a particular date. The other constraints fix a task to a particular date.

Why is this a problem? Let's look at an example.

Say the estimate for task A reduces from 4 days to 3 days. Task A is on the critical path so that reduction should pull the project end date back by 1 day. However, because there is a 'start no earlier' constraint against Task A there will be no impact on the project end date.

For more information on how to use constraints in MS Project see Project Constraints and Common mistakes in using Microsoft Project Constraints

MS Project -fixed start and finish dates - references

Dennis Lock, 1996. Project Management , 6th ed. Aldershot:Gower Publishing Limited. Latest edition Project Management from Amazon.