Abbett.org

February 8, 2010

How to promise, when you can only guess?

“When is it going to be done?” is a reasonable question and we as software developers should try to come up with the best answer we can based on our experience and analysis. What we should not do, however, is treat our answer as solemn oath.

It's hard not to nod your head while reading David Heinemeier's latest post on the 37signals blog, especially if you're a software developer.

Having tested the waters of consulting as of late, I also couldn't help shaking my head. One the one hand, software is full of unknown-unknowns -- even with mature UX design materials, there are minute implementation details that are hard, if not impossible, to discover until you start working. On the other, this post leaves unanswered a huge question.

How do you quote a project to your customer?

I can't imagine that every Agile shop insists on time-and-materials, with no deadlines, and no functionality commitments.

Honestly, this isn't a rant -- I desperately want to know how to solve this problem. Readers, please share your experiences.

1 comments

February 11, 2010
11:38 am

There are a lot of uncertainties at the beginning of the project. While it is [relatively] easy to estimate known-knowns, it is hard to estimate known-unknowns and very hard to estimate unknown-unknowns. I think doing a good faith estimate of known-knows and known-unknowns is a good start. What about unknown-unknowns? Take the estimate that you have for the knowns and multiply that by two. Multiplying it by two assumes that unknowns cannot be more than knowns, and if they are we failed ourselves as professionals and should pay the cost. In my opinion start with the magic multiplier of "two" and refine it (reduce it, most likely) based your past projects.

Vineet Manohar

Add a comment

Please add a comment using your Twitter account. Don't have one? Sign up.