Project Estimation for Beginners

Opinions are like assholes. Everybody's has one and everyone thinks everyone else's stinks

Оценка проектов для начинающих

At some point in life, we all have had to make an estimate of time. How much does it take you to get from home to work? Or how much time will you need to do your housework at the weekend? When do you have to arrive at the airport so as not to miss a flight? I guess you know what I mean. Most people have no particular difficulties in coming up with exact numbers. Some estimates turn out to be precise, some of them appear to be inaccurate. We are used to constant time estimation, and we do this subconsciously. In web-projects, as well as in any other ones, a time estimate, which is a base for a cost estimate, is made the same way as we usually do this in everyday life. The difference lies in the cost of error.

There is plenty of specialized literature on different estimation techniques, in this article I won't go deep into methodology but I'll only describe some of the most popular and widespread ones.

Individual's Estimate

Without any doubts, I claim that this is the most common method of estimation which is particularly misused by young and inexperienced teams. Having received a new task, a project manager, or any other team member who's in charge, carries out an analysis and gives the final number. Anything can be meant by analysis, ranging from flipping a coin to complex calculations. The final estimate based on an individual's subjective opinion is a unique feature of the method. In a majority of small and standard web-projects, a good manager's experience is enough to make a more or less accurate estimate. However, when we deal with the unique functionality, we shouldn't limit ourselves to an individual's decisions.

Analogous Estimation

This is another popular method with young teams. It implies the comparison of a new project or some of its parts with previous projects of the team or the company. The method retains its popularity because the majority of small and medium web-projets are quite similar. Online stores usually have the analogous functionality, so it is enough to draw an analogy to the completed project and get an accurate estimate. If a new project does have some differences, it is possible to employ a decomposition method by dividing the task into smaller parts and estimating them separately, then put the results together into a final estimate.

Parametric model estimating

This method is quite similar to the previous one, but it implies estimation based on a certain parameter, for instance, code lines, design pages, dialog windows, database tables etc. If we know from the previous projects that the design process of a page takes three days, and a new project requires to design twenty pages, we can conclude that the whole design process will take sixty days.

Three point estimation (PERT)

It's a useful method for a subjective estimate elimination. It is based on making three separate estimates: the most pessimistic (P), the most optimistic (O) and the most likely (M). The estimate is calculated using a formula and results in the expected time needed for the project: (P+4M+O)/6. For example, a developer says that he needs some amount of time to complete a certain task.  In the most optimistic case (if no one distracts him), it'll be 10 hours. In the most pessimistic case (if everything goes wrong), he will need 25 days but taking into account the fact that there are no possible distractions at work, and probably he won't fall behind the schedule. It is most likely that he will complete the task within 15 days. Having made simple calculations, we get almost 16 days.

Experience, I guess not only mine, has shown that to get the most accurate estimate (by accuracy I mean the correlation between the obtained estimate and the real result) you should apply several methods and compare the outcomes. If possible, it's better to use task decomposition and make a separate estimate for each subtask. And of course, if the project is complex and large-scale, it is always needed to indicate that the estimate ranges from A to B.

P.S.If you're interested in the methods of time and project value estimation, I recommend reading Software Estimation: Demystifying the Black Art by Steven C. McConnell. 

Let’s fill the brief, shall we?