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.