When it comes to estimating software design and development, anyone who has certainty down to dollars and cents is like the two swindlers in the folk tale The Emperor’s New Clothes.

The emperor in Hans Christian Andersen’s folk tale was persuaded by the swindlers that they had supplied him with magnificent clothes that were invisible to the simple-minded. It takes a child to blurt out that the emperor is wearing nothing at all.

Certainty, when it comes to estimating software design and development, is mythical.

That is probably why astrologers, psychics and soothsayers have always been popular. You go to somebody and they tell you what is going to happen to you, and you say: "Great, awesome."

We try to get that certainty, but absolute certainty is a myth. It doesn't mean that we don't strive to estimate better, but we have to remember that an estimate is exactly that.

Some of the first questions I received, when I started out as a project manager many years ago, were, “How much is this project going to cost?” and “How long is it going to take?” I said, “Without doing some analysis on it, I don’t know,” I was asked to guess, so I did. Three months later I was reminded of the figure, and I reiterated that it was just a guess.

If you've got a static piece of work to do, you can start with a requirements document. There's this idea that if everything is written down the project will have certainty. Software projects are seldom static, so by the time the requirements document is finished the requirements have usually changed.

Michael Hamid, left, with Bryan Miles, centre, and Stephen Warren.
ESTIMATING SOFTWARE DEVELOPMENT: Company-X professional services manager Michael Hamid, left, reviews an estimate with business analyst Bryan Miles, centre, and project manager Stephen Warren.

Estimating software development

At the beginning of the estimation process, we try to get a very high-level ballpark idea about the cost of the overall work in orders of magnitude. Is the work less than $10,000? Is it between $10,000 and $100,000 or is it over $100,000 up to $1,000,000.

We might say to our prospective client, “This is feeling like it's going to be six figures worth of work.” They might ask, “Is it $100,000 or $900,000?” We might say, “Somewhere in there. We’re certainly sure it's over $100,000.” As we get a better handle on it, we might say, “We think it's around $150,000 to $170,000.”

Many factors influence estimation including the estimated duration of the project, the culture of the organisation doing the estimating, and the seniority and experience of both the software development team and the client’s team.

If the organisation has never run a project of this type before it raises a red flag. If the culture of the organisation is open and accepting of failure there is less incentive to hide problems and that definitely helps the success of a project. If the project team has a lot of junior or inexperienced developers that can make a project take longer.

At Company-X we often try to compare the projects that we are estimating with something similar we have done earlier. We estimate the things we know about. If there are things, we are not sure about, we try to work out what we need to do in order to get more certainty. It could be to carry out some research, or set a defined time period in order to further explore the risk area. A big mistake less savvy software developers make is to assume everything will work out fine without this extra work. It seldom does.

We keep our forecast window short at Company-X in terms of certainty. Generally, we can be reasonably certain up to a few months into the future. Beyond that, it’s often a ballpark guesstimate.

We break the work into small chunks until we can get to a size that we are comfortable with. We check the estimate with other experienced people outside of our assigned software development team to see what they think and whether we have considered everything. We try to uncover as many risks as we can and then figure out how to mitigate those risks.

The late US secretary of defence Donald Rumsfeld talked about the known knowns, the known unknowns and the unknown unknowns. And he was absolutely right. There are things we know we know. There are things we know we don't know. There are things we don't know we don't know.

We identify the things we know and feel comfortable about. These are things that are not risky and we've got a fair idea about how long they're going to take.

We try to identify the things we know we don't know. For example, there's a risk that a third party’s application programming interface (API) may not work as specified, or there's a risk that a library component may not do the job we think it will. Then we decide what we are going to do about the risks, if possible, we try to schedule the mitigation work straight away. Is there an alternate plan? If we didn't get the data, what do we do?

While everyone likes to have certainty in their lives, we all have to accept a level of uncertainty. That is why certainty is a myth. One of our jobs in Company-X is to ensure the client is well aware of the things we know as well as the things we don’t know.

If we can plot a path for our development work and keep the customer in the conversation as we develop, evolve and understand more about the work, we increase our chance of developing software that meets the needs of the client.

Michael Hamid is Professional Services Manager at Waikato software specialist Company-X.