Everyone wants to know a software project budget and schedule. How come software estimation is still hard today, despite a lot of accumulated experience in the field? Well, it turns out that while there are quite a few techniques to make a schedule more reliable, the principles at the core of the estimation process are still the same, and so are the difficulties. Accurate estimation, especially in today’s dynamic outsourcing world, is really not an easy task.
Methods of estimation
Building a reasonable schedule or estimate is based on two complementary methods: analysis and analogy. Using analysis we divide a project into a number of more comprehensible subtasks which can be estimated easily, and then aggregate these estimates into the final one. For example, if we want to implement a microblogging service, we need to break down the functionality into the smallest possible blocks: user registration, login, sending posts, looking at the blog roll etc., and then weight up how long it would take to implement each one.
Analogy is completely different style of thinking. Here we base the estimation on our previous experience: if we have done a similar project in the past and it amounted to x man-hours, then this project will take about the same resources. This is more informal method, but it’s suitable for quick and dirty estimation.
Okay, so what’s wrong with those methods anyway?
The problem with analysis is that it requires a very detailed realization of what exactly should be done. Planning in general words is fooling yourself – I’ve seen a lot of seemingly tiny details that completely changed my view on how to implement the project. Even if from a layman’s point of view tasks such as verifying that a program cannot fall into infinite loop, checking with 100% confidence whether user opened email or merely programmatically changing image on iPhone lock screen seem perfectly natural, in fact they are impossible due to fundamental, technological or political reasons. So to build a reliable estimate ideally one need to think over every little detail in the project. No wonder it can take a lot of time, but the real problem is sometimes we simply do not have enough information to make such an elaborate estimate.
If piece by piece estimation is hard, then can’t we take a similar project figures as a reference? Well, every project is special. Even projects with the same domain can be very different inside (think twitter or plurk) – in fact, most of the time is often being spent not on the basic features, but on project-specific bells and whistles. That difference becomes drastic when comparing, for example, big social network with small online shop (though both are websites). Then, everyone’s experience is limited, especially having in mind rapid software industry progress. So you want to develop a large project with this hot year-old technology? Then it’s natural that we do not have very much experience with it, and hence you should not expect a very accurate estimate.
So what to do if you don’t want to spend half a year on planning and a lot of money on a business analyst salary, but still want some time & budget estimate?
Some tips to make the whole thing right
Advice #1: Prepare a specification. You won’t believe how many clients are asking for an estimate after shedding three of four sentences about the project to be developed. Yes, nobody likes writing specs, but it would help a great deal during the development. By the way, you don’t need to be too picky, just describe what the app should do in a more detailed way.
Advice #2: Don’t try to eat an elephant at once – long-term scheduling is always risky, make a prototype. We can settle on a 2-4 weeks prototype, after which you can see how the team works and the team can base their estimates on something real. It’s better to spend two weeks at the beginning than learn after year that it would take two more years to finish the project (by the way, Agile software development does not exist for nothing).
And remember: even the best estimate isn’t perfect! Always take it with a grain of salt.
P.S. Joel Spolky’s article on the estimation is quite good. I recommend reading it despite its “obsolete” marker – he’s using a new technique now, but the basic ideas are still very applicable.
Oleg V, Project Manager,
Team Lead of .NET Department,