0

In Defense of Hard Constraints…

Bridget Fleming 5 Comments 0 like Articles
3/3 Articles Read This Month

Unlock Premium Access

$129

Annual Membership

Save 15% annually

Join Now
  • Access 100s of PDU's
  • Expert Articles Access
  • Resource Downloads
  • Live Weekly Webinars
  • On-Demand Webinars
  • Training & Courses
Written by Bridget Fleming
Bridget Fleming, PMP, PMI-SP, MCP has been in project management and scheduling for over 30 years, working with Microsoft Project since 1994 and Project Server since 2002.  As the founder of PMM, a project management training and consulting company, she has provided implementation support, process definition, user support and training for Microsoft Project and Project Server.  Bridget ran a Microsoft Project helpdesk for 15 years that provided support for a Fortune 100 client with over 500 users and has trained thousands of users in Microsoft Project and Project Server.  Bridget was a core team member for the development of PMI Practice Standard for Scheduling - Second Edition.  You may contact Bridget at bfleming@p-m-m.com.
Share This Post
Have your say!
00
5 Comments

  1. Nice article

  2. A variation might include one more task called “Schedule Margin” that links the final two milestones as FS. The Schedule Margin is under control of the Program Manager and is property of the program, not the individual task owners.

    If someone wishes to extend a task duration, they must negotiate the increase with the PM who then can reduce the Schedule Margin to assure timely completion. This becomes a positive control mechanism since it must be manually decremented. There are ways to float this duration, but I do not recommend it.

    Nice article Bridget!

  3. I couldn’t agree more with one thing: use constraints if you must, but monitor total slack. It’s the schedules without complete link networks that don’t understand slack where all of the surprise failure comes from. Now if we could all monitor total slack AS WELL AS peak units on the resource side life would indeed be good. Thank you for this Bridget.

  4. For the example you gave, where you are planning an event that must happen on a certain day, adding a hard constraint at the end of the project is appropriate. The problem is that 99% of the time, and especially with new users, they’re not used this way.

    The main advantage and purpose of MS Project is the calculation of the critical path. You enter your tasks, durations, relationships, resource assignments, etc. and it calculates the end date for you. When you enter hard constraints, you are interfering with that calculation. You would be better off using Excel instead because Excel won’t be calculating an end date that isn’t accurate.

    For someone in charge of planning an event — a wedding, a track meet, etc — adding a hard constraint the date of the event is the right thing to do, and as you pointed out, watch the float values. But for almost every other kind of project, stay away from hard constraints and allow Project to do what it was designed for.

  5. Hi Brian,
    I agree that constraints can be a problem when used incorrectly which is why I included the caution at the bottom of the article, and why I make sure my students understand how to use them correctly.

    I also agree that you want to let MS Project calculate the end date of the project which is represented in my example using the Project Complete milestone.

    However, I have found that most projects, whether it is a satellite launch or a software release or anything else, have a commitment date, promise date, contract requirement or whatever they call it that they are trying to meet. Given this, there needs to be a way for the project to measure progress toward meeting it. That is the value of the Target Complete with MFO.

Leave a Reply