Creeping Overhead Projects

D

dwolf

We have created Overhead projects using the Gary Chefetz instructions
from this NewsGroup (1 per SBU) exactly as described.

1) Using fixed-duration tasks, with effort-driven turned off
2) Resources assigned to the tasks so that the total of the assignments
equals the percentage we've estimating to be discounted.
3) Kept it simple, keep the buckets fairly general. In our case
following Accounting's prescribed buckets.

The one frustration that we have observed is that as people charge into
these Fixed Duration tasks the end date of the tasks keep moving out
into the future. Since the objective is to maintain these projects as
annual budgets this becomes difficult to understand and explain to
upper management. The idea was to model these budgets as level loaded
capacity drains against which actuals would draw.

This year we thought we had discovered a solution using a constraint of
"Finish No Later Than" with a date of 12/23/2005. The concept was that
the level loaded budgets would pile up towards the end of the year
until used. We figured this modelled the probability of reality quite
nicely. However, when the first week's hours were recieved, the dates
did not hold as expected. When a group did not charge until the
Thursday or Friday, the entire task moved that many days into the
following year.

Any ideas how to constrain these "buckets" so that they do not do this?
The only other thought we've had was to hammock each task between two
milestones.

--DWolf
 
D

Dominic Moss

dwolf said:
We have created Overhead projects using the Gary Chefetz instructions
from this NewsGroup (1 per SBU) exactly as described.

1) Using fixed-duration tasks, with effort-driven turned off
2) Resources assigned to the tasks so that the total of the assignments
equals the percentage we've estimating to be discounted.
3) Kept it simple, keep the buckets fairly general. In our case
following Accounting's prescribed buckets.

The one frustration that we have observed is that as people charge into
these Fixed Duration tasks the end date of the tasks keep moving out
into the future. Since the objective is to maintain these projects as
annual budgets this becomes difficult to understand and explain to
upper management. The idea was to model these budgets as level loaded
capacity drains against which actuals would draw.

This year we thought we had discovered a solution using a constraint of
"Finish No Later Than" with a date of 12/23/2005. The concept was that
the level loaded budgets would pile up towards the end of the year
until used. We figured this modelled the probability of reality quite
nicely. However, when the first week's hours were recieved, the dates
did not hold as expected. When a group did not charge until the
Thursday or Friday, the entire task moved that many days into the
following year.

Any ideas how to constrain these "buckets" so that they do not do this?
The only other thought we've had was to hammock each task between two
milestones.

--DWolf

I am not familiar with the method promoted by Gary but am sure it is
appropriate & useful.

From my own experimentation on "Administrative Projects" which is what I
assume you mean by Overhead Projects it is possible to assign a person or
people "0" hours work to a non effort driven task, fixed unit or fixed
duration - this will ensure that the task appears in the individuals
timesheet for tracking purposes. Assigning a person "0" hours is likely to
result in the task duration also being "0". If all you have are tasks with
these assignments then your "Administrative Project" will also have a
duration of "0".

If you want the "Administrative Project" to reflect a defined window of time
you could incorporate a "hammock" task as you suggested. A further
enhancement given your requirement to track annual budgets would be to
define baseline cost & or work values (you can manually enter whatever value
you want - well at least you can in normal projects, I have not experimented
with this on an "Administrative Project") either for the individual
"buckets" for different classes of "buckets" or the whole project. You would
then be able to compare how much effort was expended on each of the buckets
compared to your estimate - if you are undergoing any process changes this
may be a way of indirectly highlighting the "savings" made by changing or
improving certain processes.

--
Dominic Moss

www.projectability.co.uk

Helping people achieve more with Microsoft Project

Tel +44 8707 303 400
Fax +44 8707 303 500
 
Top