<story><title>Why are software development estimates regularly off by a factor of 2-3?</title><url>http://michaelrwolfe.com/2013/10/19/50/</url></story><parent_chain><item><author>kronholm</author><text>Been going at it for a couple years now with consulting and freelancing. I&amp;#x27;ve finally gotten good at hitting my estimates. What worked for me was to keep strict time of everything (shoutout to toggl.com, love it!), so I could learn from my mistakes.&lt;p&gt;The trouble is now though, my competition seems to be underbidding me, but in reality they&amp;#x27;re providing those ~33% estimates they will never realistically keep, while I&amp;#x27;m at ~100% estimates. Not really sure how to relay that to clients. One of the many reasons people like me need a salesperson in front, I guess.</text></item><item><author>_wwz4</author><text>So the article tries to describe the hidden complexity of software with a hiking analogy but then it leaves a huge part missing.  Let&amp;#x27;s extend the analogy somewhat... this isn&amp;#x27;t your first hiking trip.  In fact, you&amp;#x27;ve been on dozens and dozens of hiking trips.  You&amp;#x27;re an experienced hiker.  Yet, why do you continue to give meaningless as-the-crow-flies estimates of how long it will take you to get to your destination?  The reason is that if you miss your estimate, it probably won&amp;#x27;t matter.  Your sherpas will be there at every stop with your food, water, and tent.  You have nowhere to be any time soon, so estimating your time just isn&amp;#x27;t important enough to worry about.&lt;p&gt;Developer estimates are regularly off because they seldom impact the developer directly.  Experienced development managers will pad the hell out of the developers who give them the worst estimates.  Most developers will explain all the complexity of what threw their estimate off without acknowledging the huge mistake of not anticipating extra complexity in the first place.&lt;p&gt;My estimates in my early career were no better than anyone else&amp;#x27;s, ie way off -- especially for more complex projects.  I&amp;#x27;d explain what happened to my managers and soldier on.  The very next task that came up, I&amp;#x27;d give my manager some best-case estimate of how long something would take and the cycle would begin again.&lt;p&gt;That all changed once I started to do consulting for myself using &amp;quot;not-to-exceed&amp;quot; pricing.  The first multi-month project I did killed me.  My effective hourly rate went down to sub McDonalds levels and took much longer to deliver than I had expected.  After that project, I did a post-mortem on the project to figure out where I went wrong.  I came up with several spreadsheet templates and checklists to run through before giving any more estimates.&lt;p&gt;Mostly I just concerned myself with getting a hell of a lot better at estimating project duration and difficulty.  Like most things, when you really pay attention to it and practice it, you get better at it.</text></item></parent_chain><comment><author>RyanZAG</author><text>You&amp;#x27;re probably losing more business than you think - customers have no idea who is accurate or who is just faster, etc. They will generally go with the lowest quote regardless of other factors unless they&amp;#x27;ve been burned before multiple times. Most people haven&amp;#x27;t.&lt;p&gt;I don&amp;#x27;t have a solution here though other than noticing that underbidding and then getting skilled at convincing clients to do paid extensions later actually appears to make the most money at the cost of your ethics. I&amp;#x27;d avoid that approach, but it does seem to work for a lot of companies.&lt;p&gt;My personal approach is to quote for very bare projects with only the bare essentials (eg, poor UI design, minimum possible feature for the client to see what they&amp;#x27;re asking for, etc). This can usually be done a lot cheaper than most people think as 90% of the work is in the last 20% of the features. Then once the client has something, you can give them a quote to touch up the parts they need. Basically you split the project up into many small projects each with their own quote which helps you to estimate tasks as they appear and helps your client to minimize costs by leaving off features that are more expensive than they initially appear.</text></comment>
<story><title>Why are software development estimates regularly off by a factor of 2-3?</title><url>http://michaelrwolfe.com/2013/10/19/50/</url></story><parent_chain><item><author>kronholm</author><text>Been going at it for a couple years now with consulting and freelancing. I&amp;#x27;ve finally gotten good at hitting my estimates. What worked for me was to keep strict time of everything (shoutout to toggl.com, love it!), so I could learn from my mistakes.&lt;p&gt;The trouble is now though, my competition seems to be underbidding me, but in reality they&amp;#x27;re providing those ~33% estimates they will never realistically keep, while I&amp;#x27;m at ~100% estimates. Not really sure how to relay that to clients. One of the many reasons people like me need a salesperson in front, I guess.</text></item><item><author>_wwz4</author><text>So the article tries to describe the hidden complexity of software with a hiking analogy but then it leaves a huge part missing.  Let&amp;#x27;s extend the analogy somewhat... this isn&amp;#x27;t your first hiking trip.  In fact, you&amp;#x27;ve been on dozens and dozens of hiking trips.  You&amp;#x27;re an experienced hiker.  Yet, why do you continue to give meaningless as-the-crow-flies estimates of how long it will take you to get to your destination?  The reason is that if you miss your estimate, it probably won&amp;#x27;t matter.  Your sherpas will be there at every stop with your food, water, and tent.  You have nowhere to be any time soon, so estimating your time just isn&amp;#x27;t important enough to worry about.&lt;p&gt;Developer estimates are regularly off because they seldom impact the developer directly.  Experienced development managers will pad the hell out of the developers who give them the worst estimates.  Most developers will explain all the complexity of what threw their estimate off without acknowledging the huge mistake of not anticipating extra complexity in the first place.&lt;p&gt;My estimates in my early career were no better than anyone else&amp;#x27;s, ie way off -- especially for more complex projects.  I&amp;#x27;d explain what happened to my managers and soldier on.  The very next task that came up, I&amp;#x27;d give my manager some best-case estimate of how long something would take and the cycle would begin again.&lt;p&gt;That all changed once I started to do consulting for myself using &amp;quot;not-to-exceed&amp;quot; pricing.  The first multi-month project I did killed me.  My effective hourly rate went down to sub McDonalds levels and took much longer to deliver than I had expected.  After that project, I did a post-mortem on the project to figure out where I went wrong.  I came up with several spreadsheet templates and checklists to run through before giving any more estimates.&lt;p&gt;Mostly I just concerned myself with getting a hell of a lot better at estimating project duration and difficulty.  Like most things, when you really pay attention to it and practice it, you get better at it.</text></item></parent_chain><comment><author>crusso</author><text>&lt;i&gt;What worked for me was to keep strict time of everything (shoutout to toggl.com, love it!), so I could learn from my mistakes&lt;/i&gt;&lt;p&gt;Right, that was part of my method as well.  I learned to keep really good notes of each part of the project.  At the end of each project, I compared my &amp;quot;what I thought it would take&amp;quot; with &amp;quot;what it actually took&amp;quot;.  In subsequent projects, I tried to match up similar complexity items with &amp;quot;what it actually took&amp;quot; notes to remind myself of the pain.</text></comment>