Inactive Tasks in Microsoft Project

Beware inactive tasks in MSP 2013+, especially if you use non-finish-to-start relationships.  

The other day Dominic Moss posted a nice Pulse article over on LinkedIn called Inactive Tasks – more than meets the eye.  I liked the article, though I pointed out some fundamental issues with Inactive Tasks that were introduced in MSP 2013.  [Note: the link takes you to a new, improved version of Dominic’s article; our original discussion was lost.]  Here’s a recap of the lost comments:

“Dominic, this is a nice write-up. I was an early adopter of inactive tasks in MSP 2010 for the reasons you mentioned. With MSP 2013, however, Microsoft introduced a substantial change to schedule calculation around inactive tasks – the program inserts a hidden FS link between inactive task predecessors and successors at run time. I imagine that change persists in 2016. It seems a large number of users complained about the logical consequences of inactivating a task – i.e. its successors lose their driving logical constraints and slide back to the project start date. While the change seems to make life easier for the complainers, users should recognize that inactivating a task does not reliably remove it from the scheduling calculations (except in MSP 2010). That defeats most of their benefits for my purposes….  I stumbled across that ‘feature’ by accident, when a client’s planners (newly upgraded to 2013) started getting different end dates than I was (on 2010) from exactly the same mpp file. We had a number of contingent tasks that were inactivated – some with FF links. MSP 2013 was replacing those FF links with FS links and driving out the project completion!”

So the conclusion is – Beware Inactive Tasks on MSP 2013+.

[Edit: July 2018 – having finally upgraded a dedicated machine to MSP Professional 2016, I can confirm that the program’s updated behavior is a bit more refined than I had experienced with MSP 2013.  In the absence of complications caused by lags and multiple calendars, the run-time adjustments generally comply with expectations of a “dissolved” activity.  That is, relationships are applied through a zero-duration inactive task – at least on the Forward Pass (the calculations leading to the Early Dates.)  This can still extend the scheduled project completion if the inactivated task… 1. was on the driving path to project completion, and 2. possesses reverse logic flow, as in the case of a driven finish and a driving start.  Unfortunately, all this sleight of hand seems to wreak havoc on the Backward Pass and the corresponding Late Dates; if the inactive task has a parallel logic path, the late dates (and corresponding Total Slack values) of its predecessors are typically incorrect.  Lags and multiple calendars make things even more complex.  We’ll have to address all these behaviors in the pending upgrade to BPC Logic Filter, our MSP add-in.]

2 thoughts on “Inactive Tasks in Microsoft Project”

  1. Hi, I have a task in a very large schedule (9800 tasks) that is greyed and crossed out. It was originally meant to be inactive but the “Active” column shows it as being active. It has 0% completion, but I noticed the original .mpp file had a baseline even though it was created as a proposal schedule and not a tracking schedule. Is this possible, and if so what are the implications.

    1. Hi Paxton,
      If the “Active” field for the task is “Yes”, then clearly the task is not inactive. Since it is grayed-out and struck-through in one of the Gantt chart tables, this may reflect a simple font-editing of the task row in the table. If so it’s easily reversed by restoring the default version of the table or re-editing the row.
      Other issues:
      1. Re. “originally meant to be inactive….” Not sure what you’re getting at here. With the exception of a couple edge cases I can’t recall, MSP will allow inactivation of tasks without progress. 0% Complete doesn’t necessarily mean no progress; there must also be no Actual Start date.
      2. In general, Task “Baseline…” and “Active” properties are mutually independent.
      3. Baselines get recorded all the time and for all sorts of reasons. Those are subject to management protocols rather than what is possible with MSP.
      Good luck, tom

Leave a Reply

Your email address will not be published.