Prev: How to use xml export?
Next: How can I display the last time (date/timestamp) my project wa
From: Bud on 26 Apr 2008 10:07
Our PMO is moving projects onto MSPS. It is mandating certain options going
to MSPS. One of the options it is mandating is the use of "Fixed work" for
tasks with deliverables. If they are going to mandate anything I think it
should be "Fixed units".
They are also mandating other items as well. Is MSPS so rigid?

What are your thoughts on this mandate of "Fixed work"?

Thanks
From: Dave on 27 Apr 2008 02:10
Bud wrote:
> Our PMO is moving projects onto MSPS. It is mandating certain options going
> to MSPS. One of the options it is mandating is the use of "Fixed work" for
> tasks with deliverables. If they are going to mandate anything I think it
> should be "Fixed units".
> They are also mandating other items as well. Is MSPS so rigid?
>
> What are your thoughts on this mandate of "Fixed work"?
>
> Thanks

For the vast majority of tasks fixed work is the most appropriate task
type. This is because most tasks do in fact require a fixed amount of
work to be carried out on them before they are finished. In practice,
are they going to run through and check that every single task is set to
fixed work (beyond the first week or so)?

Another reason why they might be trying to do this is to make life
easier for those who are not so proficient in the use of the tool and
aren't so familiar with the different task types. I've seen that
happening before. Have you asked if you can be exempt from the rule
since you understand sufficiently well the differences between the
different task types?

MSPS is not rigid in this regard and I suspect that the mandate is more
to do with improving internal standards or making them more consistent
than the fact that you are going to be using MSPS.
From: Rod Gill on 27 Apr 2008 17:28
But I always say Fixed Units is the most flexible and easiest for beginners.
Fixed work forces the task into effort driven which causes many problems and
fixed duration hurts because if the takes/project is effort driven, the
duration needs to be calculated, not fixed.

I think the answer to the original problem needs to be driven by your
project scheduling practices first, then what delivers the results you need
in Project second.

--

Rod Gill
Microsoft MVP for Project

Author of the only book on Project VBA, see:
http://www.projectvbabook.com



"Dave" <nobody(a)hotmail.co.uk> wrote in message
news:481418e3$1(a)mail.hmgcc.gov.uk...
> Bud wrote:
>> Our PMO is moving projects onto MSPS. It is mandating certain options
>> going to MSPS. One of the options it is mandating is the use of "Fixed
>> work" for tasks with deliverables. If they are going to mandate anything
>> I think it should be "Fixed units".
>> They are also mandating other items as well. Is MSPS so rigid?
>>
>> What are your thoughts on this mandate of "Fixed work"?
>>
>> Thanks
>
> For the vast majority of tasks fixed work is the most appropriate task
> type. This is because most tasks do in fact require a fixed amount of
> work to be carried out on them before they are finished. In practice, are
> they going to run through and check that every single task is set to fixed
> work (beyond the first week or so)?
>
> Another reason why they might be trying to do this is to make life easier
> for those who are not so proficient in the use of the tool and aren't so
> familiar with the different task types. I've seen that happening before.
> Have you asked if you can be exempt from the rule since you understand
> sufficiently well the differences between the different task types?
>
> MSPS is not rigid in this regard and I suspect that the mandate is more to
> do with improving internal standards or making them more consistent than
> the fact that you are going to be using MSPS.

From: Bud on 27 Apr 2008 20:36
Thanks

Here is how I see this and am going to have to figure the best way to
approach the PMO as I to see Fixed units as the best option......Thoughts on
this?????

The Gantt chart is where most PM's make changes. Of the 3 variables (work,
duration, units), the Gantt chart has a work variance field so if work
changes from the baseline it can be displayed on the Gantt chart. The Gantt
chart has a Finish and Duration variance field and if that changes from the
baseline it can be displayed on the Gantt chart.
The Gantt chart or any other view does NOT have a Units variance field that
will show how the units changed. That's because MS Projects default task type
is fixed units. However, if the Resource UNITS are what is fixed than there
is no reason to know what the Resource Units variance is. There won't be any.

The truly fixed variable here is the resource UNITS (how much of 1 person do
I have to do the work). The following is what should happen….and this is just
1 resource out of many. We say….Joe because of all your Production support
on-going non-direct tasks you have 50% to apply to enhancements. Please do
so. So…Joes starts getting enhancements and he applies around 50%. So in
reality he is fixed on his resource units.
Using "Fixed units" the resource units will not change and therefore no need
to check any UNIT variance. The other 2 task type variables WORK and
DURATION/FINISH DATE can be seen on the Gantt chart at the task level or
summary levels and ALSO their VARIANCES. It's easier to manage the detail of
the schedule on the Gantt chart and the OVERALL over allocations on the
resource usage screen. When the one variable that MS Project doesn't give a
variance for is allowed to be fixed (Fixed units) you can see the variance on
the other 2 task types WORK and Duration/Finish date quickly on the Gantt
chart through the task and summary tasks.

Using "Fixed work" increases the management of the schedule simply because
it may allow the resource units to increase/decrease and MS Project does NOT
have a UNITS variance field on the Gantt chart at the task level or summary
level or anywhere else for that matter.
It forces the management of the schedule at a more granular level which is
each assignment and can ONLY be seen on the Resource usage or task Usage
view. Way more difficult to manage at the assignment level since MS Project
doesn't supply tools their. The PM would have to sight check it down every
change request per Resource.

One way or another WORK is what is going to change either by actuals being
posted and changed or by increasing/decreasing the work. I understand they do
their best to FORECAST their work but it's a forecast and that will change as
the phases of the request are processed. They may say I need more hours on
this task or actuals will be applied completing a phase changing work.




"Rod Gill" wrote:

> But I always say Fixed Units is the most flexible and easiest for beginners.
> Fixed work forces the task into effort driven which causes many problems and
> fixed duration hurts because if the takes/project is effort driven, the
> duration needs to be calculated, not fixed.
>
> I think the answer to the original problem needs to be driven by your
> project scheduling practices first, then what delivers the results you need
> in Project second.
>
> --
>
> Rod Gill
> Microsoft MVP for Project
>
> Author of the only book on Project VBA, see:
> http://www.projectvbabook.com
>
>
>
> "Dave" <nobody(a)hotmail.co.uk> wrote in message
> news:481418e3$1(a)mail.hmgcc.gov.uk...
> > Bud wrote:
> >> Our PMO is moving projects onto MSPS. It is mandating certain options
> >> going to MSPS. One of the options it is mandating is the use of "Fixed
> >> work" for tasks with deliverables. If they are going to mandate anything
> >> I think it should be "Fixed units".
> >> They are also mandating other items as well. Is MSPS so rigid?
> >>
> >> What are your thoughts on this mandate of "Fixed work"?
> >>
> >> Thanks
> >
> > For the vast majority of tasks fixed work is the most appropriate task
> > type. This is because most tasks do in fact require a fixed amount of
> > work to be carried out on them before they are finished. In practice, are
> > they going to run through and check that every single task is set to fixed
> > work (beyond the first week or so)?
> >
> > Another reason why they might be trying to do this is to make life easier
> > for those who are not so proficient in the use of the tool and aren't so
> > familiar with the different task types. I've seen that happening before.
> > Have you asked if you can be exempt from the rule since you understand
> > sufficiently well the differences between the different task types?
> >
> > MSPS is not rigid in this regard and I suspect that the mandate is more to
> > do with improving internal standards or making them more consistent than
> > the fact that you are going to be using MSPS.
>
>
From: "Crook" please reply to on 28 Apr 2008 12:14
Bud,

FWIW, I greatly respect Dave's expertise, but I agree with you and Rod on
use of Fixed Units. Another arrow for your quiver, MS Project uses Fixed
Units as its default out-of-the-box task type.

HTH,
Crook


"Bud" <Bud(a)discussions.microsoft.com> wrote in message
news:3BD6A287-2A13-4681-9AC2-EDBF3C34634B(a)microsoft.com...
> Thanks
>
> Here is how I see this and am going to have to figure the best way to
> approach the PMO as I to see Fixed units as the best option......Thoughts
> on
> this?????
>
> The Gantt chart is where most PM's make changes. Of the 3 variables (work,
> duration, units), the Gantt chart has a work variance field so if work
> changes from the baseline it can be displayed on the Gantt chart. The
> Gantt
> chart has a Finish and Duration variance field and if that changes from
> the
> baseline it can be displayed on the Gantt chart.
> The Gantt chart or any other view does NOT have a Units variance field
> that
> will show how the units changed. That's because MS Projects default task
> type
> is fixed units. However, if the Resource UNITS are what is fixed than
> there
> is no reason to know what the Resource Units variance is. There won't be
> any.
>
> The truly fixed variable here is the resource UNITS (how much of 1 person
> do
> I have to do the work). The following is what should happen..and this is
> just
> 1 resource out of many. We say..Joe because of all your Production support
> on-going non-direct tasks you have 50% to apply to enhancements. Please do
> so. So.Joes starts getting enhancements and he applies around 50%. So in
> reality he is fixed on his resource units.
> Using "Fixed units" the resource units will not change and therefore no
> need
> to check any UNIT variance. The other 2 task type variables WORK and
> DURATION/FINISH DATE can be seen on the Gantt chart at the task level or
> summary levels and ALSO their VARIANCES. It's easier to manage the detail
> of
> the schedule on the Gantt chart and the OVERALL over allocations on the
> resource usage screen. When the one variable that MS Project doesn't give
> a
> variance for is allowed to be fixed (Fixed units) you can see the variance
> on
> the other 2 task types WORK and Duration/Finish date quickly on the Gantt
> chart through the task and summary tasks.
>
> Using "Fixed work" increases the management of the schedule simply because
> it may allow the resource units to increase/decrease and MS Project does
> NOT
> have a UNITS variance field on the Gantt chart at the task level or
> summary
> level or anywhere else for that matter.
> It forces the management of the schedule at a more granular level which is
> each assignment and can ONLY be seen on the Resource usage or task Usage
> view. Way more difficult to manage at the assignment level since MS
> Project
> doesn't supply tools their. The PM would have to sight check it down every
> change request per Resource.
>
> One way or another WORK is what is going to change either by actuals being
> posted and changed or by increasing/decreasing the work. I understand they
> do
> their best to FORECAST their work but it's a forecast and that will change
> as
> the phases of the request are processed. They may say I need more hours on
> this task or actuals will be applied completing a phase changing work.
>
>
>
>
> "Rod Gill" wrote:
>
>> But I always say Fixed Units is the most flexible and easiest for
>> beginners.
>> Fixed work forces the task into effort driven which causes many problems
>> and
>> fixed duration hurts because if the takes/project is effort driven, the
>> duration needs to be calculated, not fixed.
>>
>> I think the answer to the original problem needs to be driven by your
>> project scheduling practices first, then what delivers the results you
>> need
>> in Project second.
>>
>> --
>>
>> Rod Gill
>> Microsoft MVP for Project
>>
>> Author of the only book on Project VBA, see:
>> http://www.projectvbabook.com
>>
>>
>>
>> "Dave" <nobody(a)hotmail.co.uk> wrote in message
>> news:481418e3$1(a)mail.hmgcc.gov.uk...
>> > Bud wrote:
>> >> Our PMO is moving projects onto MSPS. It is mandating certain options
>> >> going to MSPS. One of the options it is mandating is the use of "Fixed
>> >> work" for tasks with deliverables. If they are going to mandate
>> >> anything
>> >> I think it should be "Fixed units".
>> >> They are also mandating other items as well. Is MSPS so rigid?
>> >>
>> >> What are your thoughts on this mandate of "Fixed work"?
>> >>
>> >> Thanks
>> >
>> > For the vast majority of tasks fixed work is the most appropriate task
>> > type. This is because most tasks do in fact require a fixed amount of
>> > work to be carried out on them before they are finished. In practice,
>> > are
>> > they going to run through and check that every single task is set to
>> > fixed
>> > work (beyond the first week or so)?
>> >
>> > Another reason why they might be trying to do this is to make life
>> > easier
>> > for those who are not so proficient in the use of the tool and aren't
>> > so
>> > familiar with the different task types. I've seen that happening
>> > before.
>> > Have you asked if you can be exempt from the rule since you understand
>> > sufficiently well the differences between the different task types?
>> >
>> > MSPS is not rigid in this regard and I suspect that the mandate is more
>> > to
>> > do with improving internal standards or making them more consistent
>> > than
>> > the fact that you are going to be using MSPS.
>>
>>


 | 
Pages: 1
Prev: How to use xml export?
Next: How can I display the last time (date/timestamp) my project wa