Maintain budget constraints with new activities

[DWeb]

Hello! I am looking for suggestions for how to approach the following
scenario.

I have a list of issues that represent work requests. Each of these issues
may or may not spawn one or more change requests (CRs) that will always be
associated with the parent issue. I currently have high-level work estimates
for each issue, broken out by phase (i.e. Requirements, Design, Build, Test,
Deploy).

I would like to track work/schedule/assigned resources for each issue (and
any associated CRs) and be able to show that the CRs roll-up to a given
issue. As CRs come up, I would like to be able to add the CR (as a subtask
of the issue if that makes sense) and associate a portion of the "budget" for
that issue to the CR, leaving the remaining budget with the issue.
Similarly, if another CR is added, I would like to be able to carve out part
or all of the remaining issue budget and associate it with the CR. Each CR
would have the same phases as the original issue. Resources can be assigned
to the issue, CR, or both.

So if issue #1 had 10 hours each for Requirements, Build, Test, Deploy, if I
add CR #1-1 with those same phases allotted at 5 hours each, then issue #1
would show 5 hours of budget for each phase. If I added 2 such CRs (#1-1
and #1-2) at 5 hours per phase, then the original issue would show 0 hours
remaining for each phase.

Another component of this scenario is that I would like to be able to
quickly see that a group of issues/CRs and the associated tasks are related.
I thought about using a custom field to hold the parent issue #, but realize
that may make for the same value repeated in multiple rows, which I guess can
be automated by macros, but I'm open to thoughts on this as well.

Sorry for the long-winded description - I hope it made sense. Please
respond with any suggestions or guidance. I do appreciate it.

 

[John]

DWeb,
First, don't apologize for explaining your question. Yes it may be a
"drag" having to read it all but it sure beats the short, curt, poorly
written posts that at best beg more questions than answers and at worst
are indecipherable.

I think the gist of your question is how to handle added tasks within a
fixed budget requirement. I'll provide some simple answers. Hopefully
others will give their viewpoint.

First, given your situation, (i.e. a normal changing environment with
limited resources), it is always prudent, (no, necessary), to set aside
a management reserve from the original budget for contingencies and
inevitable changes. One rule of thumb sets the value at 10% of budget.
It depends on corporate policy, customer requirements, and experience.
The budget reserve can be shown as a separate line item in the existing
Project plan or held separately, outside the plan. It must be used only
after careful analysis of "added" requirements. There is always give and
take.

Another approach is to lay out detail tasks only for the near term.
Depending on the overall length of the project, this may be tasks
scheduled to begin in the next few weeks or for longer plans, the next 3
to 6 months. Tasks beyond the immediate are scoped for an estimated
budget and left as "planning packages". That is, the detail of
performing those planning package tasks is not developed until they come
into the near term window. That also means that the budget allocated to
them is tentatively available if needed for unforeseen near term tasks.
It is kind of like a reserve but requires VERY careful and deliberate
review before budget for future phases is re-allocated to resolve
immediate issues lest you run out of money before the project is through.

This is all part of Project Management. Being able to effectively jockey
money, labor and tasks to complete a project. Sometimes you get lucky
and are able to find more efficient ways to accomplish tasks with fewer
resources and sometimes you just need to make you case to upper
management to secure additional budget.

Hope this helps. See, I get a bit wordy also.
John
Project MVP

 

[DWeb]

John - thanks for the quick reply! I do appreciate the feedback. I think we
are attempting to lay out the detail tasks for the near term, but are looking
for a mechanism within MS Project to manage it. I think establishing those
issue budgets I mention addresses the "planning packages" idea you mention.

In our case, we know our resource budgets and the work that is currently on
our plate. We have established a means for prioritizing the work and are
finalizing high-level estimates for the work. We fully expect to see far
more work than we have resource availability and have gone through the effort
to establish what % of each resource's time is available for these
issues/CRs, as many of them will also be doing ongoing customer support and
tech support activities.

I guess my question was less about how to maintain budget constraints as to
how best to programatically administer the scenario I mentioned in MS
Project, keeping the consideratios you mention in mind.

 

[Steve House [MVP]]

One of the issues to be aware of is the word "budget" can have different
meanings. The everyday usage is that it represents a top-down allocation of
funds to various possible activities - in a real sense it is a distribution
of projected revenues and represents the maximum you might be allowed to
spend for each activity. But note that in that context the budget is based
on the projected availability of funds, not the projected actual costs of
the activity itself. It sounds like that is how you are using it - you have
a certain number of issues and each one has been allocated $XXX to resolve
it. Then as a CR is added, you want to draw the allowed expenditure for
that CR out of the pot allocated to its parent issue. But that's not quite
what "budget" means in a project management context. As MS Project and PM
in general uses the word, the budget is a bottom-up estimate of projected
actual cost. When you have a summary task (one of your issues) and subtasks
(the CRs associated with the issue) the budget of the summary is defined as
the sum of the costs of the subtasks. Indeed, the budget of the summary has
no independent existence and can't be estimated until the subtasks have been
defined and their respective costs estimated. Perhaps I have an Issue with
a budget of 500 hours and there are already 5 CRs defined for it. I now add
another CR and enter a budget for that activity of 100 hours. That doesn't
cause the budget of the summary to drop to 400 hours. Instead, it does just
the opposite, the budget of the summary will *increase* to 600 hours
reflecting the additional work in the new CR.

If you need to track projected hours versus allowable hours, you perhaps
could use a couple of user defineable fields to hold the allowable and
subtract the projected from it.

 

[John]

One of the issues to be aware of is the word "budget" can have different
meanings. The everyday usage is that it represents a top-down allocation of
funds to various possible activities - in a real sense it is a distribution
of projected revenues and represents the maximum you might be allowed to
spend for each activity. But note that in that context the budget is based
on the projected availability of funds, not the projected actual costs of
the activity itself. It sounds like that is how you are using it - you have
a certain number of issues and each one has been allocated $XXX to resolve
it. Then as a CR is added, you want to draw the allowed expenditure for
that CR out of the pot allocated to its parent issue. But that's not quite
what "budget" means in a project management context. As MS Project and PM
in general uses the word, the budget is a bottom-up estimate of projected
actual cost. When you have a summary task (one of your issues) and subtasks
(the CRs associated with the issue) the budget of the summary is defined as
the sum of the costs of the subtasks. Indeed, the budget of the summary has
no independent existence and can't be estimated until the subtasks have been
defined and their respective costs estimated. Perhaps I have an Issue with
a budget of 500 hours and there are already 5 CRs defined for it. I now add
another CR and enter a budget for that activity of 100 hours. That doesn't
cause the budget of the summary to drop to 400 hours. Instead, it does just
the opposite, the budget of the summary will *increase* to 600 hours
reflecting the additional work in the new CR.

If you need to track projected hours versus allowable hours, you perhaps
could use a couple of user defineable fields to hold the allowable and
subtract the projected from it.

Steve,
From my experience most projects are a combination of bottom-up and then
top-down budgets. The performing organizations lay out the plan complete
with resources and associated costs. Bottom-up, all is well and good.
However, then upper management or a customer steps in and negotiates the
WBS of the plan in a fact finding mission. From that, a negotiated
budget is set. That budget is then applied to each piece of the program
plan, which may or may not have been appropriately de-scoped during
negotiations, and the baseline is set. On top of that, management pulls
a management reserve. The resulting overall "budget" is then a
"challenge" and may be part of criteria for incentive clauses in the
contract.

Yeah, probably not the ideal situation, but it's the scenario I'm most
familiar with and probably not unique.

John

 

[Steve House [MVP]]

Yet "budget" as used in earned value BCWS and BCWP is always bottom-up. The
problem with a "negotiated" top down budget from a PM context is that it
bears no relation to what it will cost to produce the required deliverable.
If it takes 10 hours to paint that wall, that is what it will take.
Anything less and the wall isn't painted, at least not to acceptable quality
standards. No amount of negotiation can change it. No amount of management
desire or skill, no amount of will power, no amount of drive or
determination, no level of negotiation skill, will change it. The Board
gets so angry at costs going out of control they're going to fire everyone
in senior management for their alleged incompetance - it's still going to
take 10 hours to properly paint that wall. Physics is physics <grin>.

Top-down Allocation > Required Budget = Successful project
Top-down Allocation < Required Budget = Update your resume, the project is
doomed at birth and cannot successfully be completed under any
circumstances.

--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

 

[John]

Steve,
The wall painting example in my opinion is a rather simplistic case.
Yes, some activities are well enough understood that they can be quite
easily bounded when it comes to estimating how long it takes to do them.
But, just to keep it interesting, let's say that the 10 hour painting
estimate is based on a tried and true brush, roller or even spray method.
Perhaps the painting contractor has decided to try a new method (let's
call it "paint vapor deposition") that was developed by Behr and using
that technology the time to paint the wall will be 1 hour. Yeah, I know
it sounds ridiculous, but then so was transcontinental flight some years
ago. Here is a case where management may have a little more information
than the people doing the bottoms-up estimate. Should that information
have been shared with the performers before the estimating process
started? Probably. My point is, human activities are rarely defined by
physics. Rather, they are defined (and changeable) by the application of
human effort to achieve a physical output.

Ok, you don't like my example. Many activities particularly in the
technology field are not so easily predictable as painting. Estimates
for these activities are often based on experience, (and maybe not a
very happy one), of the estimator. In this case the bottom-up estimate
may in fact be "loaded" with excessive contingency hours. Management may
or may not have a better handle on what a plan should take and this
"global experience" may make a top-down estimate equally viable as far
as overall program success.

No one, task performers, management, or customer, knows what the
"required" budget for a successful program is until the program is over.
Hindsight is great. In that regard no one knows if the bottom-up or
top-down allocation is closer to the required budget. "Past performance
is no guarantee of future results", to quote the matra of the securities
industry.

Since "required" budget is an undefined amount when a project is
estimated, one might say that a negotiated budget based on a combination
of bottom-up and top-down is viable approach and in a world where "you
can't always get what you want", the best approach.

Just another viewpoint.
John

 

[doniy]

John,

I agree with you. Sorry for my poor English, hope you can understand.
Estimates depends on experience,a detailed buttom-up approach in real
project is sometime not applicable.

For example,Pulling cable, we have cables big than one's leg, small than
one's finger.We really do not know how many hours we need to finish. but we
know all the cables for this system takes 30 days to finish based on previous
experience.when the work is ongoing, compare the progress with remaining
work,we will have a more accurate estimation.

Sometime we need to track cost, but at the moment design is not completed,
how can we make a buttom-up budget, what we can do is to distribute
"negotiatied budget". We assigned cost to tasks without resource assigned to
them in some project. we just want to know the overall picture of cost of the
project over time. Some of these project have more than 100000 tasks, to
finish a single tasks of the 100000 tasks we need dozens of resources,how can
we deal with it buttom-up?

Each time I do a different kind of project, I have no idea of duration
estimation. It will take me a lot of time to learn this kind of project and
those tasks,when I become experienced the project will finish. Next project
may be a powerplant, while this project is Metro.

I am thinking about what is the right way for a scheduler?

 

[Jan De Messemaeker]

Hi John,

I'd like to repeat some in your memo:
"In this case the bottom-up estimate
may in fact be "loaded" with excessive contingency hours"

You can say that again. I'd rather say that nearly all bottom-up estimates
ARE loaded.
I first "met" Project Management from an other angle - being promoted head
of all the PMs in a software shop - and my respect for UNCHALLENGED
bottom-up estimates is very, very low.

OBTW, lost of people don't load - but they wildly underestimate!
Greets,

 

[DWeb]

Thank you for the feedback! I realize budget is a term with multiple
connotations and meanings, depending on the audience. I appreciate the
suggestion to use user-defined fields. I'll see if I can make that work.

 

[Steve House [MVP]]

I agree my painting example is simplistic but I think the principle is true.
A top-down budget is based on what the company can afford, based on an
analysis of the funds in the coffers and handed down by executive fiat. It
does not take into account what is required to actually do the work at hand
except in the broadest sense.

I have to disagree with your statemnent that management could have a better
knowledge of the conditions than the people doing the bottom up estimating
because IMHO, that job should be done by the Project Manager. The PM is a
member of mid-level management who is specifically charged with being a
subject matter expert in the nature of the project or having subject matter
experts at his dispoal and that expertise is what will be used in preparing
the bottom up estimates. Using your example, it's not the Controller or CFO
originating the top-down budget who knows about the new painting technology,
it's the Project Manager who either is an expert on painting or consults
with an expert in painting during planning.

 

[John]

doniy,
First, I don't have any problem with your English. Your post is better
than many of them I see where the user's first language IS English.

Just to make it clear, I don't disagree with Steve's bottom-up advocacy.
I think perhaps he has been burned one to many times by "forced" budgets
from upper management and/or customers. I've also been in that
situation. However, when dealing with performers, management and
customers, it's all about compromise. If the balance is fair the project
will succeed regardless of budget. If it's not, the project will fail
and a lot of finger pointing will result.

Ok, enough soapbox theory. In my experience the best estimating methods
center around historical data, experience and educated guesses. You just
can't do any better than that. Any plan is going to be dynamic. Your
approach of basing the original estimate on experience and then updating
as the work progresses is the right way to go. The idea of allocating
funds without resources is basically the planning package approach I
mentioned earlier. If the plan starts to get out of hand and you end up
using too much allocated budget from far term planning packages to solve
real present days problems, then you either go back to the table and
re-negotiate for more funds or change the scope of the plan (i.e
re-define project success). There is just no other way. The "best laid
plans" are just like life, give and take. And success can be defined and
measured in many ways.

One thing you mentioned does bother me. You mentioned that you have
projects with more then 100K tasks. In my experience, any Project plan
with anything more then 10K tracked tasks is much too detailed and
impossible to manage. Group the little tasks into more general
categories that are easy to manage. Keeping the tasks at a reasonable
level also serves to buffer the "winners" and "losers" that cause
Project Management headaches. In a way, its a little like having a
diversified financial portfolio. If the total number of tasks still
exceeds 10K (and that's even a very tough number to effectively manage
in my opinion), then consider breaking the overall project into small
subprojects. For example, instead of tracking every task necessary to
build every car General Motors makes, break the effort into divisions
(e.g. Chevy, Pontiac, etc. or perhaps frame, body, electrical, etc.).

No idea of duration on new projects? Tilt! Maybe you don't have an idea
but I can't believe no one else in your company does either. Otherwise
the project is outside you company's core business. The people in your
organization who have actually done that type of task are your best
resource. Tap their knowledge base. It's the bottom-up data we've been
discussing. You just have to apply the test of reasonableness. And
remember, Duration and Effort are two independent things. If the person
giving the estimate is biased, the bias will more likely apply to the
effort (hours to perform a task). Estimates of Duration should be more
immune to a bias. On the other hand, if it's a project that your company
has never done, you might need to get outside help (i.e. consultants,
contacts in similar industry, etc.).

Hope this helps.
John
Project MVP

 

[doniy]

John,
Thanks for your advice.

doniy,
First, I don't have any problem with your English. Your post is better
than many of them I see where the user's first language IS English.

Just to make it clear, I don't disagree with Steve's bottom-up advocacy.
I think perhaps he has been burned one to many times by "forced" budgets
from upper management and/or customers. I've also been in that
situation. However, when dealing with performers, management and
customers, it's all about compromise. If the balance is fair the project
will succeed regardless of budget. If it's not, the project will fail
and a lot of finger pointing will result.

Ok, enough soapbox theory. In my experience the best estimating methods
center around historical data, experience and educated guesses. You just
can't do any better than that. Any plan is going to be dynamic. Your
approach of basing the original estimate on experience and then updating
as the work progresses is the right way to go. The idea of allocating
funds without resources is basically the planning package approach I
mentioned earlier. If the plan starts to get out of hand and you end up
using too much allocated budget from far term planning packages to solve
real present days problems, then you either go back to the table and
re-negotiate for more funds or change the scope of the plan (i.e
re-define project success). There is just no other way. The "best laid
plans" are just like life, give and take. And success can be defined and
measured in many ways.

One thing you mentioned does bother me. You mentioned that you have
projects with more then 100K tasks. In my experience, any Project plan
with anything more then 10K tracked tasks is much too detailed and
impossible to manage. Group the little tasks into more general
categories that are easy to manage. Keeping the tasks at a reasonable
level also serves to buffer the "winners" and "losers" that cause
Project Management headaches. In a way, its a little like having a
diversified financial portfolio. If the total number of tasks still
exceeds 10K (and that's even a very tough number to effectively manage
in my opinion), then consider breaking the overall project into small
subprojects. For example, instead of tracking every task necessary to
build every car General Motors makes, break the effort into divisions
(e.g. Chevy, Pontiac, etc. or perhaps frame, body, electrical, etc.).

No idea of duration on new projects? Tilt! Maybe you don't have an idea
but I can't believe no one else in your company does either. Otherwise
the project is outside you company's core business. The people in your
organization who have actually done that type of task are your best
resource. Tap their knowledge base. It's the bottom-up data we've been
discussing. You just have to apply the test of reasonableness. And
remember, Duration and Effort are two independent things. If the person
giving the estimate is biased, the bias will more likely apply to the
effort (hours to perform a task). Estimates of Duration should be more
immune to a bias. On the other hand, if it's a project that your company
has never done, you might need to get outside help (i.e. consultants,
contacts in similar industry, etc.).

Hope this helps.
John
Project MVP

 

[John]

John,
Thanks for your advice.

doniy,
You're welcome. I hope you get it worked out.

John