It seems a lot of people have an argument against the “No Estimates” idea that goes something like this:
“Our Customers Need Estimates*”
There are many variations on this, but they typically come down to the same thing: We need customers, customers need estimates, therefore, we do estimates. The following are a few generic examples of this idea:
- No customer will agree to hire us to write custom software for them unless we give them an “estimate”.
- The reality of business is that we must give estimates to our customers so we can get work.
- We must be good at estimates because our competitors are giving estimates.
- The customer want’s to know if we can do their work at a price they can afford
- The customer needs to know if they can make a profit based on the amount their software will cost, so they need an estimate.
How Can I Get These Customers Without Estimates?
This is a very easy question to answer: You probably can’t get these customers without estimates. They want estimates – it’s part of the way they think. You probably MUST DO ESTIMATES for these customers. That is, you don’t tell these customers “We don’t do estimates” if you want to work with them.
If you have chosen to work with the sort of customer that requires an estimate (or price) then give them what they want: an estimate (or price). Your main job is to figure out a way to be able to make money taking on work for this sort of customer. I understand that. You understand that. What more do you need to know?
A few points you might want to consider:
- Are you willing to give an estimate/price for free?
- Who pays for the estimates for jobs you don’t get?
- How much extra do you need to “pad” the work for the “unknows”? Why should your customer pay for that?
- Are you going to give a range?: “It will cost you no less than this but no more than that”. Will you guarantee that?
- If it costs you more to make the software than you estimated, are you willing to take the loss? Why??? If not, how will you deal with that? Re-negotiate the contract?
- How do you know enough about the work to be able to give a resonably accurate price/estimate?
- If a competitor shows them a better way, will they ever come back to you again?
- That’s just a start – I’m sure we can come up with a lot of other things to consider.
If you choose to work following the “we must do estimates” model you are in good company (or at least in very numerous company), as there seems to be many who feel this is a reasonable way (or the only way they’ve found, perhaps?) to do business.
The Agile Way
I recently heard Jeff Sutherland do a talk where he mentioned the “80/20” rule – that “80 percent of the value is in 20 percent of the features” of a software project. He quoted someone (I don’t remember who) as having suggested “we should just fund the 20% and not do the rest”. I agree. I’ll take it a bit further: I believe that the rule is more like “95/5” – that is: 95% of the value is in about 5% of the features, and that the people paying for the project will quickly end the project once that 5% is in use. Perhaps our goal is to pay as little as we can to discover and create that 5%. So… how to do that?
Some choose the Agile way. In this model, we recognize that “requirements emerge”. If we can get good at allowing the more important and useful requirements to naturally emerge it pays off very nicely.
What does this have to do with estimates? If I have to tell you, then you probably should be reading someone else’s blog. But here it is: A customer who needs to “know how much it will cost” before they will decide to hire you to do the project might not be the sort who is willing to let requirements emerge. It’s just not their way of thinking. You might be able to “change them”, but probably not.
Not All Customers Require an Estimate (or price)
What it comes down to is this: You get to choose who you do business with. If you choose to serve customers who need an estimate/price, then do estimates/prices, and figure out how to make that work for you. If you choose to serve customers who are willing to let requirements emerge, then get good at the Agile way, and go for those customers. It’s your choice.
Some of my other posts on estimates and “no estimates”
- Estimation is Easy and Useful: Estimate a game of Chess
- Do Estimates Do What We Want Them To Do?
- No Estimate Programming Series – Intro Post
- No Estimate Approach For End-Of-Life Legacy Support
- Notes From A Conference Session On No Estimates in Software Development
- A Comment And Response from Estimate Chess Post
- Can We Code Without Estimates?
- If You Found Estimates Bring No Value – What Would You Do?
- Why do we need estimates?
* For the purpose of this article, the sort of estimates I am discussing are the estimates typically asked for on many software development projects where a project, a feature, or a function, or a bug fix (or where a list of features or functions) are described and people are asked to come up with an approximate cost in time, money, or effort to do the work that will be required to provide the feature(s)/function(s)/capability(ies)/bug fix(es) being requested.
Disclaimer: There are many situations where estimates can be meaningful and useful. This article is about situations where I don’t think they are typically meaningful or useful, and only in the realm of software development.