Inactivating Task causing Critical Path to Malfunciton

[Zack Wilker]

I am using MS Project Pro 2016 and I have recently ran into a problem in one of my projects where I inactivated a task and the critical path was not being calculated like I thought. Here is an example.

Imagine we are building a house and the first task is to frame the house. The second task, lets say is to add electricity. The third is to add plumbing. and The last is to finish the rest of the house (its predecessors are electric AND plumbing, otherwise everything flows in that order). However, the couple decided that they wanted to become Amish and I therefore inactivated the add electricity task. The problem is that everything after add electricity is on the critical path but framing the house is showing that I have total slack which is not true as the longer it takes to frame the house, the longer the dates push out to finish the house.

Any ideas as to why this is?

[Anonymous]

Zack, I agree that doesn’t sound right. I do know that sometimes Project might result in some corruption (although very rare). Have you tried deleting and recreating the inactive task, or the framing task? Sorry, best I can give you right now. Otherwise maybe take a closer look at the task(s) and see if something else is coming into play. Did you level the project at any time? Sorry, just reaching. Hope that helps…

[Sai Prasad]

Adding to what Larry said, do you have any constraints on the first task or is it manually scheduled. If you could screenshot of the schedule, it can help to troubleshoot better. Meanwhile, you may want to look at my article https://mpug.com/articles/the-case-of-the-broken-task-in-microsoft-project/ on why this could happen

[Daryl Deffler]

Zack
When you inactivate a task, Project treats the task and all its predecessor/successor relationships as if they don’t exist.
For example, in a simple waterfall sequence of A-B-C-D-E, if I inactivated task C, project ignores task C AND the relationship between B-C and C-D. As a result, the task sequence now looks like A-B and D-E with no relationship between B-D.
Bottom line, when you deactivate a task(s), you need to make certain the proper relationships are added to cover any potential gap in the path. So in this example, you’d need to add the B-D relationship to re-establish the straight waterfall sequence.

Hope that helps

[Zack Wilker]

All tasks were auto scheduled and there were no constraints. With the newer versions of MS Project, I believe much of the waterfall relationships were corrected when inactivating tasks.

That being said, I believe the cause of the problem was due to what I would call a circular reference.

Here is the link to the original example: (Let me know if you have trouble viewing any of the images)

Here is the link with the original inactivation of the task:

The problem was that my “Finish House” tasks already established a relationship with the ‘Add Electricity” tasks due to the “Add Plumbing” task. Therefore, when I inactivated the task, resulted in an error in the total slack (see gantt chart). By removing the “Add Electricity” predecessor of “Finish House” allowed for the linking of tasks to properly work.

Here is the link for the correct file:

Zack

[Zack Wilker]

Apparently my links were not received (What is the easiest way to do this?). Try copying and pasting the text into your browser.

Here is the link to the original example: (Let me know if you have trouble viewing any of the images)
https://www.dropbox.com/s/ljjhyo0hyi5zvev/Project%20Example%20All%20Tasks.PNG?dl=0

Here is the link to the original example: (Let me know if you have trouble viewing any of the images)
https://www.dropbox.com/s/n5jp5ujtqcxn6xw/Project%20Example%20With%20Inactivated%20Task.PNG?dl=0

Here is the link for the correct file:
https://www.dropbox.com/s/gidjmkrx6p6r6xd/Project%20Example%20With%20Inactivated%20Task%20Correct.PNG?dl=0

Zack

[Thomas Boyle]

Zack,
In my opinion, your example is a very good illustration of the logical discrepancies that Microsoft introduced with their “fix” of Inactive Tasks beginning in MSP2013+. When introduced in MSP2010, inactive tasks functioned exactly as I expected, and as Daryl has so clearly described. Unfortunately, users who didn’t care about logical consistency or accurate Total Slack ultimately won the day, and their demands are what drives the current goofy behavior. (MSP seems to insert appropriate phantom relationships between the inactive task’s predecessors and successors at run-time, but there is no evidence that the same phantom relationships are properly implemented as part of a backward pass – the late dates of your framing task are incorrect.) This is one more reason not to trust Total Slack in MSP.
Good luck, tom

[Drew Hogenkamp]

Tom,

Since I’m relatively new to MSP, what’s the history behind why MS did this? You make it sound like inactivating tasks worked in the first place, so why was a “fix” necessary? What group of users don’t care about logical consistency or accurate Total Slack?

Thanks for your help!
Drew

[Thomas Boyle]

Drew,
I really can’t read MS’s mind, though my general impression is that they made the changes in response to user demand. I believed the functionality was originally introduced to provide an easy off/on switch for whole network branches of contingency tasks, what-ifs, and prospective de-scopes. For those purposes, the as-designed behavior was perfect in my view. E.g. if Tasks B1 to B12 are removed from the scope of the project (or have not yet been added to the project), then the rest of the schedule network needs to work perfectly in their absence; consequently, there may be some open-ended logic that needs filling. Other users, however, seemed to expect an inactive task to effectively lose its duration while keeping its predecessor and successor logic intact. (Keeping a task in the network but setting its duration to zero is a common way to handle de-scoped work in the absence of the feature.) There were certainly some public complaints among MSP2010 users that the as-designed consequence of inactivating a task – its successors naturally falling back to the project start date – was seen as defective.

“What group of users don’t care about logical consistency or accurate Total Slack?” Judging from these observations…Most.
Here’s a link to other discussion, including the changes from 2013 to 2016: https://boyleprojectconsulting.com/TomsBlog/2016/09/22/inactive-tasks-in-microsoft-project/

[Author]

Posts