It is our practice to assign 1 resource per task when planning our IT projects.
What is the “Best Practice” in assigning resources to tasks?
I can see where assigning 2 or more resources to a single task may complicate the project plan & scheduling.
Can anyone quote an on this? Saving Changes...
Sort By:
Hans RobbersSenior Director| SalesforceVlissingen, Netherlands
Kenneth
Interesting question. The reason to have one resource per task is to ease the tracking and the scheduling. More resources per task will automatically lead to schedule the task when all the resources are available. In case of key resources this might lead to a stretch of the project plan. Having one resource per task will avoid this "invisible" constraint.
If the resources are truly depend on each other you can always arrange this with task constraints..
For me there is one exception . Team meetings since these are dependent on the availability of all the team members
Hopes this helps
Hans
Saving Changes...
Hans RobbersSenior Director| SalesforceVlissingen, Netherlands
Kenneth
Interesting question. The reason to have one resource per task is to ease the tracking and the scheduling. More resources per task will automatically lead to schedule the task when all the resources are available. In case of key resources this might lead to a stretch of the project plan. Having one resource per task will avoid this "invisible" constraint.
If the resources are truly depend on each other you can always arrange this with task constraints..
For me there is one exception . Team meetings since these are dependent on the availability of all the team members
Hopes this helps
Hans
Saving Changes...
Hans RobbersSenior Director| SalesforceVlissingen, Netherlands
Kenneth
Interesting question. The reason to have one resource per task is to ease the tracking and the scheduling. More resources per task will automatically lead to schedule the task when all the resources are available. In case of key resources this might lead to a stretch of the project plan. Having one resource per task will avoid this "invisible" constraint.
If the resources are truly depend on each other you can always arrange this with task constraints..
For me there is one exception . Team meetings since these are dependent on the availability of all the team members
"best practices" suggest that work at the task level represents 40 hours of labor. Since you were non-specific on the content or complexity of the work effort, it can be appropriate to PLAN 1 headcount per task.
Second, assigning multiple resources doesn't necessarily mean an improvement in the speed of delivery, or quality of deliverable.
Lastly, increasing the number of assigned resources creates additional communication demands on the members of the team as they have to coordinate more activities .
Hope this helps.
Don Saving Changes...
Prasad VelagaExecutive| OptisolCollege Station, Tx, United States
Kenneth,
Planners assign more than one resource to a task mainly for two reasons: (1) the task cannot be performed by a single resource and (2) duration of a high priority task needs to be reduced by assigning more than one resource and possibly delaying some other tasks (provided that the task can be shared by two or more resources).
Good scheduling software automatically generate a resource-leveled schedule even for multi-resource assignments to tasks in either case.
Saving Changes...
Andrew MakarProgram Manager| AMAKAR LLCOakland Township, Mi, United States
I agree with Hans approach. I like to schedule tasks at the 40 hour level and sometimes even lower if I'm building a fixed work estimate. This allows you to track design, build and test activities for future estimation.
However, I still assign 1 task to one resource unless it is a review activity. For team meetings, I prefer to not include these in the schedule as it really is an operational task. Key meetings like tollgates or sign-offs are in the schedule, but my weekly governance meetings with the team and executive sponsors are all scheduled in Outlook...and not in the project schedule.
(I know ... I know the PQA police may come after me but the end goal is working software...not functional documentation)
I find that there are not many tasks that require two or more resources, other than meetings and reviews. For scheduling if I do get a task that requires more than one resource, I tend to split it so that each resource gets their won "part" of the task. This approach makes it very clear any resource conflicts or constraints. Saving Changes...
