Managed Mayhem

I frequently run into the request for a ‘ball-park’ estimate for software development projects. I loathe to give these type of estimates. They are inherently dishonest from the very start because they are a ‘promise’ based on incomplete and sometimes incorrect information.

I love to give a free one hour consultation for my clients. It gives us a chance to get to know each other, introduces me to their product or idea … and begins the process of figuring out ways that I am able to help them. I can usually tell rather quickly within this one hour period if I’m going to be an asset to their team or not. In most cases, clients have a very basic idea of what they are really wanting to accomplish. A loose set of ideas, sometimes scribbled on a notepad or napkin while you watch. Other times, clients will actually have some prior education and will have something a little more organized… perhaps some storyboards or a diagram showing what they want to do. This is better, but honestly… still not enough to give a proper estimate.

The problem that I have with ball-park estimates is that they are too subjective and emotional. I might be hungry that day, or I might not be hungry at all. I might be really excited about working with this particular project or client, or perhaps I’m not really interested in what they are doing but still want to help. Maybe I just want the client to like me. Maybe I’m without work at the moment, or I might be swamped. None of these things should really matter when building project estimates because they are subjective, emotional, and variable. We have all been in that position where we were without work, underbid a project (usually as a ball-park estimate) and then half-way through the gig we’re late, overbudget, swamped with new work feeling taken advantage of, and no longer really motivated to do a good job. Why do we do this?

When I have given them, my ball-park estimates for custom software development swing manic depressively between polly-anna optimism and grinch like pessimism. This is never good because either way, someone is going to be unhappy with the end result. If I am pessimistic and shoot high, clients get skittish or I automatically lose to moderates and optimists without the opportunity to close. If I am optimistic and shoot low, inevitably the client is disappointed anyhow because:

• Time lines are missed
• Market opportunities are missed
• Budgets are missed
• Rush to release results in mistakes

Some clients have been thinking about and developing their product / idea for years… it’s only reasonable to expect that we are given the time needed to study their product / idea thouroughly in order to do our jobs properly. There are a lot of software development firms out there who  with respect to setting budgets…they hedge on margin / volume, or occasionally getting lucky. They figure ’some we win, some we lose’.

I don’t like to lose… I like both the client and me to win every time.

The analysis portion of our jobs as software developers is primarily about reducing risk. I see gambling with incomplete / inaccurate project estimates as a risk that is deadly to projects, and one of the primary reasons why they fail. Get as much information about the project up-front. Spend the time that it takes to get as accurate an estimate as possible. Don’t worry about being perfect, but at least make the attempt.

I promise to write an article about how I estimate software projects soon. For now, feel free to comment about some of the project estimation tools you’ve used that have worked for you!