gevgar
asked on
Project 2007 applying work resource time spent to summary level tasks
Hi,
I need clarification on whether it is ok to assign work resources, and apply time to them, on summary level tasks.
I occasionally have problems with applying time spent to work resources and I was informed, by coworkers, that I should never assign work resources at the summary level as that can cause problems with Project 2007. Is this true?
Furthermore, I was informed that applying time to subtasks of summary tasks that have resources and time spent, which sometimes happens, is even more of a problem. Is this true as well?
Some background: I typically create a Gantt where the summary task is the deliverable and the subtasks are components of getting that deliverable done. When workers submit their timesheets it only lists the deliverable they worked on and not necessarily the actual subtask (my organization decided to save the workers time from having to fill in detailed timesheets at the subtask level) so I apply their time to the summary level.
Furthermore, there are times when there are subtasks that are also deliverables (sometimes summary level and sometimes not); so time will also be applied there. This is where the second items mentioned above comes into play, where I will, sometimes, apply time to a subtask of a deliverable if it is another deliverable (either a summary task or not).
Thank You
Gary
PS. I cannot find a zone for MS Project? has it disappeared?
I need clarification on whether it is ok to assign work resources, and apply time to them, on summary level tasks.
I occasionally have problems with applying time spent to work resources and I was informed, by coworkers, that I should never assign work resources at the summary level as that can cause problems with Project 2007. Is this true?
Furthermore, I was informed that applying time to subtasks of summary tasks that have resources and time spent, which sometimes happens, is even more of a problem. Is this true as well?
Some background: I typically create a Gantt where the summary task is the deliverable and the subtasks are components of getting that deliverable done. When workers submit their timesheets it only lists the deliverable they worked on and not necessarily the actual subtask (my organization decided to save the workers time from having to fill in detailed timesheets at the subtask level) so I apply their time to the summary level.
Furthermore, there are times when there are subtasks that are also deliverables (sometimes summary level and sometimes not); so time will also be applied there. This is where the second items mentioned above comes into play, where I will, sometimes, apply time to a subtask of a deliverable if it is another deliverable (either a summary task or not).
Thank You
Gary
PS. I cannot find a zone for MS Project? has it disappeared?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The needs of Management and PMO are ideally very similar but in reality they differ widely and dont lend themselved to good project management - been there :(
However you outlined a very clear requirement of what you want project to achieve so:-
1. Project plan with timeline and resources - I suggest you focus on how progress by the resources is reported and design your tasks to reflect that so you have an audit of timesheet to deliverable to MS project Task Actuals. Assuming you put dependencies and sesnibel estimates in you will get a good timeline with every task assigned a specific resource. Try to avoid putting mutliple resources on a task because actuals work at the task level - split the task into two parts instead and make their end dates interdependent if appropriate.
2. Provide a checklist of critical items. This is the one project will struggle with unless you are assigning resource and recording actuals against them. If this is a Checklist why not use the Notes or Text fields instead. If you have regular deliverables like this you can record them one in a Project template then add them in as required. All projects reports can be modified to output them so for a given deliverable(s) you could print a report for a resource as part of assigning the task and they can physically check it off as an addition to their timesheet if they want (and even record time if it suits them). This way you maintain the checklist and stand a good chance of collecting metrics which you can feed back into the Project Template against the Deliverable which will improve estimating in future.
3) if you have good procedures around alll the above then the project file plus the Template metrics will provide this
I appreciate its not going to be this straightforward but I have found that if you focus on whats needed to manage the project you can satisfy the other needs to a greater or lesser extent and justify any shortfall with the quality of the data you have collected.
Reg
However you outlined a very clear requirement of what you want project to achieve so:-
1. Project plan with timeline and resources - I suggest you focus on how progress by the resources is reported and design your tasks to reflect that so you have an audit of timesheet to deliverable to MS project Task Actuals. Assuming you put dependencies and sesnibel estimates in you will get a good timeline with every task assigned a specific resource. Try to avoid putting mutliple resources on a task because actuals work at the task level - split the task into two parts instead and make their end dates interdependent if appropriate.
2. Provide a checklist of critical items. This is the one project will struggle with unless you are assigning resource and recording actuals against them. If this is a Checklist why not use the Notes or Text fields instead. If you have regular deliverables like this you can record them one in a Project template then add them in as required. All projects reports can be modified to output them so for a given deliverable(s) you could print a report for a resource as part of assigning the task and they can physically check it off as an addition to their timesheet if they want (and even record time if it suits them). This way you maintain the checklist and stand a good chance of collecting metrics which you can feed back into the Project Template against the Deliverable which will improve estimating in future.
3) if you have good procedures around alll the above then the project file plus the Template metrics will provide this
I appreciate its not going to be this straightforward but I have found that if you focus on whats needed to manage the project you can satisfy the other needs to a greater or lesser extent and justify any shortfall with the quality of the data you have collected.
Reg
ASKER
Hi Reg, all of this is excellent information and I will digest and incorporate it into my planning.
2 more items I want to comment on:
1. In your first reply you indicated to a deliverable like 'desk' doesn't really make sense as it is an outcome and not the actual work. Agreed. unfortunately this is what the PMO office wants to see as the 'deliverable' because that was signed off on the scope.
2. In your second reply you indicate to try to put only one resource per task. Not readily possible. We have 35 staff in the IT department here and all of them could work on a task at any time. They all cover eachother, no-one is responsible for just projects; they all work on operations and projects as their time dictates. So, for example, there are 4 guys that have networking expertise and, when the project starts, one will be assigned to help figure out all the work to be done. They record that detail in the internal ticketing system (so you could say that the actual work, checklist, to be done is recorded in the ticketing system and not in the project - again, management expects everyone to live in the ticketing system and not the PWA site so that's why the project gantts are so basic). From then on it could be anyone in the networking group that could work on that deliverable. I get weekly updates on status (besides time entries) in the ticketing system but I have no control over who does the work. So my small tasks, like install the server in the rack, will often have the 2 hours of work done by 4 resources.
Anyway, I understand 100% what you mean and I will have to take a look at how I do the project gantt's and incorporate your great ideas but my main one right now is to stop putting resources and time on the summary level - I think that alone will help a lot as it will stop my project from crashing or causing wierd things to happen with the numbers.
Thank You Reg for all your help.
Cheers
Gary
2 more items I want to comment on:
1. In your first reply you indicated to a deliverable like 'desk' doesn't really make sense as it is an outcome and not the actual work. Agreed. unfortunately this is what the PMO office wants to see as the 'deliverable' because that was signed off on the scope.
2. In your second reply you indicate to try to put only one resource per task. Not readily possible. We have 35 staff in the IT department here and all of them could work on a task at any time. They all cover eachother, no-one is responsible for just projects; they all work on operations and projects as their time dictates. So, for example, there are 4 guys that have networking expertise and, when the project starts, one will be assigned to help figure out all the work to be done. They record that detail in the internal ticketing system (so you could say that the actual work, checklist, to be done is recorded in the ticketing system and not in the project - again, management expects everyone to live in the ticketing system and not the PWA site so that's why the project gantts are so basic). From then on it could be anyone in the networking group that could work on that deliverable. I get weekly updates on status (besides time entries) in the ticketing system but I have no control over who does the work. So my small tasks, like install the server in the rack, will often have the 2 hours of work done by 4 resources.
Anyway, I understand 100% what you mean and I will have to take a look at how I do the project gantt's and incorporate your great ideas but my main one right now is to stop putting resources and time on the summary level - I think that alone will help a lot as it will stop my project from crashing or causing wierd things to happen with the numbers.
Thank You Reg for all your help.
Cheers
Gary
ASKER
Hi Reg, thought I would, as a closing note, include a snapshot picture of my last project (upgrading our sharepoint environment to 2010). As you can see the resources at the bottom are more than one; furthermore, I always assign a 'role' to tasks as part of my estimating (so I don't assign a name but something like 'networking expert') which then gets removed once the time starts rolling in and replaced by the actual name.
Unfortunately another item that often happens then is that the resource's unit allocation goes through the roof when I keep applying they're time on a weekly basis, haven't quite figured out why that happens but it doesn't seem to affect the project itself so I haven't worried about it.
Another thing to keep in mind is that we have our projects setup to never allow duration to change as management always requires us to maintain our timeline once locked down (including at the deliverable level). if something falls behind or causes problems then they simply assign more resources to resolve it. (another reason people keep getting added). So I understand why the units keep going up because of the work, units, duration triangle in project. I also understand that sometimes a project looks really odd as we have a 2 day duration task item that took 10 people 60 hours but that's the way it is here.
Ps. In this particular screenshot you will note that the baseline estimate is way below the actual; in this particular deliverable we had a lot of issues so original time required was way underestimated.
Cheers
Gary
Capture.JPG
Unfortunately another item that often happens then is that the resource's unit allocation goes through the roof when I keep applying they're time on a weekly basis, haven't quite figured out why that happens but it doesn't seem to affect the project itself so I haven't worried about it.
Another thing to keep in mind is that we have our projects setup to never allow duration to change as management always requires us to maintain our timeline once locked down (including at the deliverable level). if something falls behind or causes problems then they simply assign more resources to resolve it. (another reason people keep getting added). So I understand why the units keep going up because of the work, units, duration triangle in project. I also understand that sometimes a project looks really odd as we have a 2 day duration task item that took 10 people 60 hours but that's the way it is here.
Ps. In this particular screenshot you will note that the baseline estimate is way below the actual; in this particular deliverable we had a lot of issues so original time required was way underestimated.
Cheers
Gary
Capture.JPG
Hi Gary
sorry I missed your comments because the question was closed so I stopped getting updates.
per your item 1 - 'Desk' as a task rather than a deliverable. - ultimately what you call a task is immaterial as long as you are consistent. You might want to think about using some of the 'spare' fields which project provides - this would let you define your tasks names but take (for example) TEXT1, change its name to 'Deliverable' and hey presto - PMO can see which deliverable the tasks amounted to
2 I agree is a little trickier so how about this:- Instead of assigning individuals to a task you are actually assigning a group to a deliverable. So have an 'IT NETWORK' group as the resource, give it an allocation limit of 400% (4 people) and then its less likely to be overallocated. The ticketing system will provide the audit trail of WHO did the work whilst project will total it up under IT RESOURCE and attach it to what Deliverable they worked on
The idea that duration never changes is plain stupid but I guess thats the environment you're in. In these circumstances I try to apply the 'Scotty' principle - as in estimate every task at the next unit of time above - hours will be like days
Good luck - and thanks for the feedback
Greg
sorry I missed your comments because the question was closed so I stopped getting updates.
per your item 1 - 'Desk' as a task rather than a deliverable. - ultimately what you call a task is immaterial as long as you are consistent. You might want to think about using some of the 'spare' fields which project provides - this would let you define your tasks names but take (for example) TEXT1, change its name to 'Deliverable' and hey presto - PMO can see which deliverable the tasks amounted to
2 I agree is a little trickier so how about this:- Instead of assigning individuals to a task you are actually assigning a group to a deliverable. So have an 'IT NETWORK' group as the resource, give it an allocation limit of 400% (4 people) and then its less likely to be overallocated. The ticketing system will provide the audit trail of WHO did the work whilst project will total it up under IT RESOURCE and attach it to what Deliverable they worked on
The idea that duration never changes is plain stupid but I guess thats the environment you're in. In these circumstances I try to apply the 'Scotty' principle - as in estimate every task at the next unit of time above - hours will be like days
Good luck - and thanks for the feedback
Greg
ASKER
Hey Greg, Thanks. I am already seeing an improvement in how project operates based on your original feedback so great info.
As for the latest feedback; I don't know if I told you that we use the Microsoft Project Server environment (PWA); this system allows us to click on an action item in project and designate it as a deliverable so it shows up on the central deliverable tracking table along with its timeline and current state. This is typically what mgmt looks at, they don't go in the project itself.
Furthermore, resources are centrally created under the system resource table; I have no control over that but I am required to select the resources from it as it then rolls up the work these resources have spent (key word here is 'have' for management) on ALL projects they belong to so they can get an idea of how much work an individual is doing and adjust future project membership. I can do whatever I want when I'm planning (i.e. create a group or role type resource) but as soon as we're executing and time is rolling in for me to apply, I have to use the actual system wide resources.
To further add to the challenge, some resources (like a networking expert) have their allocation set to a lower than 100 number (networking expert is 10%). The idea being that a networking expert is only 'supposed' to work on project work 10% of the time and the rest on operational stuff. In reality they are often full time on the project and let the operational work go to someone else. So that affects project as well as it has to up the allocation % if the duration is not allowed to change. Hence me having resources with %'s through the roof.
Now you can start to see some of the challenges we have here; fixed durations, controlled allocations for resources, reality, etc. :)
So, long story short, it comes down to a reality vs imposed procedures scenario and I try my best to balance it all out.
I do appreciate your feedback though and I'm already wondering how the Spare fields can be used. Not sure if they filter up to the project server level but I'm sure i can use them for other reasons internally here.
And finally, yes, I do (shhh, don't let my bosses find out), umm, 'estimate' work required based on our reality and not what it should take.
cheers
Gary
As for the latest feedback; I don't know if I told you that we use the Microsoft Project Server environment (PWA); this system allows us to click on an action item in project and designate it as a deliverable so it shows up on the central deliverable tracking table along with its timeline and current state. This is typically what mgmt looks at, they don't go in the project itself.
Furthermore, resources are centrally created under the system resource table; I have no control over that but I am required to select the resources from it as it then rolls up the work these resources have spent (key word here is 'have' for management) on ALL projects they belong to so they can get an idea of how much work an individual is doing and adjust future project membership. I can do whatever I want when I'm planning (i.e. create a group or role type resource) but as soon as we're executing and time is rolling in for me to apply, I have to use the actual system wide resources.
To further add to the challenge, some resources (like a networking expert) have their allocation set to a lower than 100 number (networking expert is 10%). The idea being that a networking expert is only 'supposed' to work on project work 10% of the time and the rest on operational stuff. In reality they are often full time on the project and let the operational work go to someone else. So that affects project as well as it has to up the allocation % if the duration is not allowed to change. Hence me having resources with %'s through the roof.
Now you can start to see some of the challenges we have here; fixed durations, controlled allocations for resources, reality, etc. :)
So, long story short, it comes down to a reality vs imposed procedures scenario and I try my best to balance it all out.
I do appreciate your feedback though and I'm already wondering how the Spare fields can be used. Not sure if they filter up to the project server level but I'm sure i can use them for other reasons internally here.
And finally, yes, I do (shhh, don't let my bosses find out), umm, 'estimate' work required based on our reality and not what it should take.
cheers
Gary
ASKER
Everything you say makes perfect sense and I will have to find a way to manage my projects keeping this in mind as I want to avoid the problems I have had doing it this way. At first thought I will likely place a subtask that is similar to the deliverable and record all my resources and time in there. If only to put the resources and time in another place than the summary level.
Now, to explain a bit about why I do things this way. Part of this is the way the PMO office likes to see things done and part of it is my way.
First, we need the MS projects to do a number of things for us, 1) provide a project plan with timelines and resource requirements, 2) provide a checklist of critical items that need to be remembered to be done as part of the deliverable (not necessarily all things as the resource is expected to know what to do) and 3) provide historical info on how much time the deliverable took to be done and how many resources it took.
Keep in mind that I work in a hospital environment and not construction so our deliverables are often simple items such as 'order all required items', 'get the server up and running','implement ECG software', 'train nursing', etc. The subtasks then are often just reminders for the people working on the deliverables to not forget important items such as 'get the patch cables','request the network IP in plenty of time', 'send out training notification one week in advance'. We keep our project plans simple only because of time constraints. With 20 projects on the go at any one time per PM we have little time to spend on planning and often the resources are what help us build the plan. It is more a tool to inform everyone and to brainstorm the tricky parts than it is a plan with timelines to follow.
Next, the resources then report back, using our task tracking system, time spent on the deliverable. As per dept policy, they don't report on the subtasks time spent that they needed to do to get the deliverable done, just on the deliverable. this was put in place by mgmt so the resources don't spend significant time figuring out time spent.
Hence I was putting the resources and time spent on the summary as trying to put it on the actual work lines would require a significant amount of time spent first creating those lines and second, figuring out how to split up the time submitted properly.
Finally, when management reviews a historical project to determine time and resources so they can estimate a future project it would confuse them if time was split between subtasks, UNLESS it was acurate, which I can't see it ever being here so I'm thinking that creating a subtask that is named the same as the deliverable and applying time and resources to it is the way to go.
Thank You for your continued assistance.