Common mistakes in using Microsoft Project Constraints

This guide is continued from Part 1 Project Constraints - what they are and how to use them.

WARNING! Project Constraints have a valid part to play in project planning, but they can also be created by mistake with dangerous knock on effects. Read this guide to Microsoft Project constraints for project planners and project managers. What they are and how to use them and common mistakes.

Project Constraints can be useful and have a valid part to play in project planning. However, they can also be created by mistake with dangerous knock on
In Microsoft Project constraints can be used to create a link between a task and a particular date. By default all tasks are created with the Constraint type ‘As Soon As Possible’. This allows Microsoft Project to schedule a task on the basis of its duration, resource(s) and dependencies, rather than against a particular date.

A plan with lots of constraints e.g. 'Start No Earlier Than' or 'Must Start On' could be unworkable because the constraints will:
  • Break the Logic - The order of tasks (the logic or precedence) is broken. Tasks are scheduled by dates rather than by their predecessor
  • Break the critical path - Tasks are scheduled by date so it is impossible to identify the Critical Path
  • Show unrealistic dates - Tasks will be forced to start and/or end on a particular date. This simply may not be realistic.
  • Prevent automatic rescheduling - Constraints prevent Microsoft Project from rescheduling automatically. This means that the impact of change e.g. early finish of a task will not be reflected on the schedule.
As a best practice set all tasks to start 'As Soon As Possible'. Only set another constraint type if you know the impact it will have on your schedule.

Beware of accidentally setting Project constraints

Constraints can be set in a few ways including:

  1. Deliberately setting a Constraint by clicking on a specific task, selecting the Advanced tab and setting the constraint type and date.
  2. Accidentally setting a constraint by manually setting or changing start or finish dates
  3. Accidentally setting multiple constraints by copying and pasting tasks and including their start and finish dates
Number 1 is most likely a deliberate and considered action taken by an experienced project planner.

2 and 3 are likely steps taken by someone inexperienced who doesn't understand the impact on the schedule. For example, copying and pasting tasks will cause multiple task constraints to be set which will potentially break the critical path.

Manually setting or changing a start or finish dates

Microsoft Project and other project planning software is designed to carry out complex calculations that Project Managers used to have to do by hand.
The idea is that you input:
  • what you need to do,
  • in what order you need to do it and
  • how long it will take.

The software will then calculate start and end dates and the critical path for the project.

Project Managers who are new to Microsoft Project will often try to set start and end dates themselves. This breaks the calculations and creates constraints against the tasks.

The simple project plan below has a project start date of 12/11/2012 and an end date of 14/12/2012.

Simple Project Plan

All of the tasks have finish to start relationships and there are no constraints. The problem is the launch day has to be on the 13/12/2012. The venue is already booked and the press releases have gone out. This should prompt the Project Manager to investigate legitimate ways to reduce timescales.

However, it can be tempting simply to force the plan to meet the deadline, by changing the start and end dates.

Here is an example:
Firstly the Project Manager changes the start date of Prepare for launch to 09/02/2010.

Setting Microsoft Project Start and end dates

If they are using Project 2007 they will get a warning message.

Project Planning Wizard Warning message

If they continue the link to the tasks predecessor ‘Train users’ will be removed and in this case a ‘Start No Earlier’ than 09/02/2010 constraint is set.

Contraint breaks dependency in MS project

Here the existence of the constraints is less of a problem than the fact that the Project Manager is attempting to force a task to start earlier than the finish of it's predecessor. This breaks the logic of the project plan. Unless the Project Manager takes some other legitimate action to shorten the timeline the deadline probably won’t be met. In addition the dependency between ‘Train users’ and ‘Prepare for launch’ has been lost, this means that even if the Project Manager found a legitimate way to reduce duration earlier in the plan the reduction would not be reflected in the start date of ‘Prepare for launch’.

I have seen numerous examples of project plans that are riddled with constraints. If you see this you should be concerned.
It suggests that the Project Manager may have manually set start or finish dates for activities. This may be because they don't understand how to use Microsoft Project's automatic scheduling capabilities or perhaps they have attempted to force the plan to meet an impossible deadline.

Copying and pasting project tasks

This example is from a project plan produced by one of my clients.

Copying and pasting project tasks
Here the Project Manager copied and pasted tasks into Microsoft Project, causing a series of ‘Start No Earlier’ constraints to be set. The problem is that the tasks won’t respond to improvements in the schedule.
For example ‘UAT prep’ is dependent on ‘Tester Training’ which has a planned duration of 2 days. If the client finds a way to reduce the time it takes to train the trainers from 2 days to 1 day then UAT prep could start earlier. However, because of the ‘Start No Earlier’ constraint ‘UAT prep’ will remain scheduled to start on 18/03/2010 and the improvement won’t impact the plan.

The next time you are working with a supplier or client check their project plan and look out for the constraints.

There might be a problem if you see:
  1. several tasks, one after the, other all with constraints against them.
  2. several constraints dotted about the plan

Removing all Project Contraints automatically

Jack Dahlgren has written a macro which removes all contraints in Microsoft Project automatically, see Microsoft Project vba

Note on Constraints in Microsoft Project 2010

Microsoft Project 2010 provides some helpful tools to help planners understand the impact of constraints on project scheduling. The Task Inspector shows the factors affecting an activity calling out the constraint type and the task predcessors.

Microsoft Project 2007 uses auto scheduling by default, but also enables Project Managers to take actions which break the automatic calculations inadvertently risking the viability of the plan. Project 2010 reduces this risk by making the choice between manually or automatically scheduling a task explicit.

How to create a Project Constraint

Read more guides on using Microsoft Project