Why not assign resources to summary tasks?

[Anonymous]

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?

[Heather Agee]

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.

[Josh Logan]

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.

[Bill Stewart]

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.

[Daryl Deffler]

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.

[phil planner]

I’m also coming round to the idea that assigning resources to a summary task is not always a bad thing.
If i may give my example.
We work in a staged project process with gates at the end of each stage. THe schedule is mostly constrained by the technical tasks performed by the technical team and third parties. These tasks are scheduled in detail and resources assigned at the task level.
However, the project manager and project support will typically be assigned to a small number of projects and the effort of each project estimated at the stage level, ie stage 1 concept may only require 20% of a project support but stage 9 delivery may need 100%. Similar levelling for a PM.
These resources (especially project support) will not have their activities scheduled in detail as this needlessly complicates the schedule. Instead, why not assign these resources at the stage summary task?
From reading around the subject i have seen no good reason given.

Heather, you mentioned that if you are only resourcing at this level, you should not plan any in any further detail. I think this is not applicable in the example i give. There is definite need to schedule the technical tasks and their interdependencies in detail and i would not recommend assinging the resources at summary level there, but there is little need to schedule in detail the administration activities of project support. The other points you mention regards statusing is also not relevant to the example i give regards admin and management activities – if you are not scheduling these tasks in detail (and i argue there is little need in the projects in support)

Josh – you mention having to calculate by hand the amount of work, many organisations estimate a level of effort for project support without calculating their individual tasks.

Daryl – good point regarding timesheets, but only a small percentage of Microsoft Project implementations use timesheets. Still good to know

[Author]

Posts