Re: Adding to a Contingency Line Item
- From: "davegb" <davegb@xxxxxxxxxxxxxx>
- Date: 29 Jan 2007 15:53:53 -0800
I'm not clear why starting with the deliverables would be bottom up,
but it is just a disagreement in terminology. What you call top-down,
I call "by edict".
I'd also add that I think starting with "deliverables" is very
dangerous and I've seen it lead to major screw-ups. The best example I
can remember is when an otherwise pretty sharp manager I had years ago
told the IT dept to order a particular kind of CAD software that he
had heard about from a neighbor. After expending over $5M in software,
hardware and training over the next few years on a system that was
obviously a dismal failure, it was replaced with a suitable CAD system
(when a new manager took over). The orignial system was designed for
the aeronautics industry and could not be adapted to the oil/gas
business. The guy who recommended it to our manager was in aerospace!
They started with a "deliverable", "get product X", without looking at
what they were trying to achieve and the ability of product X to
deliver it. Had they started with an achievement, i.e., "Procure and
install Process industry CAD software and train personal in the use of
it" they probably never would have bought X. This is one of the main
differences between Achievement Based Planning and what I call "task
based planning", aka "deliverable based planning". There are other
significant differences, but that's another story!
On Jan 29, 2:16 pm, "Steve House" <sjhouse.rem...@xxxxxxxxxxxxxxxxxx>
wrote:
To me, top-down implies the boss comes to you and says "I want you to head
up a project to do xxxx and I'll budget up to $yyyy for you to accomplish
it" or the sales department comes to you with the news that "We just signed
a contract with XXX client to deliver YYYY at a fixed price of $ZZZ." The
budget is set through some a priori process before you even have a clue what
is going to be involved in carrying out the project. Bottom up, OTOH, says
"We need to do the following work in order to complete the project and it's
estimated to cost $XXXX." In other words, top-down starts with an allowable
budget and you figure out what deliverables you can achieve for that money
while bottom-up starts with the required deliverables and derives the budget
from their estimated cost.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visithttp://www.mvps.org/project/faqs.htmfor the FAQs
"davegb" <dav...@xxxxxxxxxxxxxx> wrote in messagenews:1170104521.515370.246130@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Maybe our differences are more about definitions than application. To
me, starting with "What do we need to achieve?" is the basis of
Achievement Based Planning, which I consider a top down planning
model. All the questions you mention are what I call top down
planning. Asking the big questions first, then working your way down
to a task list from there.
To me, bottom up is when you start by creating a task list, then work
your way up from there.
On Jan 25, 4:22 pm, "Steve House" <sjhouse.rem...@xxxxxxxxxxxxxxxxxx>
wrote:
The problem with top-down, as I see it, is that essentially it involves
saying "We have this much money available this year, what can we do with
it?" rather than the bottom up approach that says "What do we need to
achieve? How much will it cost to achieve it? Do we have the assets
available to do it? What trade-offs do we have to make in order to make
the
needs and the assets fit?"
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visithttp://www.mvps.org/project/faqs.htmforthe FAQs
"davegb" <dav...@xxxxxxxxxxxxxx> wrote in
messagenews:1169478475.227820.274120@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Steve House wrote:
Remember the primary function of Project is to be a work scheduling
and
cost
estimating program. It appears you are trying to use it as a top-down
budget planning program. In fact, it doesn't do top-down anything
very
well. Even with the thing it's designed to do best, scheduling work
hence
estimating durations, the duration of tasks does not reflect the time
allowed for them. Rather they are your best guesstimate of the time
that
each physical activity will take from when work on it begins until
work
on
it ends. Project planning, both for time and for budget, is always a
bottom-up process rather than a top down process - you're most
concerned
with what will be required to achieve the deliverable and then you can
look
at whether you have the assets available needed to pull it off.
I have to respectfully disagree with Steve on this. In many cases, our
experiences vary. In my experience, I prefer top-down planning of
projects, in which the desired final result is carefully determined,
then the major milestones neccessary to achive that final result are
determined, then broken down further and further until the desired
level of detail for effective project control is achieved. Once those
tasks are known, their durations and dependencies are determined, and a
bottom up process of calculating the overall duration, cost, resource
needs, etc., can procede. It's just one approach among many.
One of the approaches that works this way is called "Achivement Based
Planning". It starts by determining exactly what the project is
supposed to achieve. The advantage of this approach is that it avoids
many of the pitfalls you find in project planning, such as doing a
project that doesn't really need to be done at all or doing a project
that solves the wrong problem, or approaching the problem in a less
effective manner because you weren't sure why you were doing it in the
first place. I've seen all these things happen, and on some pretty good
sized projects.
This is just one Project Planning Methodology among many. I have found
it to be effective because it avoids many of the strategic problems
encountered in planning. It's certainly not the only one, nor even the
only effective one. Just one that I found to help me to be a better PM.
Hope this helps in your world.
If you do
need to track present estimates against a top-down budget, grab a
spare
cost
or numeric field to hold the bedget data. (The 'time budget' is best
tracked
by using deadline field entries to represent the required delivery
dates
for
the relevant tasks rather than trying to kludge up some sort of
'maximum
allowed duration' metric).
In you can, if B & C are truly component tasks of deliverable A, then
A
should be a summary and B and C its children. But you need to insure
that
ALL of the other components of A are also detailed out in order to
have
valid rollup figures. When you do, the duration of A is from when its
earliest starting child begins until its latest finishing child ends,
no
more and no less. And of course this is determined by the durations
of
the
subtasks, with their various start dates determined by the combination
of
the effects of dependency links taking into account lag and lead time
plus
the influence of any start time constraints. If plugging all this in
has
an
impact on your current duration estimate for the summary task then the
process you used for determining its present duration is in error.
John is spot on with his suggestion not to use the summary fixed cost
as
you
have. Fixed costs at both the subtask and the summary task levels
roll-over
into the total cost of that line item but they don't roll-up in the
fixed
cost column itself. This is to allow for a situation where there is a
fixed
cost associated with a summary line that is in addition to the fixed
costs
associated with any of its subtasks. The ultimate total appearing in
the
summary line Total Cost field is = sum(subtask resource costs) +
sum(subtask
fixed costs) + (summary task fixed cost). As you can see, roll-ups
from
subtask to summary occur in the total cost field so they do ultimately
get
rolled up. If you do as you have done and try to use the summary
fixed
cost
as a manually entered roll-up, you'll end up doubling the total fixed
cost
component of the Total Cost field over its true value.
HTH
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visithttp://www.mvps.org/project/faqs.htmforthe FAQs
"kraus" <k...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:2DBFF509-14C5-4E45-95CA-CB4BD0FE9258@xxxxxxxxxxxxxxxx
I have set up a consultant contingency line item in my project plan
and
baselined it.
Consultancy Contingency = $151,655.00
Duration = 100wks (covers planning and execution phases)
I am now engaging some consultants and want to reflect the change in
the
consultant contingency line item but also reflect in the project
plan
the
additional work added.
My original line was "A" (below) as the baseline. Lines "B" & "C" is
the
work after the fact that I would like to deduct from "A". I have
been
trying
to work it out myself, you'll notice the fixed cost in "A" equals
the
total
of "B" & "C". Ideally I would like "B" & "C" as sub-tasks of "A" but
this
will mess up my baseline not to mention the duration impact, "B" &
"C"
took
2wks and this would also be the duration of "A" if it were the
rollup
task
but I want this to stay at the 100wks.
Fixed Cost Total
Cost
Baseline
A. Consultancy Contingency $4,395.00 $4,395.00m $151,655.00
B. Hospitality Consultant Prepare
Hospitality Report $0.00 $3,500.00 $0.00
C. Hospitality Consultant Review
Schematic Design $0.00 $895.00 $0.00
Any suggestions would be appreciated.
David- Hide quoted text -- Show quoted text -- Hide quoted text -- Show quoted text -
.
- References:
- Re: Adding to a Contingency Line Item
- From: Steve House
- Re: Adding to a Contingency Line Item
- From: davegb
- Re: Adding to a Contingency Line Item
- From: Steve House
- Re: Adding to a Contingency Line Item
- From: davegb
- Re: Adding to a Contingency Line Item
- From: Steve House
- Re: Adding to a Contingency Line Item
- Prev by Date: Re: Two Week Project schedule by hour
- Next by Date: Re: Master Project
- Previous by thread: Re: Adding to a Contingency Line Item
- Next by thread: Duration is greyed out
- Index(es):
Relevant Pages
|
