[Mark == [EMAIL PROTECTED] on Mon, 1 Nov 2004 15:45:34 +0000 (UTC)]
Mark> So, what resources are recommended to consult to make great
Mark> estimates? What habits to develop?
Estimate only what you know. My preferred model is to "bid" on only
"one phase at a time". During kickoff, I'll give a client a firm
budget for the discovery phase, but only a "rough estimate" of the
planning, implementation, and rollout phases. When discovery is done,
I'll prepare a firm bid for "planning", but still only have a rough
estimate for implementation.
Most clients respond relatively well to this. If they push hard on
wanting a firm estimate up front for something that's not already
well-specified, then the developer's risk inevitably goes up. The
standard mechanism to absorb this risk is to increase your profit
margins to readjust the risk/reward ratio.
Really smart clients actually realize that fixed-bid estimates
generally end up costing more than straight time-and-materials, since
they are forcing their vendor to absorb risk. (Assuming of course the
vendor is honest in general.) But few clients are actually this
savvy, so I sympathize with the pressures to deliver an "up front
estimate".
Mark> I know that before the good estimate comes the strong
Mark> technical specification so you can know what you are
Mark> estimating-- that much I think I do well at.
I'm pretty good at it too, but that really only works for smaller gigs
where the work is substantially similar to something you've done
before. My limit for being able to write a complete tech spec up
front is about 4-6 person-weeks. Beyond that, it's best to get over
the fantasy of being able to do accurate "up front specification"
leading to a solid, accurate estimate. You're just guessing at that
point, and no estimation tips-and-tricks is going to replace
experience and gut instinct on the right price tag to put on a piece
of paper.
Consider changing how both you and clients approach the idea of an
estimate. Estimation is an ongoing process, not a 1-time activity up
front. Use phrases like "current best estimate". Always have an
estimate range for how long the remaining work will take to reach
certain milestones.
I actually tend to jump on this process, and walk out of the first
phone call/meeting already having told the client my "current best
estimate". "So, off the cuff, my experience tells me this should be
about a 2-4 week planning phase followed by about 2-6 week
implementation/rollout phase, broken into about 4 releases. We of
course won't find out reasonably accurate implementation costs until
about release 2, but I'll try to continually refine these numbers for
you. I know you need to control your budget, so I'll commit at this
point to delivering a list of things we need to decide by the end of
planning for a fixed bid of 40 hours work". Whatever, something like
that, to lead them into seeing that you are offering them cost
control, but that a fixed bid right now isn't in anyone's best interest.
If the client pulls back hard, you've got a client management
situation on your hands. You're best off just doubling or tripling
your gut instinct, write up an "assumptions" document, and hoping the
law of averages works to your favor this time.
Mark> I have also read about the 'XP' model, but I find it does[n't]
Mark> map well onto smaller "one off" projects that flow through
Mark> here.
I don't advocate XP for most professional services situations. But
the teachings of XP have been hard won and most make sense in even
your situation, and are not lightly ignored if you want to have a
realistic perspective on the real-world software development process .
I had adopted the procedures described above before even the very
first XP mentions, but they can rightly be called "XP-like".
The key XP lesson for professional services situations is "release
early, release often". If you can get your client to pay you for
functionality in "phases" or "releases" (where the func spec and tech
spec are distinct releases), you are well on your way to breaking the
tyranny of the up-front estimate. My pitch to clients is all about
their benefits: lower cost, better risk management, higher confidence
by knowing there's actual code being worked on, provable deliverables
("full test suite from release #1"), and various other slants
depending on how they've been hurt by development costs before.
Another sort of XP-ish approach is the completely transparent
estimate. Write down every task you intend to do (possibly by
fleshing out the test plan first), put a number by each one, and add
it all up in a single spreadsheet document to get to a bottom line.
If a client balks over the price, you say, "is there a particular task
you think is overbid?" Make them point to the line they think is
wrong, and if they can't, they will realize they need to actually dump
tasks to make the cost go down.
Mark> I also wouldn't mind hearing stories about "software estimates
Mark> in the real world", the good the bad and ugly.
The above recommended patterns come after about 300-400 software
project estimations. I worked for many dotcom-years at a professional
services firm where the expectation was always fixed-bid estimates,
both from internal account management teams and clients. But people's
expectations can be changed. Clients individually and on the whole
get smarter over time regarding how to manage this whole "software
thing". You can't just out-right refuse to give something that looks
like a firm estimate, but you can change how people think about
estimates and expectations of what business/project approach will lead
to the lowest costs.
-- [EMAIL PROTECTED]
"Truth is a great flirt." -- Franz Liszt
