How do I set a project task effort to be a percentage of other tas

[Andy the Viking]

I want to be able to set a task to automatically set the work units to be a
percentage of other tasks, then ideally to ditribute those units evenly
across the duration of a project.

I.E. I run sofware development projects where we assign the project
management overhead to be 25% of the overall development effort (which could
be a combination of multiple sub-tasks). I'd then like the project management
task to spread evenly across the project development phase from start to
finish (either by adjusting the resource assignment levels or more usefully
by splitting the effort into chunks as per a repeating task).

Any help much appreciated as I've been trying to sort this for ages.

 

[John]

I want to be able to set a task to automatically set the work units to be a
percentage of other tasks, then ideally to ditribute those units evenly
across the duration of a project.

I.E. I run sofware development projects where we assign the project
management overhead to be 25% of the overall development effort (which could
be a combination of multiple sub-tasks). I'd then like the project management
task to spread evenly across the project development phase from start to
finish (either by adjusting the resource assignment levels or more usefully
by splitting the effort into chunks as per a repeating task).

Any help much appreciated as I've been trying to sort this for ages.

Andy,
Well there are different approaches to dealing with management support.
As a matter of fact we are in the process of developing a new FAQ for
our MVP webpage that discusses this issue, but, it's not quite ready
yet. However, here is the section that relates to your question.

"Assigning resources to summary lines is probably the number one reason
why values in the Cost field do not appear to add up. A secondary effect
is double booking if a resource is assigned at both summary level and
subtask level. The main problem with summary line resource assignments
is that data visibility is hidden and thus values may be confusing
because data from subtask fields (e.g. Cost, Work, etc.) is added to
resource data at the summary level. The one case where a resource
assignment on a summary line may make sense is for
management/supervisory support. However, an approach better
suited for general users is to either create a separate task to
delineate management/supervisory support, (see related FAQ 19 - Hammock
tasks), or in a multi-file project plan, create a separate file for
management tasks."

Personally, I have also used the method wherein support effort is
discretely broken into monthly (quarterly or whatever) pieces. It is
easy to track and adjust as needed.

Hope this helps.
John
Project MVP

 

[Andy the Viking]

John, Thanks for your input. I was hoping to create an actual task rather
than using the summary line though. I think it may not be possible to do
automatically, certainly in project 2000 (my version). I can obviously
manually create a management task and set it to say 25% of the total workload
of other tasks but the trouble is then remembering to keep it updated.

PS I've had a look for teh FAQ section in the MVP pages but don't seem to be
able to find it can you post a URL.

Thanks again.

 

[John Sitka]

Try the monthly (or whatever) chunk approach because it stands up to vicious simple scrutiny.
The reason it isn't obvious to use this is because of a pattern of learned behaviour that accepts.......
the unknowable (what realy is management overhead and do we want to define it?).....
as known (what do you mean? It IS management overhead "circular arguement").....
but not in a level of detail explicit enough for a sound schedule calculation (specific resource effort coming to bear on a specific
task)

Observe the ambiguity.
How does one plan for this?Over time that set of tasks is probably going to have a variable "count" could be one, could be many, as the situation changes and
needs arise.
Even the interpretation of what constitutes a full discrete management overhead task is probably variable. So there is a level of
abstraction in the task(s)
to begin with.

Now these "acts of management" how long do they take? Obviously when an managed individual is challenged the management task
requires greater effort. When a experienced resource is at the plate the management task is less. So if you go through a
reassignment at the productive task level and then that has to cascade an impact to the management overhead tasks. Complex; even in
it's most simple renditions. So if a management task is understood to be durable only for a month for example, and has as it's
starting estimate any old value; There is nothing that says throughout that month actual hours can't be recorded on it, or that a
remaining work estimate can't be applied/reapplied and refined through that month. Also that management task can be split and thus
automatically chunk itself into the correct reality slots it might want to be with respect to status dates within that month.

Simply put. Let it float to mirror the actuals, When it times out use a new one.

Here it is in real example. Project manager requests status of management on "management overhead task"(one or many) on Nov22_05.
"Hi this is PM, could you give me your best estimate of remaining management hours until Thanksgiving."
"Sure, Instead of the usually 4 per week this is going to be 8 because of this new guy we have. I have to basically take him by the
hand for the next two days cause he wants to spend some extra time over the holiday going the right direction."

Voila, get back from holidays, record actual work against the 8 hour estimate. Set remaining work to 0 and add a new abstracted
management task to the plan or use one you already have sequenced in there (the December one). attach them or constrain them to
month end if needed. Whatever, it's the fact that they are knowable only in as much as historically they always occur. Status
reporting; I say everybody should report on task completeion, task change and end of shift. But you can extend it to much less
frequent status updates just as easy. But realize that a plan or schedule is only as valuable as the frequency of updates. None of
has have the ability to see into the future, so decision making can only be based on current situation at best.

One other little note: consider that last five minutes of accomplishing anything. You probably aren't going to have a huge
management overhead contributing to a delay at that point. The task at hand is going to be one of "final task". Now if indeed
delivery dosen't take place until after a sign off or debrief etc (management classification possibly). it would seem that that
should be a discrete task on it's own. This is important to mention because it sheds light on the fact that the management "timed"
death and rebirth series of tasks will probably not be on a critical chain of events to Project completeion. They may add time but
you wouldn't plan for a lot of it because much of it is unknown going in and will fall in as a parrallel event to some other
productive task. If it IS known (by the definitions at the very beginning of the post) going in and significant then it is either
lazy not to put it in the logical plan as a discrete effort requirement, or it may need to be linked and unlinked repeatedly as the
plan progresses.

One other other thing; if these management units are in a resource levelled environment; just observe the fact that they will drive
towards zero with each passing day till they time out (at the end of a month for example) and you start to recognize the new one. To
reflect reality just adjust the remaining work accordingly. One day left in the month probably means it's safe to set the management
overhead to someting less than 24 hours. Or start it real small if you are optimistic and expect good performance. (Which you
should; rather than building in task level safety that will just disappear because of lack of focus no matter what you do. That is
just people, they work to fill the time if available to them.)

Hope this helps, you are recording your actuals for historic reasons, you can have management overhead burden your plan when this is
needed. Emergency meeting tomorrow!!! link it up as required. In the planning stages before project tracking make your estimate as
to the sum total of management tasks as one task use it to derive a deadline/finish date evaluation, baseline (or some other
reference technique) then remove that consolidated management task and use the approach outline above.

 

[Mike Glen]

Hi Andy,

FAQs, companion products and other useful Project information can be seen at
this web address: http://project.mvps.org/faqs.htm

Hope this helps - please let us know how you get on

Mike Glen
MS Project MVP

 

[John]

Try the monthly (or whatever) chunk approach because it stands up to vicious
simple scrutiny.
The reason it isn't obvious to use this is because of a pattern of learned
behaviour that accepts.......
the unknowable (what realy is management overhead and do we want to define
it?).....
as known (what do you mean? It IS management overhead "circular
arguement").....
but not in a level of detail explicit enough for a sound schedule calculation
(specific resource effort coming to bear on a specific
task)

Observe the ambiguity.
How does one plan for this?
Over time that set of tasks is probably going to have a variable "count"
could be one, could be many, as the situation changes and
needs arise.
Even the interpretation of what constitutes a full discrete management
overhead task is probably variable. So there is a level of
abstraction in the task(s)
to begin with.

Now these "acts of management" how long do they take? Obviously when an
managed individual is challenged the management task
requires greater effort. When a experienced resource is at the plate the
management task is less. So if you go through a
reassignment at the productive task level and then that has to cascade an
impact to the management overhead tasks. Complex; even in
it's most simple renditions. So if a management task is understood to be
durable only for a month for example, and has as it's
starting estimate any old value; There is nothing that says throughout that
month actual hours can't be recorded on it, or that a
remaining work estimate can't be applied/reapplied and refined through that
month. Also that management task can be split and thus
automatically chunk itself into the correct reality slots it might want to be
with respect to status dates within that month.

Simply put. Let it float to mirror the actuals, When it times out use a new
one.

Here it is in real example. Project manager requests status of management on
"management overhead task"(one or many) on Nov22_05.
"Hi this is PM, could you give me your best estimate of remaining management
hours until Thanksgiving."
"Sure, Instead of the usually 4 per week this is going to be 8 because of
this new guy we have. I have to basically take him by the
hand for the next two days cause he wants to spend some extra time over the
holiday going the right direction."

Voila, get back from holidays, record actual work against the 8 hour
estimate. Set remaining work to 0 and add a new abstracted
management task to the plan or use one you already have sequenced in there
(the December one). attach them or constrain them to
month end if needed. Whatever, it's the fact that they are knowable only in
as much as historically they always occur. Status
reporting; I say everybody should report on task completeion, task change and
end of shift. But you can extend it to much less
frequent status updates just as easy. But realize that a plan or schedule is
only as valuable as the frequency of updates. None of
has have the ability to see into the future, so decision making can only be
based on current situation at best.

One other little note: consider that last five minutes of accomplishing
anything. You probably aren't going to have a huge
management overhead contributing to a delay at that point. The task at hand
is going to be one of "final task". Now if indeed
delivery dosen't take place until after a sign off or debrief etc (management
classification possibly). it would seem that that
should be a discrete task on it's own. This is important to mention because
it sheds light on the fact that the management "timed"
death and rebirth series of tasks will probably not be on a critical chain of
events to Project completeion. They may add time but
you wouldn't plan for a lot of it because much of it is unknown going in and
will fall in as a parrallel event to some other
productive task. If it IS known (by the definitions at the very beginning of
the post) going in and significant then it is either
lazy not to put it in the logical plan as a discrete effort requirement, or
it may need to be linked and unlinked repeatedly as the
plan progresses.

One other other thing; if these management units are in a resource levelled
environment; just observe the fact that they will drive
towards zero with each passing day till they time out (at the end of a month
for example) and you start to recognize the new one. To
reflect reality just adjust the remaining work accordingly. One day left in
the month probably means it's safe to set the management
overhead to someting less than 24 hours. Or start it real small if you are
optimistic and expect good performance. (Which you
should; rather than building in task level safety that will just disappear
because of lack of focus no matter what you do. That is
just people, they work to fill the time if available to them.)

Hope this helps, you are recording your actuals for historic reasons, you can
have management overhead burden your plan when this is
needed. Emergency meeting tomorrow!!! link it up as required. In the planning
stages before project tracking make your estimate as
to the sum total of management tasks as one task use it to derive a
deadline/finish date evaluation, baseline (or some other
reference technique) then remove that consolidated management task and use
the approach outline above.

John,
WOW! What did you have for breakfast? You should publish this puppy, it
has a ton of point and counterpoint type information (but I admit I
didn't read and digest the whole thing - my time is limited).
Nonetheless I think you more than gave Andy some "food for thought"

John
Project MVP

 

[John]

John, Thanks for your input. I was hoping to create an actual task rather
than using the summary line though. I think it may not be possible to do
automatically, certainly in project 2000 (my version). I can obviously
manually create a management task and set it to say 25% of the total workload
of other tasks but the trouble is then remembering to keep it updated.

PS I've had a look for teh FAQ section in the MVP pages but don't seem to be
able to find it can you post a URL.

Thanks again.

Andy,
You're welcome. I forgot to include our MVP website address but Mike
took care of that. John Sitka gave a whole lotta food for thought but I
will add one more bit to the pile.

At my company, management and some other support people are shown in our
plans as a level-of-effort (LOE). In other words, they are planned (and
more or less perform) as a "live warm body" that does not have
discretely definable tasks. They are more or less a "tax" to the
program. Normally their effort extends from project start to project
finish although some types of LOE support may be more narrowly bounded.

With an LOE task, "credit" is taken regardless of how many hours are
actually worked. In the earned value environment, BCWP is always equal
to BCWS and in fact the financial system automatically "statuses" LOE
effort. The advantage is that a very small amount of effort is required
to set up LOE effort and even less to administer it - it is ideal for
general support (i.e. management). The disadvantage is that if LOE is
applied improperly, project budget can be "chewed up" with no effort
expended. We had this case for one of our data support organizations.
They bid a level of support and their part of the plan was set as LOE.
Unfortunately, a few months into the program it was discovered that no
actuals were being accrued on the account (i.e. they weren't supporting
the project). Nonetheless the budget for their effort had already been
hit in our formal earned value system.

The bottom line is that LOE tasks can be a very good approach to dealing
with a seemingly difficult type of effort, but LOE must be administered
judiciously and monitored to insure it does not become a bad approach.

Hope this helps.
John
Project MVP

 

[John Sitka]

No worries, not to much help in terms of "how" to do anything really.
But you said that you had been working on this for a while so I thought
maybe a different "think" about it might help.

Same concept here...

http://groups.google.ca/group/micro...ad/39082b20924fa016?q=Leveling+problem&hl=en&

The human understanding of a portion of a persons residency
at work being devoted to a "type" of activity; but that activity's
ongoing/variable/overhead "type" nature makes it a tough fit in Project calculation.

If a solid precise assignment dosen't define well, plan with a black box place holder
and then wait for the actuals to define it for you once rolling. This isn't the same as
"Failing to plan",
but it is....
"Failing to plan for a reduction in management overhead"
I hope that reads right... Why would you not want to plan for a reduction in management overhead?
Isn't the opposite "Plan for an increase in (or fixed) management overhead"
a plan for failure? I think it is.
Block in expectaions of a variable overhead cost too high and you will achieve it month
after month year after year, good job? at least we know we can never save money there.
Geez you would think we would get better at what we do over time?
Guess not, Oh well? <Not a pretty picture huh!.>

What of a perfect week = no management overhead.

Just as a matter of sanity... I think folks should build plans that allow for that to be the default condition and not
institutionalize a load on a plan. Or at least incrementaly underestimate it over time and expect it to come down. One feeds the
other; pure definition of assignment allows focus, focus means better performance, less mistakes, better flow and less management. A
constant improvement type approach I guess but not intentional, just because at the very basic level the definitions are very
explicit. There is every reason to expect the whole team WILL overperform what they have done before.

Now many will say we need to sit in meetings and discuss this or that current crisis and status in order to make things run. I don't
believe people have to get together to say "I'm done".... duh no kidding! What do you want, a cookie? Or "I need a little more time
because.." Wow big woop, do I care about the minutae of your challenges, can I even relate to them? The act of the handoffs have
already been fully handled by or disciplined approach to status updates. Thus the "when" of any event is provided to everybody all
the time!. Those meetings should be spent focusing on "Help me help you stuff" Where did the plan fail, did we waste time, were
their queue's, were you stressed out. Did you have distractions. Did someone kill your flow? And most importanly did your experience
adversely affect the Project. If it caused the whole Project to delay THE MOST, then eveybody in this room is to help in every way
possible. All other resources can relax a bit and make an assumption that they can take it easy and creatively deal with their own
personal comfort until we fix this "big daddy" one. Then it will be each in turns oppourtunity to be helped.

The explicitness of assignment is resisted in many ways, Some see it as eliminating the ability to blame others in those production
meetings
Some as imparting too much constraint on their "art". Some as micro management overload when in actuallity the task assignment can
be as "macro"
or "micro" as suits the situation; so that one is just a falsehood but the others are lack of experience. Explict task assignment
means focus, not detail.
Focus generates "flow" and the joy in anything comes when you are in the "zone", concentrating, doing better than before,
anticipating the next move.

 

[John]

No worries, not to much help in terms of "how" to do anything really.
But you said that you had been working on this for a while so I thought
maybe a different "think" about it might help.

John,
I hadn't been working on it for a while because I didn't ask the
question. It was Andy the Viking, (by the way, who ever heard of a
viking named "Andy"), the original poster, who was going nuts trying to
figure it out.

John
Project MVP

 

[John Sitka]

Oops,

http://www.andythevikingfordham.com/

One hundred ......and forrrrrrtttttyyyyyy! cheer cheer

 

[Andy the Viking]

Ok guys, thanks for all the info, I off to try and phathom out what it all
means !!! There are some very valid points beiong made and perhaps I should
be looking at changing my project approach rather than forcing the
application to fit 'my way' of doing things.

Thnaks once again for all the effort put in.

Andy

 

[Andy the Viking]

Wowa - you're cooking on gas there John. will take me a while to comprehend
that lot, but I will try honest.

PS 'The Viking' bit is based on a convoluted basis of being half swedish and
the fact that when I first start going on-line and wanted a 'nom de plume'
there was a popular kids TV character called Eric the Viking here in the UK.
Andy the Viking Fordham came along later, I'm planning on suing for identity
theft ;-) oooonnnneee huuunndreeeed and eeeightty (sorry all non UK people
tha probably means nothing to you).

 

[Andy the Viking]

Thanks, page book marked and awaiting John's updates.

 

[Jan De Messemaeker]

Oh yeah? And what about Van Barneveld?

 

[John Sitka]

Geez I really want to go spend a whole day in a nice warm pub now.
Drinking pints, having a lunch special, throwing a couple games, MSNBC on the tele.
Heaven!

 

[John]

Thanks, page book marked and awaiting John's updates.

Andy,
If you are looking for more detail in the proposed new FAQ I quoted,
there won't be any. The excerpt I posted is the complete text, (sans
some editing), on the issue of assigning resources to summary lines. I
only included it in my response because some users like to assign
management support at the summary level. Our new FAQ simply presents the
possible negative consequences of using that approach.

John
Project MVP