Loading...
Quick Links

Reply To: Multiday Tasks

Home Forums Discussion Multiday Tasks Reply To: Multiday Tasks

#478936

Robert
There’s a couple ways to answer this.
Generally the simplest answer is to create a fixed duration task, assign the resources and give the resources, for example, 4 hours of work. This will then spread the resource usage over the entire duration at, for example, .1 hr/day. A second way might be to manually enter the resource load pattern or work contour for the projected work. On a grid showing the resource assignments and planned work, you can simply type values on the daily grid, for example: 2,0,0,0,0,2 to represent a 2hr meeting on first day and another 2 hrs on the 6th day. But as with all Project options, there are ramifications/costs.
Simply defining a fixed duration task spreads the work, but may result in resource leveling conflicts on tasks that could/should run in parallel. For example Bob is on the meeting task and another parallel task at which his assignment units is 100%. Because Bob is allocated at 1% on the meeting, the leveling algorithm may not schedule Bob’s next task until after the meeting completes because Bob is not available at 100% (to start the next task). The result may be a large gap (during the meeting tasks duration) in Bob’s forecasted usage.
Manually entering a work contour could also cause issues primarily because you as the PM, are taking full ownership of that task and the leveling algorithms will pretty much just ignore the task you now own.
Another option is to simply schedule a task for each meeting day. It’s more tasks, but it gives the cleanest result from a scheduling/leveling perspective.
But I would also ask how critical it is that these meetings be tracked to that detail.
Do they drive key dependencies? Maybe one final sign off on testing for example, does, but does every review meeting? In other words, does that meeting completion need to drive a successor relationship down stream in the logic.
How critical are they in terms of tracking/reporting progress? Do they need specific visibility to management or is this simply overhead that’s part of the development or testing process?
Who is involved? Is it a business leader meeting that needs to maintain visibility on the forecast, or is it internal developers/testers?
I’m asking because these questions may help determine how you set up the schedule to most effectively allow you to have the easiest job to maintain the schedule but still provide needed visibility and tracking levels.
One thing I’ll do is create a “development Phase Meetings” overhead task spanning the entire phase, for example. I’ll determine how much time per week each resource will average on all overhead type tasks such as team meetings, code reviews, testing reviews, testing support, and so on. Then I’ll create one task with the appropriate duration and assign the appropriate resources with the determined allocation. Any time spent on that topic is simply reported to that task. For example, I may determine the entire team will spend 5% on team meetings/status updates, etc. So that gets a task. I might determine that during the testing phase, the developers estimate they will spend 25% of their time doing testing support, in support of testers who have very specific testing tasks. So in that case the developers get a 25% allocation to a testing support task that spans the entire testing phase.
However, to ensure that Project will schedule other work in parallel to these overhead tasks, I then ensure that these other tasks have a resource allocation sufficiently reduced to allow parallel work. For example, the developers providing testing support are allocated 25% to testing support and 5% to meeting overhead. Therefore, I will only allocate the developers assignment units at less than 70% (100%-25%-5%) on any other tasks occurring in parallel with testing support.
I hope this makes sense.
Bottom line, if there’s a NEED to create separate meeting tasks, then by all means. But if not, don’t make your job as the PM any more difficult than necessary by muddling up the schedule and creating dozens of tasks which provide you no real benefit from a tracking the schedule perspective. Think “what’s key to manage in that phase” and try to simplify the ancillary work (in the schedule).
Hope that helps and provides some additional thought.