How many times have you gone into a consulting engagement and found a Microsoft Project plan that looked something like Figure A? This kind of formatting is common among software development houses that use an iterative design/build methodology.

Figure A

While it’s hard to argue with the logic of a plan like this, it’s hardly ideal for finding your way through the project plan once you start applying filters or views that don’t show the full task hierarchy. Figure B shows the same project in the Resource Usage view. This shows how the schedule can become difficult to use once you get resources assigned. As you can see, the same task name shows up multiple times for a resource. It would be very difficult to tell which phase or iteration each task belonged to. Although this view is a great way to see a project broken down by the resources and the tasks to which they are assigned, the naming scheme in this project will just not do.

Figure B

I’ll show you a Microsoft Project macro you can keep in your toolkit to help you clean up this kind of project plan when you go on-site with a customer.

Option 1: Rename the tasks
The first and most attractive option is to just rename the tasks to include the name of their summary task. The macro in Listing A will look at each task in the project and check to see that the task is not a top-level task and does not have any child tasks of its own. If those conditions are both true, the macro will rename the task to this format: <name of parent task> | <current name of task>. If the task is a top-level task or has subtasks, the name will not be edited. The resulting task names for the example project are shown in Figure C.

Figure C

The macro explained
Line 100 starts a loop that will iterate through every task in the active project.

Line 110 tests the current task object to make sure it’s not a blank line. A blank line would cause the code on Line 120 to cause an error.

Line 120 tests the current task object to see if it has any subtasks. The number of OutlineChildren is equal to the number of subtasks a task has. Another way to test this would be to test for tskTask.Summary = False, but since we’re working with the OutlineParent and OutlineLevel, I decided to use the OutlineChildren method. This line also tests the task to see what outline level it’s on. The OutlineLevel property of a task is equal to the number of “indentations” it is from the top level. An OutlineLevel of 2 means that a task’s OutlineParent is a top-level task (OutlineLevel = 1).

If the statements on Line 120 are both true, the code on line 130 will edit the task’s Name property to be equal to the name of its OutlineParent and its current name, separated by the pipe character.

Lines 140 and 150 just end their respective If statements.

Line 160 starts the For loop over again if there are more tasks.

One possible reason to edit this macro for your own use is if you need two levels of outline parent’s names in the task name field; you could edit line 130 to look like this:
tskTask.Name = tskTask.OutlineParent.OutlineParent.Name & “ | “ & _
tskTask.OutlineParent.Name & “ | “ & tskTask.Name

This new line will make the task’s name include the name of its parent and its grandparent.

Option 2: Add the new name to a custom field
Some clients won’t want you to rename the tasks. If this is the case, you can easily edit this macro to add the new multilevel name to a custom field instead of to the task’s name field. To do this, just edit Line 130 to something like this:
tskTask.Text20 = tskTask.OutlineParent.Name & ” | ” & tskTask.Name

Note that instead of tskTask.Name, this line assigns the new name to tskTask.Text20. This new line will place the new name into the Custom field called Text20. You could choose to use any of the 30 text fields for this purpose. Then you could add this custom text field to any view and use it as a reference so that it is clear which “Design” task is being referred to in the view.