Why is estimation of web development projects so challenging?

Why is estimation of web development projects so challenging?

One of the most debated, often confound and misconceived issues of web development is estimates. Nevertheless, this aspect is required, and we have previously written about how our team estimates our Drupal projects. However, lots of people, especially laymen, don’t realize that asking a development team to estimate a project and answer the questions ‘How long will it take?’ and ‘How much will it cost?’ equals asking them to foresee the future. We can only give a definite answer after it has happened. With small or big divergence, estimates are always wrong. When they are right, it is purely accidental. Today we are going to name challenges programmers are facing when they have to make an estimate, to clarify what makes this stage of project developing so ambiguous and hard.

Too much optimism

Most programmers tend to make overly optimistic estimates. They either overrate their productivity or underrate the complexity of the task. This is especially true for new developers who are too confident in their abilities. Making estimates as precise as possible requires much experience, practice, and knowledge of the existing system and task. Also, some companies prioritize timeliness over robustness. This strategy may not always produce satisfactory results, because as people say, haste makes waste. It’s better to under-promise and over-deliver.


When some estimates for a part of the project are not reached, other estimates should be corrected accordingly. However, programmers are usually optimistic and believe that they can do the rest of the tasks more quickly and compensate for lost time. However, the opposite is usually true.

Also, in most projects some alterations occur in the requirements, either from the customers or rational suggestions from the developers. During the time of working on web project, new ideas appear. It’s obvious, though, that any added feature influences the estimate for the whole project, which should then be re-estimated accordingly.

Membership of the team

Programmers differ in productivity a lot. The situation is better when programmers estimate their own work than when someone else does the estimation for them.

Don’t forget also that the members of the development team, like people of any other occupation or craft, may get sick or go on vacation due to unexpected personal issues in the middle of a project’s developing process. Changes in the team’s membership have an impact on the overall picture.

There is a term ‘man-month’ — one person's working time per month. It’s used to measure how much work is needed to accomplish a concrete task. It is considered that a unit of work is proportional to the number of people working multiplied by the time they work. Frederick Brook in his book ‘The Mythical Man-Month’ disproved this correlation, relying on his experience and observations about what causes most projects’ delay. Brook affirms that adding manpower to a late web project which is running behind the schedule makes it even later. This is because the time required for the new programmers to grasp the main idea and go deeply into the project increases time for communication inside the team.

Accidental complexity

In the web development process, either an essential or accidental (non-essential) complexity may occur, or both. Frederick Brook, in his other book ‘No Silver Bullet,’ distinguished between those two types and described them.

The first one is directly connected with the task itself and with customer’s desire and requirements. It’s a core of the problem that must be solved anyway, that’s why essential complexity is inherent and unavoidable. It cannot be simplified without losing value.

The second type of complexity is coincidental and unpredicted. It concerns the problems created by developers, which can be fixed. Accidental complexity relates, for example, to nuances of writing assembly code or delays caused by batch processing. This complexity can be caused by the approach chosen for problem-solving, by disorganized planning, or low priority put on a project, but there is also an accidental complexity that always arise as the side effect of solving any problem. And, of course, it requires some extra time and efforts.

Bugs and blocks

Even the best and most experienced developers can’t foresee all the obstacles and bugs that will occur. Therefore, a proper estimation should take into consideration the high probability of them happening and have some reserve for these things. Our team includes QA engineers, responsible for testing the process to make sure that all quality requirements are fulfilled.

Mechanical vs creative tasks

Mechanical and routine tasks can often be automated to some extent. They are more predictable. If programmers already had some practice with the previous similar tasks, it’s not as hard to estimate them.

Creative tasks need much thinking and inspiration. The more of them there are, the more time each one requires. It’s almost impossible to estimate these creative tasks with adequate accuracy.

Why is estimation needed, anyway?

It’s important to assess the value of every feature, no matter how small-scale it is. If all features are equally effort-consuming, you can simply create a list with no sequence and start doing them. However, features vary depending on the different amounts of efforts and the time they require. So, estimating the approximate cost of features allows you to do cost-benefit analysis and prioritize features.

As a large estimation of the entire project is more likely to be wrong and have bigger errors, it’s a good idea to break it into several smaller estimations. This also helps to structure work and to single out milestones.


As long as programmers are not fortune-tellers, their estimates are still only guesses and suppositions. So, it’s wise to accept that estimates are always wrong, don’t rely on them totally, and don’t panic if they are not reached. Meeting estimates isn’t a criterion for developers’ competent judgment. Moreover, following the initial plan may improve estimates, but also may lead to mediocre results, because it kills creativity and striving for perfection. Re-working should be encouraged to improve things, but it’s quite hard to find a balance between re-working in the context of the current project and the creation of a new one that will be implemented later. This is a chance to discover new dimensions and perspectives.

Every project is unique. No two are the same. It’s obviously impossible to estimate the unknown with 100% accuracy until it is discovered. Plus, life is always unpredictable. So, let us pleasantly surprise you with the estimation and end result of your website development process.

3 votes, Rating: 5

Read also


Time for some more useful project management information by our expert Ivanna aka Vania ;) Having learnt about retrospective and sprint estimation and seen how Agile technology is used...


We continue learning about the implementation of Agile at big companies from the series of blog posts by our project manager Ivanna, aka Vania. Let’s now give her the floor once again.


A few years ago the word “Agile” was a complete neologism in the project management terminology. Today, many companies use this methodology and consider it to be an essential part of the workflow...


Let’s give the floor again to our project manager Ivanna (aka Vania). In her previous article, she shared her ideas on retrospective. Today, she welcomes her fellow project managers to read about...


Retrospective is one of the components of the famous Agile methodology. ...

Subscribe to our blog updates