How do you typically enter a multiday event in project? Say you have an IT dev team review that will likely take multiple reviews to accomplish a goal. Do I enter as one tasks with a duration of say 10 days? However, I don’t want it to appear as if it will consume full days since these are likely 1 to 2hrs sessions which may only happen 2 or 3 times within that estimated duration.
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.
Without knowing more context about your company and project(s)…
I would probably (depending!!!) enter that as a single activity with 2-week duration. Then I would open the task details and enter the estimated number of hours of each resource. For instance for people who would be sitting in 4×2 hour meetings, I would show them consuming 8 hours over the 2 weeks. For other people who attend the meetings then have “homework” between meetings (related to the activity), I would estimate that number of hours and add it to the 8 (perhaps 48 hours spread over the two weeks).
I would just stick with the “flat” work contour even though that’s not really true. But in my world it makes no sense to track every hour of people’s day, I’m lucky if I can get the correct number of hours over a week. But really all I’m doing with my resources is watching for drastic over-allocations. For example if I add 48 hours of work to someone who is already doing another 80 hours of work on a different task then I’ll get a flag that says I need to look deeper and maybe re-shuffle. On the other hand if I add 8 hours (over 2 weeks) to someone who is doing 80 hours of work, I might just consider that “noise” and not bother delving further. It all depends on the situation.
Things that would impact how I handle it could potentially be:
– How resource-constrained is my company (and project)
– How hours are tracked and charged (if they are at all)
– The criticality of the meetings, and whether the successors are “hard” or “soft” dependents (i.e. is the successor task REALLY constrained by having everything be 100% complete as an outcome of the meetings)
– The nature of communication within (and outside of) the project team
– The topic of the meetings and how central it is to the project, or whether the topics are more “administrative” or tangential
Your mileage may vary. Actually it WILL vary, and that’s why Project Management is as much of an art as it is a science. Sometimes neat formulas work, sometimes we have to be creative about determining the needs of our organization and understand when things might have to bend around a bit.