A Ballpark Estimate is Like Predicting the Weather

If we could only be like the weatherman. Making predictions about the future, talking about the chance of something happening, and never being held accountable for being inaccurate. Ruin someone’s outing because you failed to predict rain? No big deal, the weather gets blamed, not the person who told you what it was going to do. We cut the weatherman slack because he can’t nail down all the factors involved. If he could, we’d have a legitimate reason not to like him when our supposed-to-be blue skies are gray. Too bad a programmer’s ballpark estimate doesn’t get the same leniency. An application build is just not one of those things that is easy to predict.

With programming, an accurate estimate is created from a list of what the software is supposed to do. Usually, even the most custom application is still going to be composed mostly of things that an experienced programmer has done before. If a programmer has 10 specifications, they will break each item down by the time it takes to do them and add them all up to reveal the cost. Then there are the “X” factors, or the things we are asked to do that either have never been done before, or are so unusual that it’s going to take a little extra effort to figure them out. The best course of action is to relate the task to a similar activity and go from there.

Accurate estimates are made from realistic expectations. Not surprisingly, the ballpark figure is the mother of all false expectations. A ballpark figure is a generalized price range that you give to clients to help them understand if a project is within their budget. True, you can’t sell something without a price. But a ballpark figure is always a bad idea because you are taking something that is mostly not subjective and making it entirely subjective. Now everyone is guessing what they can and can’t get for a price. When things go bad and profit margins erode, you can usually trace it back to false expectations set by a ballpark figure. So how do you fix it?

The first step is using an interaction designer. This is integral to the process of an accurate estimate. The interaction designer communicates with account, creative and the programmers to understand what the software is supposed to do. Next, the interaction designer will document a flow of how the application should work by producing a series of pictures. That way, no one will be left interpreting a Word document, which most people don’t read anyway.

Now you have a visual document that sets expectations for the designers, programmers, account, project management and the client. These are your documented specifications. Now the programmer has as much information as everyone else and can better gauge how long it will take to produce.

At this point, you can circle back to the client and say, “This is what you asked for and this is what it costs. Anything else is extra.” You can start small and build up from there, but the important thing is that you only ever estimate on known specifications.

When you generalize, programmers have to guess at specifications and sometimes don’t factor them all in because, quite simply, they aren’t mind readers. Under the most ideal circumstances, it can be tricky to nail down exactly how long something takes to produce. If you don’t provide all the details, however, your programmers should be held no more accountable for inaccurate predictions than your local weatherman.