The Case of the Broken Task in Microsoft Project

A few months ago, a colleague expressed concern to me that when a tasks duration was reduced, the start and finish dates for subsequent tasks weren’t reflecting the change.

Figure 1: Here’s where we were…

The Case of the Broken Task in Microsoft Project

When the duration of the “Plan” task was reduced to one day, the “Build” task was still reflecting the old start date. Why?

Figure 2: …but when we reduced Plan by a day, Build didn’t shift.

The Case of the Broken Task in Microsoft Project

To validate the completeness of the schedule, I asked three questions about the schedule:

1. Is the project schedule set up from project start date or project finish date? To find out, I opened the “Project Information” dialog box (Project | Project Information) and found that the project was scheduled from “Project Start date.” This was critical to know. If a project is scheduled from “Project Finish date,” then by default all the tasks would be scheduled “As late as possible.”

Figure 3: Scheduling from project Start date.

The Case of the Broken Task in Microsoft Project

2. Are the tasks properly linked to each other? I viewed the network diagram of the schedule (View | Network diagram) and found it was closed. The right critical path would be identified by project only if the dependencies between tasks were logical.

Figure 4: A view of the links between tasks.

The Case of the Broken Task in Microsoft Project
3. Are there any schedule constraints attached to the task? I checked out “Indicators” to find any constraints. Bingo! The task information for “Build” indicated a “Start No Earlier Than” constraint, which was set, preventing the task from starting earlier.

Figure 5: The Indictators column provides clues about schedule constraints.

The Case of the Broken Task in Microsoft Project

Figure 6: A drill down on that task divulged the constraint.

The Case of the Broken Task in Microsoft Project

To solve the problem, I changed the “Constraint type” of “Build” task to “As Soon As Possible” and then checked to see if the schedule was now flexible. Yes, it was!

Figure 7: Problem remedied.

The Case of the Broken Task in Microsoft Project

Lessons Learned

I can extrapolate the solution provided in general to the following principles:

  • Create a unique deliverable. Each task should create a verifiable, tangible deliverable.
  • Set up a closed network diagram. All the tasks in a schedule expect the first and last task to have at least one predecessor and successor.
  • Minimize date constraints. Add date constraint (Start-No-*, Finish-No-*) to a task only if it is dependent on a non-project activity outside the control of the project management team, such as approval of government order or software installation by vendor.
Next Webinar

Microsoft Project Practice Exams -- The Good, the Bad and the Ugly

Written by Sai Prasad
B Sai Prasad, PMP®, PMI-SP®, MVP Project, Senior Manager - Learning & Development, has been with service provider Cognizant Technology Solutions India Pvt. Ltd since 2001 where he was named winner of the company's Global Trainer of the Year award. He has spent 13,000-plus hours in mentoring, coaching, training 9000-plus practitioners on project management topics ranging from project management concepts, project risk management, project scheduling, Microsoft Office Project® to software estimation techniques. He is a Champion of Project Management from PMI India and also Associate Champion Advisory Committee, PMI India. He is awarded the Champion of the Quarter (Q4 – 2012) and Delivery Excellence Award (2011-2012, 2012-2013) from PMI India. He's also the editor of the project management book, Forecast Scheduling with Project 2010. He is a Microsoft Certified Technology Specialist (MCTS) in Project 2010. He is the leader of the MPUG Chennai India Group to promote and help practitioners on how to effectively use Microsoft Office Project.
Share This Post
Have your say!
00

Leave a Reply