Ron from Cleveland, OH asks: Is it a good practice or bad to link summary tasks?
Answer: In general I don’t believe that it’s a best practice to link summary tasks within a work breakdown structure (WBS). Here are some of the reasons:
- It’s the detail tasks and the milestones that move a schedule ahead and not the summaries. Summaries can’t be tracked and shouldn’t have resources assigned to them. They’re not real tasks so much as subtotals and/or titles.
- If you try to track a summary task, it will be right only when there’s either zero percent or 100 percent completed on the detail tasks. This occurs because there’s a consistent recalculation of the summary task totals by default based on changes to their member tasks.
- Linking summaries can cause errors in the schedule that might be hard to trace.
- Linking summaries means that the entire grouping of tasks must be completed before the next grouping can start.
This last point brings up an interesting idea: Consider the application of some agile-based Scrum scheduling methodology to your project management efforts. In Scrum, a sprint (a period of two to four weeks) is always completed within a set timeframe before the next sprint can start. If any of the work in the first sprint doesn’t get completed, that work is moved over to the subsequent sprint. Each sprint is made up of “stories,” tasks scheduled to be completed in that two-, three-, or four-week section.
I would recommend using the WBS structure with milestones at the end of each summary grouping, as shown in Figure 1. The tasks within the groupings should be linked to the ending milestones because completion has the ability to push the milestones. Using this structure will also allow for generation of milestone or summary management reports in order to show the progress of the sprints.
Note that I’ve placed a deadline after each milestone. During tracking of the tasks, the goal is to ensure that the milestone arrow won’t cross the green arrow (deadline) if it does, the scheduler will be alerted. In addition, adding the deadline will allow users to monitor the total slack column to see when the slack goes negative and they’re approaching the danger of missing a deadline.
Also during tracking, if the remaining work for a task is increased, the result could be that the schedule is pushed past the two-, three-, or four-week gates and the deadline indicators would alert the scheduler to this problem as well.
Figure 1: Applying Scrum development techniques to project scheduling.
Figure 2 shows an example of the rolled up milestone report, which could be used for management reporting. To apply the milestone filter, click on Project | Filtered for | Milestone. To remove the filter, press the F3 key.
Figure 2: A roll-up of milestones.
Of course, there’s a lot more to managing a project using Scrum methodology than what I show here. But I hope these examples give you some scheduling ideas for predicting the project’s critical path and monitoring its progress.
