Managing
Change
to
Estimates
|
Rating
|
|
Neville Turbit - Project Perfect
|
 |
|
|
|
Scope
Creep
Once upon a time there was an old man who had lived in the one street all his
life. He wanted to keep his memories of the people who worked in the street
and asked an artist if he would help.
"How much do you charge, and how long does it take to do a portrait of a
person?" He asked.
"I charge $100 and it takes a day to do each portrait." Said the artist.
The old man took the artist into the street and asked him how much, and how
long, to paint everyone in the street. The artist looked down the street,
and counted 20 people. He said
"$2,000 and 20 days."
The old man then walked him to the other end of the street.
"Now count the
people."
To his surprise the artist could now see 30 people. Some were in doorways.
Some couldn't be seen because they were standing behind other people. One
person had been doing up a shoelace behind a car. The artist said
"Sorry, but it will cost $3,000 and take 30 days."
"I am sorry too." Said the old man. "You quoted me $2,000 so that is what
you get paid, and I expect the pictures in 20 days."
"But how could I see the other people? I was only at the beginning of the
street. I couldn't count what I couldn't see until I got to the end."
"I was once a Project Manager." Said the old man. "I made the same
mistake as you. I was only too keen to count what I could see and give
an estimate for how much and how long. It took me a long time to start
counting what I couldn't see, and build in an allowance for the unknown.
You gave a commitment and now you need to deliver."
"Incidentally, remember I was a Project Manager and know all the tricks.
Don't start cutting the quality or size of the pictures."
|
|
Does this sound familiar? How often do we count what we can see, and make
an estimate based on that. Again and again, the time blows out because of
what we didn't know we had to count. It is common sense to know that if we
are trying to plot everything that needs to be done over several months in
a project, we will not be able to see everything. We must make allowances
for the unknown.
Try this exercise when explaining the concept to a person who is demanding
an estimate. Ask them to write down everything that they are going to do next
weekend - from midnight Friday to midnight Sunday. Allocate a time to each
task. Add up all the times and see how much free time they have in the 48-hour
period. Chances are you will come up with 8 or 10 hours of free time. When
you ask them if they will have that time free, the usual response is
"Of course I won't have that amount of time free. The kids will need to be
taken somewhere, and there will be a few people drop in or phone me, or we
will decide on the spur of the moment to go out for lunch. I will be lucky
to have 2 or 3 free hours."
Projects
are
no
different.
There
will
always
be
unforeseen
activities.
To
sit
down
and
list
all
the
activities
you
know
about,
then
allocate
a
time
to
each
activity,
then
add
up
the
time,
will
only
give
half
the
picture.
If
you
can't
see
it,
it
doesn't
mean
it
isn't
there.
So
how
to
handle
the
contingency.
In
most
organisations,
contingency
is
a
dirty
word.
Here
are
a
few
strategies.
Contingency
The further away the activity, the more difficult it is to scope. You have
a good idea of what you are doing tomorrow, and how long it will take. You
don't have the same clarity about the week after next. In this case, take
the activities towards the end of the phase and double the time.
For example, the phase is to produce a requirements report. You think after
all the workshops and interviews, the report will take three days to write
up. Make it six days. Build in a review step which will take a day, and a
rework activity that takes another day. If challenged, talk about adding quality
to the output by undertaking a formal review prior to delivery.
Contingency
Planning
Not as effective as padding, you can gain approval for a budget and schedule
that reflects what you know now. Argue that the quote is only for what is
specified in the list of activities. For additional activities there should
be a separate fund where time and cost can be added to the project, subject
to approval by the Sponsor.
When
something
comes
up,
there
is
a
process
in
place
to
go
to
the
Sponsor
and
draw
on
the
funds.
To
make
this
happen,
the
Sponsor
needs
to
understand
that
foresight
is
not
as
accurate
as
hindsight.
The
responsibility
also
is
passed
to
the
Sponsor
to
agree
variations
or
to
reject
them.
Timeboxing
Move the focus from Scope, Resources, Cost and Quality, to Time. Agree with
the Sponsor that we will achieve as much as we can within the fixed time period.
In this way when a scope variation arises, you can take the option to the
Sponsor to include the variation but take out something else (or perhaps provide
more resources or money).
Phase
by
Phase
Estimating
By far the most effective way to estimate is on a phase by phase basis. By
phase, I mean a two to six week chunk of work with clear deliverables. It
is far easier to forecast six weeks ahead rather than six months ahead.
Historical
Trends
This
is
a
more
painful
path
but
can
prove
a
point.
Record
the
time
and
cost
estimates
for
each
project
(or
phase)
in
the
organisation.
Compare
them
with
the
final
result.
Over
a
period
of
a
year
or
two,
you
will
start
to
throw
up
a
pattern
of
the
level
of
underestimation.
Use
this
as
the
basis
for
your
contingency.
Summary
Making accurate estimates in an IT project is a flawed technique. IT estimation
is an art, not a science. That is not to say there should be no estimate.
No estimate is worse than an incorrect estimate. At least if an estimate exists,
you can see how you vary as the project proceeds.
The key is to get the organisation to understand it is not a fixed tender.
There will be variations because with IT projects, the future is rarely clear.
Farmers might forecast income for their crops, but they cannot predict drought
and flood. They cannot foresee disease or attack by pests. They cannot control
world markets that dictate prices and demand.
Similarly
IT Project Managers do not have control over the complexity and cost of the
required solution until the evaluation of the proposed solution is complete.
How many simple name and address solutions have turned into multi-million
dollar CRM implementations? How many software purchases have become hardware
upgrades when the finally selected solution came to be implemented?
The critical questions are often not visible at the start of the project.
Even if they are, they may not be answerable unless you provide all the permutations
on how the question might be resolved. The answer would become meaningless.
The correct answer is that the project will take X months and Y dollars however
our best guess is that the estimate might be out by up to Z%. It should be
expected that the numbers will change. As the project progresses, Z% hopefully
reduces, and X months and Y dollars can be refined.
To date, 43 people have rated this article. The average rating is 3.98 - Add your rating. Just select a rating and click the button. No other information
required.
Only one rating per person is allowed.
|
Contingency in Projects
|
Return to the top
