Tagged: summary tasks
This topic contains 4 replies, has 4 voices, and was last updated by Daryl Deffler 3 weeks, 5 days ago.
- 06/09/2014 at 1:08 pm #116944
I keep reading that this is best practice, but I have not read solid reasons why. Say you have a summary task that contains 5 sub tasks, and you have individuals working on those sub tasks. Say you have one person that is just overseeing the work of these individuals. Their effort does not drive task completion at all, but you estimate that they are going to spend 20 hours supervising. Why not assign them to the summary task? Anything more detailed would be false detail.
Resons I have heard are that people forget that they are assigned to the summary and assign them to individual tasks as well. This isn’t a legit reason in my opinion. Don’t assume I’m going to make that mistake. Why go through the effort of creating a phase task or task that spans an entire summary task?06/09/2014 at 2:29 pm #116952
I think of a summary task as a container for other tasks…a file folder. If you were looking at a folder on your computer with a word document inside, you wouldn’t write your content on the folder, you would write it on the document inside the folder. Same concept here…we should think of the content landing at the task level, not its container.
I also would challenge you this way…if you want to have resources and dependencies at the summary task level, why even have the fidelity of the lower level tasks beneath it at all? You should schedule at the level where you want to manage the work. And if you’re doing that, your resources and dependencies should also be at that level. If you’re tempted to use summary tasks for everything, you may want to question why you have subtasks at all.
Also…if you are doing resource planning…especially if it leads to something like EVMS reporting, it’s important to assign people to the specific work they will be doing. When you implement Enterprise project and begin doing enterprise-level resource planning, you can even add resources to the Sharepoint Engine and have them status the tasks they are responsible for. Therefore you will want them to status at the task level, not the summary task level.06/09/2014 at 4:10 pm #116958
If one were to assign all the resources for a task to its summary task, then, at the very least, one would have to hand calculate the work and determine which period of time (month, week & etc. in which to record the planned work for the resources. This defeats the purpose of using a scheduling tool. Why not use Project to do that (of course, some manual work assignments may be needed for updates to tasks)?
Further, as stated by Heather, all the planned work is hidden in the summary task, and that makes it difficult to track status of each task, and to perform resource planning. If tasks slipped or needed changes to work or duration, this would make the schedule a nightmare to maintain. There would be no way to accurately maintain a baseline or to manage a project accurately.
This would be the equivalent of removing all the the gauges from a vehicle’s dashboard and driving by feel. How could you tell if the engine were overheating, or speed?
Even one task hidden in the summary task defeats the purpose of using a scheduling tool. Yes, it’s done, no, it’s not good practice.10/18/2019 at 5:38 pm #416679
Hi, the original poster has a really good point. And I am encountering it right now. And there is another issue.
In many places in my large schedule for a large project, the individual tasks overlap, but there is one manager. For example, there are lot of business process activities, many overlapping, under one Business Process summary task. To try and allocate 50% of the manager to the first part of an individual activity, then 33% to the last couple days, and so on, to achieve 100% leveled allocation across all the business process work would be a nightmare. I would have to divide up many of the individual tasks at the overlap point, making the project almost unreadable.
It is much better, clearer, easier, and more accurate to simply allocate the manager 100% to the entire summary task.
There is no problem, if you don’t allocate resources at both the summary and indented tasks. And honestly, I cannot imagine why you would make that mistake in the first place.
Hope this makes sense.10/23/2019 at 2:08 pm #416696
One additional consideration if you track actual time through timesheet entry in project.
When a resource is assigned to a summary task, that summary task will NOT appear on the resources timesheet since Project only shows the detailed level tasks. That’s part one of the issue.
The second part of the issue is that Project will “make up” timesheet hours for resources assigned to the summary task. Meaning not hours ever reported by resources. For example, if Bob is assigned to a summary task for 100 hours and there are a bunch of detailed tasks below it that resources are in process, with those resources entering actual work hours thru timesheet data. If the sum of all detailed tasks indicate that the entire block of tasks (under the summary) is 75% complete, then Project will magically add 75 hours to Bob, even if he didn’t work those hours. Why? because if all the detailed tasks are 75% complete, then Bobs work must also be 75% complete and Project will adjust Bob’s actual work hours to make that formula true. So it will give Bob 75 more hours of actual work.
Bob may have worked 40 hours that week on other detailed tasks, but because of this quirk, Bob could end up with hundreds of actual hours being reported that week depending on how many summary tasks he is on.
Bottom line, if you are using timesheets to track hours to accurately report project hours and costs, do not assign resources to summary tasks.