how do i integrate weather delays into microsoft project?

[wright development]

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.

 

[Gérard Ducouret]

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 (e-mail address removed)> a écrit
dans le message de (e-mail address removed)...

 

[Paul Billings]

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

 

[Jim Aksel]

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]

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

 

[Paul Billings]

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.  

One thing has bothered me about this concept of using calendars--
really it's about "scheduling" delays. By the vary nature of
"scheduling", it's useful only when discussing future work. However,
I'd be hard pressed to schedule a rain delay on July 17 of next year!
Assuming one is tracking with sufficient detail, any delay due to
weather will show up as a gap when actual hours are recorded. If one
is not tracking at such a level, then they've effectively stated that
they are not interested is such details. Why is a weather delay any
different than capturing (or not) whether your roofer didn't work
because his truck broke down?

Paul

 

[Rayzy72]

Teaching Project to builders quite often, this is a very common question, and
most ask for some type of visual cue they can show the client. I usually
recommend adding rain delays as a new task. In addition it is a good idea to
format the Rain Delay bars in a different colour (eg. Green) so they stand
out against other regular tasks. For future projects you should use a
template which does not include any rain delays. Or you could filter or group
these and subtract work associated with the total Rain Delays from your final
total calculations for Work.