timgarrett.net

When asked to estimate software development, either unilaterally or as part of a team, there are a number of pitfalls you might encounter. You might be building software for a domain you are not entirely familiar with or adopting new technologies with largely unknown risks. Although those are valid issues that might arise, the advice I bring to this blog entry is much simpler. There are no formulas, charts, or dependencies.

To be honest, I have “learned” this lesson before, so I can’t really say this knowledge takes me by surprise. However, the sooner everyone in software development takes it past the recognition stage and adopts it as an inherent philosophy, the better…

When being asked to estimate software development, never rely on imaginary people.

If you have anything less than 100% confidence that a resource will be available to you when needed, assign that resource to “nice-to-have” or contingency features. Delivery dates should never be cited based on possible hires. What all too often happens is the folks with the purse strings remember your commitment to a specific date but forget their obligation to assist with resources. This situation can cause a lot of bitterness and resentment throughout the organization. Worse yet, it all too often is the sign of the beginning of the end for a project.

If you have 2 developers readily available to work on a project for which 10 would be ideal, show the delivery date based on their actual productive capability. It is fine to show delivery dates that are progressively sooner by adding additional people, but it must be made abundantly clear that the one that matters is the one in bold based on actual resource availability.

Even if your developers that are expected to remain imaginary do become available, it is important to remember another related type of developer–the mythical developer and his accompanying productivity.  The mythical man month has been discussed in great detail elsewhere, so I won’t spend too much time on it.  However, it is important to remember that even a well-resourced project can be run into the ground by mismanagement of resources.  Pay special attention to developers’ strengths and weaknesses and make sure you are using them where they can help your team and project the most.

It is sometimes hard to connect the dots between business success and resourcing of projects. The fact is many projects can be delivered much later than anyone would like or with a diminished feature set and still deliver dramatic business value. However, the correct balance between delivery dates, scope, and quality must be agreed upon by everyone involved with a project to ensure success.