Last month, a new client came to us to talk about developing
some software for him. We met a couple of times, asked a lot of
questions, drafted high-level business requirements, and did an
initial Function Point Analysis. We sized the effort at 14 months
for $220K, accurate within a range of ±20%.
We had stayed in close communication with him throughout the
discovery process, so we felt confident he would be happy. We sent
him our bid. Guess what? He was NOT happy.
"What do you mean, plus or minus 20 percent? You mean this
project could hit a quarter-million dollars?" He said he couldn't
budget against something that vague. It wasn't the time or cost
that caught him off-guard. It was the range of
uncertainty.
We were surprised that he was surprised, but in retrospect, we
shouldn't have been. His company is an industrial supplier - he
buys and sells equipment. When he buys a part, the cost is $X. No
plus/minus range. Just $X.
Yet in software development, correctly estimating the size of a
project is one of the most difficult questions to answer - maybe
the most difficult. That's because you never know exactly what
you're going to be getting into until you get into it. So software
consulting firms routinely estimate the cost of a project with a
fudge factor of ±X%. How much is the fudge factor? At one
competing firm in town (who shall remain nameless) their initial
estimate has an accuracy of -75% to +300%. Yes, you read that
right: They admit the final scope might triple in size before it's
all over and done with.
At StoneHenge Partners, our first estimate of size is accurate
±20%. After we finish business requirements and Function
Point Analysis, our accuracy improves to ±5%. That's the
best in our business. As far as I know, no one else in town offers
that level of accuracy. Our accuracy is due to a disciplined,
experienced team who use the Nimble Method, our unique blend of
practices like Function Point Analysis and Agile Development, and
it improves with every project we do.
And yet, we still have surprised clients. What to do?
On the one hand, I can understand his concern. He really can't
budget for an expense that could vary anywhere from $180K to $250K.
But on the other hand, there really is that much uncertainty in the
scope of a project. It could change - in fact, at some point during
development, it almost certainly will change.
In the end, I guess, it comes down to a matter of setting
expectations.
The analogy I've used in the past still holds true: Building
software is like building a house. Scoping size (through Function
Point Analysis) is like setting a price per square foot. It only
gives you a rough estimate -- $80/sq. ft. may be the overall price,
but the garage is going to be cheaper and the bathroom is going to
be more expensive. And we can't really tell you how much your house
is going to cost until you tell us whether you want builder's grade
carpet or Italian marble flooring.