Fixing task start and finish dates in project planning

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

Arbitrarily setting start and finish dates for tasks on a project plan can spell disaster for your project. Why? Well there are three reasons why a Project Manager would fix start and finish dates:

1. their managers or client are forcing them to make the plan fit a predefined timeline
2. they don't understand Critical Path analysis or have decided not to use it,
3. they haven't been trained on MS Project and don't fully understand the impact this will have.

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. If shortening the timeline is not possible it is our job as Project Managers 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.

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

Workstream 1 - A2, B5, F2, G1, H1 = 11

Workstream 2 - A2, C2, I6, G1, H1 = 12

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 took 4 days instead of 2 days there would be no impact. We can see how important the critical path is to understanding the relationships within a project and to get you to the correct project end date. It also vital in calculating the impact of changes during your project for example, if task I 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 - 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 the Project Manager will be working with a project plan that shows an inaccurate end date.

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

If you manually set a start or finish date MS project will create constraints against the task. Constraints fix a task in relation 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 Constraints: what they are used for and common mistakes