Part 1 of a series on customising fields in Microsoft® Project® to make working with project schedules more useful.
How do you set up a framework to enable you to quickly identify and review project schedules for common schedule setup logic errors, without having to deduce and apply complex combinations of filters? This is the approach I have used successfully on several programmes.
When you are pulling together a collection of project schedules to create a useful programme schedule, you may find that they are of variable quality, and may contain some fairly basic schedule setup errors. To avoid wasted effort, I recommend you first check incoming project schedules for commonly-occurring schedule setup logical problems. This post follows on from how to create a useful programme schedule by providing a bit more “nuts and bolts” detail on how to do this.
What we are looking for, where it comes from and why we don’t want it
Resources assigned to summary tasks
- Sometimes Project Managers (PMs) do this deliberately, e.g. to show a single person overseeing a group of tasks.
- More often, though, it is a “hangover” from an earlier schedule stage, where the PM assigned the resource to a single placeholder task that was later broken down into more detail. So you will probably find the same resource assigned to the lower level tasks as well.
- Unresolved, this can lead to artificial over-allocation of the resource and hence inflation of cost forecasts if the schedule is being used for this purpose.
- If the resource allocation to the summary task is being used to show ownership, it is probably better to use a separate (task owner) field for this.
Summary tasks with links (predecessors and/or successors)
- Sometimes Project Managers (PMs) do this deliberately, e.g. to show that something starts when a group of tasks has finished.
- More often, though, it is a “hangover” from a setup stage, where the PM assigned a dependency to a single placeholder task that has since been broken down into more detail.
- This can lead to complications establishing the critical path, and can place artificial constraints on tasks, so they don’t behave as you would expect.
- If the dependency on the summary task is genuine, I recommend that instead you create a “collector” milestone within the summary task, that has all the deliverables in the summary task as predecessors.
Tasks without successors (widows) or predecessors (orphans)
- Pretty much all items in a schedule should have at least one predecessor and at least one successor The exceptions are: summary tasks, a single milestone indicating the project start, and another milestone indicating the project end.
- If an item has no predecessors, then it is not dependent on any other tasks and could be done now. So why is it scheduled when it is, rather than now? Why haven’t we done it already?
- If an item has no successors, then its completion is not required by any subsequent items in the plan. So why are we doing it at all? can it be removed?
- Items missing predecessors and/or successors also will not be included in the calculation of the critical path through a project.
Placeholders in the past
- PMs sometimes use “placeholder” tasks (with default date and duration, and no predecessors or successors) as memory joggers for small tasks to be carried out at some point, or a task to be fleshed out with more detail later.
- By default, MS-Project schedules new tasks on the Project Start date (often a long time in the past) and gives them an arbitrary, default duration (usually 1 day)
- When enough of these are bundled with other, active tasks into a summary task, the non-completion of the placeholder makes the summary task look much longer than it should be, and woefully behind schedule. This is inconvenient if you are using schedule extracts for stakeholder communications, as it makes things look worse than they are.
- I recommend scheduling placeholders like these in the future using estimated dates and durations.
Item uses over-allocated resource
- If a PM allocates too much work to a resource, or a resource is assigned to too many tasks at the same time, the work cannot be performed as scheduled, calling forecast delivery dates into question.
How to do it: logic tests
So how do you easily detect these common schedule setup problems? The answer is to customise a Text field to display a very compact commentary resulting from some simple tests that look for common scheduling logic errors.
To do this, pick an empty custom task text field (in MS-Project 2016, select Project, Custom Fields), rename it something like “Schedule setup diagnostics” and click on Formula:
Enter the following formula:
IIf(([Summary] And (([Predecessors]<>"") Or ([Successors]<>""))),"SWL ","") & IIf([Summary] And ([Resource Names]<>""),"SWR ","") & IIf((Not [Summary] And ([Predecessors]="")),"W ","") & IIf((Not [Summary] And ([Successors]<>"")),"O ","") & IIf(([Start]=[Project Start]) And [Estimated] And ([Predecessors]="") And ([Successors]=""),"PIP? ","") & IIf([Overallocated],"UOAR ","")
Pay close attention to all the brackets and commas. You need them all, in that order!
This formula uses IF statements and text string concatenation to alert you with short text codes if items in the plan suffer from any of these logical schedule setup problems:
- SWR = Summary task With Resources
- SWL = Summary task With Links
- W = Widow (non-summary task without successors)
- O = Orphan (non-summary task without predecessors)
- PIP? = Placeholder In the Past?
- UOAR = Uses Over-Allocated Resource
Display the new column in your Gantt chart table (in MS-Project 2016, select Gantt Chart Tools, Format, Insert Column, and type the name of the new column, in this case “Schedule setup diagnostics”); any commentary generated by the formula will appear in this new column.
The presence of any of these codes should prompt a discussion with the PM, and preferably the adjustment of the schedule to correct the error (unless it was deliberate) and remove the flag.
So that’s my approach to automating MS-Project schedule setup diagnostics, learned through the experience of getting it wrong and coming up with a better way.
Is this approach useful to you? How do you check for consistent project scheduling logic? How do you check for consistent project scheduling logic like this? What do you use custom fields for? Let me know in the comments.
If you would like to have the benefits of an approach like this but prefer not to have to worry about this sort of techy stuff, why not talk to us about taking care of it all for you on your next big project or programme?
® Microsoft and Project are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.