From: wright development wright on
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
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
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
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
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