how do i integrate weather delays into microsoft project?
in [Project]
|
From: wright development wright on 12 Nov 2009 13:37 i need to incorporate multiple changes in plans and other delays that have affeceted the project and am not sure as how to do this so that it extends the completion dates for the items it affects.
From: G�rard Ducouret on 12 Nov 2009 14:00 Hello, The easiest way to do this is to enter these bad weather days in the project's calendar : Tools / Change Working Time, and set these days as Non Working. G�rard Ducouret "wright development" <wright development(a)discussions.microsoft.com> a �crit dans le message de news: 1792B46F-1223-43C0-B090-A1EF10DC6E82(a)microsoft.com... >i need to incorporate multiple changes in plans and other delays that have > affeceted the project and am not sure as how to do this so that it extends > the completion dates for the items it affects.
From: Paul Billings on 13 Nov 2009 12:55 Another option that will highlight the weather delays is to have a specific task called Weather Delay. When a delay occurs, use task- usage to record the time spent (lost) on this "task". Enter hours in the Actual Work field since Work can be shifted around by the various leveling or rescheduling capabilities. You do not have to assign a resource, but it may be useful to use a Weather resource if you care to track more than one type of weather delay (e.g., WD-Integration and WD-Testing). You can also use the various real resources that are affected (especially useful if only some are impacted). It is helpful to initially assign a resource(s) at 0% to get their name(s) "on the list" and will allow recording of actual work. Any of these approaches will make bars show up on the Gantt chart at the appropriate time. Other considerations if one goes down this road are the costs if you're tracking that in MSP (e.g., using Earned Value). Occasionally people are paid through such delays; assign to real resources and record their hours. Often they are not and would require a separate Cost Rate if you will attribute their hours (without pay) to this task. It just depends on what you care to track. One tip: It is a little tricky to make MSP use a different rate table (say table B) for a specific task -- it is done in the task or resource usage view: either double-click the resource or insert the CostRateTable field. You do not need to mess with effective dates on rate table B (the table you've chosen to use for zero-cost). One consequence of using a Weather task is that there will be "work" associated to this task, so rolled up Work values will be a little off. To minimize this, record 0.1 or 0.01 hours with the usage timescale zoomed to the day level instead of 8h. This certainly wound up being longer than I first thought it would, but hopefully gives someone something to think about in their specific situation. Paul On Nov 12, 12:00 pm, "Gérard Ducouret" <ducouret.gerardREMOVET...(a)THATfree.fr> wrote: > Hello, > > The easiest way to do this is to enter these bad weather days in the > project's calendar : Tools / Change Working Time, and set these days as Non > Working. > > Gérard Ducouret > > "wright development" <wright developm...(a)discussions.microsoft.com> a écrit > dans le message de news: > 1792B46F-1223-43C0-B090-A1EF10DC6...(a)microsoft.com... > > >i need to incorporate multiple changes in plans and other delays that have > > affeceted the project and am not sure as how to do this so that it extends > > the completion dates for the items it affects.
From: Jim Aksel on 15 Nov 2009 00:16 Paul, I am not certain this is the best approach as it adds work to the schedule. If workers are paid through the delay, this is "cost" not "work". You want to add cost to the task as idle time, not productive hours. Actual Cost would come from an accounting system (I assume costs are manually calculated, I usually do not let Project do it). I suppose an arguement can be made that they are "working" and it just took more "work" to do this task than estimated becuase of the rain delay. What I don't like about that approach is that it skews the history data. It may only take 48 manhours to put on a roof.... If I charge "work" (rather than cost) to all my rain delay, I will be tempted to include that labor hour estimate in my next bid... even though the 48 hour of effort did not change.... I might be tempted to bid the same number of hours that I actually charged the task last time (that is, I let the rain delay impact the number of hours it takes to put up a roof). I would take a slightly different approach. Some tasks are impacted by weather, others are not. For example, roofers will not roof in the rain, but some tasks like painting interior might still be able to continue if the roof did not leak. Certainly tasks like "Visit Client to approve final colors" would continue... That being said, I would have a specific RainDelay calendar that is a copy of the real work calendar. I would then follow Gerrard's plan and set days to Non-Working in the Weather Calendar. I would assign the Weather calendar to those tasks that would stop work waiting for the weather. If workers are paid through those days, add it to the cost in the Task Usage view. That's my opinion... I am sure others will have different and well considered views (just like yours), and that is why we are all here... -- If this post was helpful, please consider rating it. Jim Aksel, MVP Check out my blog for more information: http://www.msprojectblog.com "Paul Billings" wrote: > Another option that will highlight the weather delays is to have a > specific task called Weather Delay. When a delay occurs, use task- > usage to record the time spent (lost) on this "task". Enter hours in > the Actual Work field since Work can be shifted around by the various > leveling or rescheduling capabilities. You do not have to assign a > resource, but it may be useful to use a Weather resource if you care > to track more than one type of weather delay (e.g., WD-Integration and > WD-Testing). You can also use the various real resources that are > affected (especially useful if only some are impacted). It is helpful > to initially assign a resource(s) at 0% to get their name(s) "on the > list" and will allow recording of actual work. Any of these > approaches will make bars show up on the Gantt chart at the > appropriate time. > > Other considerations if one goes down this road are the costs if > you're tracking that in MSP (e.g., using Earned Value). Occasionally > people are paid through such delays; assign to real resources and > record their hours. Often they are not and would require a separate > Cost Rate if you will attribute their hours (without pay) to this > task. It just depends on what you care to track. > > One tip: It is a little tricky to make MSP use a different rate table > (say table B) for a specific task -- it is done in the task or > resource usage view: either double-click the resource or insert the > CostRateTable field. You do not need to mess with effective dates on > rate table B (the table you've chosen to use for zero-cost). > > One consequence of using a Weather task is that there will be "work" > associated to this task, so rolled up Work values will be a little > off. To minimize this, record 0.1 or 0.01 hours with the usage > timescale zoomed to the day level instead of 8h. > > This certainly wound up being longer than I first thought it would, > but hopefully gives someone something to think about in their specific > situation. > > Paul > > On Nov 12, 12:00 pm, "Gérard Ducouret" > <ducouret.gerardREMOVET...(a)THATfree.fr> wrote: > > Hello, > > > > The easiest way to do this is to enter these bad weather days in the > > project's calendar : Tools / Change Working Time, and set these days as Non > > Working. > > > > Gérard Ducouret > > > > "wright development" <wright developm...(a)discussions.microsoft.com> a écrit > > dans le message de news: > > 1792B46F-1223-43C0-B090-A1EF10DC6...(a)microsoft.com... > > > > >i need to incorporate multiple changes in plans and other delays that have > > > affeceted the project and am not sure as how to do this so that it extends > > > the completion dates for the items it affects. > > . >
From: Paul Billings on 16 Nov 2009 12:46
On Nov 14, 10:16 pm, Jim Aksel <JimAk...(a)discussions.microsoft.com> wrote: > Paul, I am not certain this is the best approach as it adds work to the > schedule. Jim, As you alluded to, "best" is different for various people. I simply wanted to mention that such delays can be highlighted on the Gantt chart, which may be useful to some people. I've had customers specifically request it. (In those cases, the bar depicted delays caused by the customer which were outside contractor control.) The easiest way I know to get such a bar to show is to specify work. We agree that could be an issue, but using an effort of 0.01 h per day of delay does not skew the work appreciably, IMHO. I also like that now Project keeps a running total of delay time, clearly visible on the chart (i.e., duration column). Clearly there are other ways to get a bar on the chart, including a time-only task (no work) that is manually split and dragged around with the mouse, but I find that cumbersome by comparison. I certainly agree that if you don't care to see this information on the chart, then using a calendar approach is "best". :-) In the interest of better resource management, however, I'm always looking for "gaps" in people's work. Typical causes are predecessor unavailability and calendars (both project and resource). Cutting down the number of places I have to hunt--or the difficulty in their access--for an explanation is useful, and having this show up on the chart is certainly easier than going through menus to access a Rain delay calendar. Paul |