Your estimates are wrong. But so are mine.

Your estimates are wrong. But so are mine.

It's common knowledge that software development estimates are always wrong, but with some careful planning and background research into your organization's previous project expenditures, they can at least be less wrong.  Including the "soft stuff" in the estimate is critical, especially when you're working with non-technical clients, clients with limited project management experience, clients who have teams making every decision... or any combination of the above.

As a project manager in an agile development environment, I generally take the research/development time and add 20% for meetings and project management.  In the past year, this has worked out extremely well -- some projects are slightly over, some slightly under -- both for us and our clients.

I started wondering if this was anywhere close to "good," and although I recall old-school IT projects falling anywhere between 10% and 30% for "overhead,"[1] I was curious what standard the agile community sets.  After some casual Googling I found a nice answer and explanation here, from StackExchange.

[1] I have to say that I really dislike the word "overhead" because of the notion that the client is paying for work that doesn't "actually go into the product."  (In particular, keep in mind that I include meetings with the client in my PM estimate.)  Agile development promotes full engagement, and this is especially important in a small team where everyone wears multiple hats: I routinely do project planning, estimating, CRM, hands-on day-to-day PM, and long-term strategic planning... in addition to technical work.

Related: "Why we should stop estimating" by Leo S. on LinkedIn

How not to manage an introvert

How not to manage an introvert

Analysis of a disruptive technology

Analysis of a disruptive technology