It seems a lot of people have an argument against the “No Estimates” idea that goes something like this:<\/p>\n
There are many variations on this,\u00a0but 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:<\/p>\n
This is a very easy question to answer: You probably can’t get these customers without estimates.\u00a0 They want estimates – it’s part of the way they think.\u00a0You probably MUST DO ESTIMATES for these customers.\u00a0 That is, you don’t tell these customers “We don’t do estimates” if you want to work with them.<\/p>\n
If you have chosen to work with the sort of customer that requires an estimate (or price)\u00a0then give them what they want: an estimate (or price).\u00a0 Your main job is to figure out a way to be able to make money taking on work for this sort of customer.\u00a0 I understand that. You understand that. What more do you need to know?<\/p>\n
If you choose to work following the “we must do estimates”\u00a0model you are in good company (or\u00a0at least in very numerous company), as there\u00a0seems to be many who feel this is a reasonable way (or the only way they’ve found, perhaps?) to do business.<\/p>\n
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\u00a0project.\u00a0 He quoted someone (I don’t remember who) as having suggested “we should just fund the 20% and not do the rest”.\u00a0 I agree.\u00a0 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.\u00a0Perhaps our goal is to pay as little as we can to\u00a0discover and create\u00a0that 5%.\u00a0 So… how to do that?<\/p>\n
Some choose the Agile way.\u00a0 In this model, we recognize that “requirements emerge”.\u00a0 If we can get good at allowing the more important and useful requirements to naturally emerge it pays off very nicely.<\/p>\n
What does this have to do with estimates?\u00a0 If I have to tell you, then you probably should be reading someone else’s blog.\u00a0 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\u00a0might not be the sort who\u00a0is willing to let requirements emerge.\u00a0\u00a0 It’s just not their way of thinking.\u00a0 You might be able to “change them”, but probably not.<\/p>\n
What it comes down to is this: You get to choose who you do business with.\u00a0 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.\u00a0 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.\u00a0 It’s your choice.<\/p>\n
NOTES:<\/p>\n
* 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.<\/p>\n
Disclaimer: There are many situations where estimates can be meaningful and useful. \u00a0This article is about situations where I don’t think they are typically meaningful or useful, and only in the realm of software development.<\/p>\n","protected":false},"excerpt":{"rendered":"
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,\u00a0but 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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[21,22,24],"tags":[],"class_list":["post-723","post","type-post","status-publish","format-standard","hentry","category-estimating","category-no-estimating","category-noestimates"],"_links":{"self":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts\/723","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/comments?post=723"}],"version-history":[{"count":32,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts\/723\/revisions"}],"predecessor-version":[{"id":1034,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts\/723\/revisions\/1034"}],"wp:attachment":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/media?parent=723"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/categories?post=723"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/tags?post=723"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}