Take Back Control of Deadlines and Constraints in Your Schedule

We frequently see dates being given or set before the project is planned out fully or before execution starts. Some dates are contractual in nature, or given to us by the sponsor or client. They may even be government regulatory dates. Either way, these types of dates should always be considered as ‘commitment’ dates for scheduling purposes and should be designated as Deadlines. Other dates are based on real ‘restrictions’ to scheduling, such as planned maintenance windows, or deliveries of materials without which we can’t start the work, or perhaps training classes with external instruction and room bookings; these types of things should be designated as Constraints. The key is to understand which dates are ‘Commitments’ and which ones are ‘Restrictions’ and apply the appropriate technique. As a rule, any commitment dates given to the project manager should never be entered as anything other than a ‘Deadline’ in Microsoft Project. Dates that carry restrictions, on the other hand, can often be entered as ‘Constraints’. You want to avoid constraints as much as possible and use deadlines instead to ensure a proactive schedule.

Deadline and Constraint Explained

Let’s take a quick look at the potential implications of using the wrong technique. In this example below, we have a portion of the schedule that shows us deploying the new system to production. We have been told that we need to be live by October 26^th, so we’ve set a deadline accordingly, as represented in the Gantt Chart by the green arrow.

You’ll also notice that we’re currently scheduled to go live on October 20^th, which is 4 days before our deadline, so we’re in good shape with some contingency built in. Now, let’s say that we either run late at some point in the project, or perhaps we get some new information that requires us to increase the effort to deploy the system to production. It’s now estimated that it will take 10 days instead of 4, so our new forecast date is October 28^th. Since we used the deadline technique, we can clearly see that our ‘Total Slack’ is -2 days, which means we’ll miss our deadline by 2 days, if we don’t take corrective action. We can also see that we’re 6 days off from our original plan, and the indicator column shows a warning icon that we’re missing our deadline.

We have all the information we need to take corrective action on the critical path of the project, and the milestone will report accurate status up to executives based on the current schedule circumstances. If we had modeled the same scenario with a constraint, which many project managers do, then we’ll report the wrong milestone date and the schedule will show that we have no Finish Variance, neither of which is true, as we’re 6 days off. Using constraints in the wrong places creates a lot of manual maintenance in the schedule and leads to inaccurate reporting, so use them very sparingly and only when you are dealing with a true restriction.

Creating a Deadline

Let’s take a look at how to set a Deadline. On our project, the sponsor has asked that we have the Project Management Plan complete by February 12^th. To set a deadline, we find the easiest method is to ensure that the deadline column is showing in the current view, but deadlines can also be set on the Advanced Tab of the Project Information dialog. To set the deadline, we simply select the date from the calendar in the Deadline cell.

You now see the deadline in the Gantt chart, and since we’re scheduled to finish one day earlier, there is no warning in the indicator column.

Constraint Types

While there are 8 entries in the ‘Constraint Type’ drop-down, only 6 of them are restrictions to scheduling and true constraints.

The first two options, ‘As Soon As Possible’ and ‘As Late As Possible,’ represent the default scheduling method and schedule either from the project start forward or from the finish date backwards. Your default should always be ‘As Soon As Possible’. The next two entries are fixed constraints, where either the Start or the Finish date is locked down. We recommend that you primarily use ‘Must Start On’ for your fixed constraints and then set the duration (or work) accordingly. The next four entries are one-sided constraints, where you can lock down the start or finish to be either no earlier or no later than a certain date. Here, we strongly recommend that you use only ‘Start No Earlier Than’ for any external dependencies or deliveries and so on. We’ve seen many project managers get in trouble with the other one-sided constraints. They sound tempting, but you will end up hard-coding your schedule most of the time if you use them. So, if you encounter a true restriction to the scheduling on your project, please consider using either ‘Must Start On’ or ‘Start No Earlier Than’ and set the appropriate date.

Setting a Constraint

As discussed earlier, constraints should be used for restrictions to scheduling, which is often an external dependency of some kind. In other words, if you are relying on a vendor or business user to deliver something to your project and you don’t “own” these resources or their time, you can use a constraint to model this relationship. I like to make these stand out, so I actually write “EXTERNAL DEPENDENCY” in capital letters. It’s a great way to track external factors that may impact your schedule. In our case, we have a business user who is supposed to complete the Project Risk Calculator, and we can’t get the business case approved until we have this, so it’s definitely a restriction to our scheduling. In speaking with the business user, we have been promised this risk calculator by January 8^th, so I will go ahead and choose the constraint type of ‘Start No Earlier Than’ and set the date to January 8^th directly in the view with the appropriate columns showing. This way, the milestone could get pushed to a later date if there are other dependencies impacting it, but we know this is the earliest we’ll receive it. You can see the calendar icon in the ‘Indicator’ column, which just reminds us that we have a constraint here.

Conclusion

To conclude this discussion, we will review a few more examples of when to use deadlines and constraints.

• We have a sponsor asking us to have the scope document submitted for approval by October 27^th. The solution here is to use a deadline, so that we can track whether we are on track and see where to take corrective action.

• A vendor is promising delivery of roof tile by a certain date. The solution here is to use a ‘Start No Earlier Than’ constraint, so we can start laying the roof tile any time after the delivery.

• We have hired a trainer to come in and teach our project managers. We also have a room booked at a local training facility, so we will use the ‘Must Start On’ constraint with a fixed duration task.

You will likely be tempted to use constraints throughout your schedule, but be very careful to ensure that it is truly a restriction to scheduling before doing so. Try to use Deadlines as much as possible, as it will provide far more scheduling flexibility.