how to flag tasks in a plan which have a relationship with a specific section

[Miles_Goodchild]

I have a complex plan and am looking to extract some sections of it into sub plans. I don't like links between plans (preferring to manually control these using named dependencies). Before I just rip out a section of the plan I prefer to check to see what relationships the rest of the plan have on this section.

To do this I have designed a simple highlight filter that is meant to highlight tasks that have a dependency on a defined section of the plan. The filter is:

Predecessors - is less than or equal to - "less than:"? (enter 12)

AND Predecessors - is greater than or equal to - "greater than:"? (enter 9)

This seems to work most of the time however a task that has the predecessor 10,2 doesn't trigger the highlight. Changing it to 10 does trigger and then when I change it back to 10,2 it stays triggered! Note that I am re-applying the filter with each change.

I am not used to MSP being inconsistent in this way, I would have expected the 10,2 to trigger in the first place OR not trigger the second time.

Note that most tasks have multiple dependencies and this doesn't appear to impact the filter.

Does anyone know what is going on here? Do you have any tricks or techniques to identify the impact of a section of the plan before removing it?

TIA

[#2]

@Miles_Goodchild,

Sorry but I can't replicate the filter issue you describe. I create a simple plan with the highlight filter you specified. Here is the plan.

And this is what I get when the highlight filter is applied. It doesn't matter is the predecessor on task ID 11 is changed, the filter still works as expected.

However, if I were trying to isolate a group of tasks in a large plan for copy and paste to a new plan, I would probably use the Marked field or a Number or Flag field in a filter rather than attempting to filter on predecessors. That might be an option to consider.

John

[#3 · Accepted solution]

@Miles_Goodchild 

I'm surprised that your filter method "seems to work most of the time." It would certainly bog down in any complex project, where pure "waterfall" logic is rare.  For other tricks or techniques, here are three views generated using the free edition of BPC Logic Filter. (Disclosure - I developed the tool for my own use; others license it from my company.  Reference to commercial add-ins is discouraged here, and I show it only because this functionality is free and available to non-registered users after the trial expires.) The first view is a highlight filter - using John's example - to highlight the predecessors and successors of the selected tasks (IDs 9-12).  The second is a grouped arrangement of predecessors, selected tasks, and successors.  The third ties the selected tasks individually to their predecessors and successors.  Good luck. tom

[#4]

John
I tried re-starting my machine and still have the same issue (filtered for <=12 and >=9
https://imgur.com/mLJZmUf
This is really odd.
How would you use the Marked or Numbered field? Would you have a test in there to see if the dependency contains items in a hardcoded range?

[#5]

Tom
I personally have no issue with people pointing to useful software but then I'm biased as I wish I could boast about my software to automate the production of Plan on a Page reports which I am very proud of 🙂
With the tool you mention does the highlighting "go away" if the focus shifts from the rows that you have highlighted (in your example 9-12)? This is the major disadvantage of the built-in functionality in MSP as you need to keep re-selecting things when you have dealt with each of the findings.

[#6]

Miles,
The tool I referenced uses flag and text fields to build the view. Unlike task paths, those persist through selection changes.

[#7]

very cool

[#8]

Miles,
I'm not sure why it isn't working for you, perhaps there is some subtle artifacts of your more complex plan than the simple example I used.

I would simply use the Marked field in a highlight filter, nothing more. It looks like Tom has taken the process much further and If that gets more of the information you want, I'd go with Tom's app.

[#9]

There are a couple issues for the OP.
1. The filter is based on the "Predecessors" field, which is itself a string of characters summarizing an indefinite number of dependency objects. With only one number (i.e. no commas) in the field, Project easily identifies the sole dependency with a Predecessor task ID to be evaluated. With commas, a filter seems to see only the first element in the list, i.e. the 10 in "10,2." (A flag formula using the same criteria won't even see that, instead just seeing a text string.). The result therefore depends on the order of entry of the predecessors. I.e. "10,2" and "2,10" are logically identical, but they will be evaluated differently by both filter and flag.
2. Modifying the pedecessors string directly can be a little flakey. As a rule, it's better to delete, recalculate, and reenter the string, IMO. (Even better to do the same thing in the predecessors table.) I'd suspect the apparent flakiness of the highlighter update is related to this.