Home › Forums › Discussion › Inactivating Task causing Critical Path to Malfunciton › Reply To: Inactivating Task causing Critical Path to Malfunciton
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/