S
St Dilbert
For exactly that reason (update data collection is on a per-task basis
and that will be less than the full hours of a work day) I often went
the way Jan described (restrict daily working time) - I'm quite happy
with that approach. Since the cost of most resources is still charged
to the project in full and we don't track the hours for "other things"
I increase the cost per day for those resources reciprocal (i.e.
1/0.8=1.25 for your setting).
In most projects we start our estimates after developing a work
breakdown structure. We get the estimates from the people who will be
performing the work. Since we usually go through a prioritization of
the WBS before actually baselining a plan, there is a real need to have
the "delivery work only" for each WBS element we call it the "net
effort".
I've seen many estimation workshops where it was really helpful to
explain that the scheduling would assume (e.g.) 6hours of "net delivery
time" for each 8h day. It made the estimators feel safe to just enter
the "net hours" and it also communicated the idea that "all that
overhead communication and meeting stuff" should fit into about 2h per
day on average. In delivering the project people often referred to that
estimation benchmark when rebalancing between "we have too little
cross-functional information" vs. "we're spending too much time in
meetings". Also it improved the feeling of ownership in the individual
estimate, because the "net effort" is something one individual can
control and it removes that "soft overhead" part in the modules
estimate that increases the apparent cost of one indiviual deliverable
while leaving a feeling of "I can't control that 25% of my work anyway,
so it's somebody else's fault if I go over the estimate".
You're mileage may vary, but if there is a shared understanding of that
purpose of that approach it can be very helpful. I've been able to
implement meaningful EVA for those projects (I attribute that to the
"increased ownership in estimates effect") and since there was no
tracking of the overhead tasks in hours it also wasn't perceived as
micromanaging at all.
Good luck for your next projects!
and that will be less than the full hours of a work day) I often went
the way Jan described (restrict daily working time) - I'm quite happy
with that approach. Since the cost of most resources is still charged
to the project in full and we don't track the hours for "other things"
I increase the cost per day for those resources reciprocal (i.e.
1/0.8=1.25 for your setting).
In most projects we start our estimates after developing a work
breakdown structure. We get the estimates from the people who will be
performing the work. Since we usually go through a prioritization of
the WBS before actually baselining a plan, there is a real need to have
the "delivery work only" for each WBS element we call it the "net
effort".
I've seen many estimation workshops where it was really helpful to
explain that the scheduling would assume (e.g.) 6hours of "net delivery
time" for each 8h day. It made the estimators feel safe to just enter
the "net hours" and it also communicated the idea that "all that
overhead communication and meeting stuff" should fit into about 2h per
day on average. In delivering the project people often referred to that
estimation benchmark when rebalancing between "we have too little
cross-functional information" vs. "we're spending too much time in
meetings". Also it improved the feeling of ownership in the individual
estimate, because the "net effort" is something one individual can
control and it removes that "soft overhead" part in the modules
estimate that increases the apparent cost of one indiviual deliverable
while leaving a feeling of "I can't control that 25% of my work anyway,
so it's somebody else's fault if I go over the estimate".
You're mileage may vary, but if there is a shared understanding of that
purpose of that approach it can be very helpful. I've been able to
implement meaningful EVA for those projects (I attribute that to the
"increased ownership in estimates effect") and since there was no
tracking of the overhead tasks in hours it also wasn't perceived as
micromanaging at all.
Good luck for your next projects!