Why are software development task estimations regularly off by a factor of 2-3?

Why are software development task estimations regularly off by a factor of 2-3?

This is an answer to the Quora question: Why estimations are not exact?

There are several factors for this. Here some common one’s:

1) Client is non-technical and feels “everything is easy”

Developing a software is not as easy as it looks.

Even though it looks easy, it is sometimes better to omit certain tasks.

• To take an analogy:

There is a huge hill and we need to build a railway track. The developers will advice: “Better avoid the hill and build the track around the hill. This way we will save 5 months of additional work”.

Here it would be obvious that it will much more time to drill a tunnel through the hill and the client would agree to the “work around”.

• Now let’s look at software development:

The developer says: “It would be better to only have one mobile version with one screen size and one desktop version with one screen size. We should avoid having a Mobile App and also avoid a completely responsive design, because that will not look good”.

Here the client will most probably say: “Why? Other websites are also responsive and can change to all screen sizes. It’s an easy task.”

But: There might be several and good reasons why the developer has suggested this. Maybe a responsive design will not look good or professional. Especially some buttons can easily malign, etc. etc.
So now what will happen is that the developer will 1) build the page responsive and 2) will increase the hours.

• For the hour increase there will be no acceptance by the client: “Why more hours? Its easy right?”
• When the task is done, the client will look at the website with his mobile and will say: “Everything is misaligned when I check the site on mobile. Why? I paid much more and now this?”.

Had the client agreed to previous way of doing it (non-responsive, with only two versions), then the website would have been cheaper (less hours) and it would perfectly fine on almost every mobile screen and desktop browser.

The main issue here is also: It is not good to argue with anyone. Especially arguing with the client is not a good idea. So the developer/ the service provider will always say “Yes, you are right, let’s do it that way”.

And once the client is not really satisfied, then the developer should again take the blame (even though, he/ she knows that it was not his fault, but that the requirement was in such a way).

2) It is not possible to take much time to estimate exactly

In the real world, a software company will get requests for software applications on a daily or weekly basis.

If every request would be estimated exactly, then the developers would have nothing else to do, but to create exact estimations. They would not be able to work on real projects, because creating those exact estimates is very much time-consuming.

So what actually happens is: They will look at the project and “estimate” the time needed. That it is why it is called an “estimate”, because it is not exact.

Also: The client itself is not interested in waiting for one or more weeks to specify the requirement. At most a 5 page document will created and that will be the basis for the development.

3) Every requirement changes during the project

I like to quote Andrew Rose from the Quora thread/ link from the beginning of this article:

“No matter how big or small a project is there will always be something that comes up after you begin the project. More likely, lots of things will come up. It’s just the nature of the beast. As a Product Manager your job is to work with your customers to come up with what they need and are willing to pay for. You also need to come up with what you can reasonably deliver with the assistance of your developers. As you work to satisfy those goals you run into changes in scope, incorrect time estimates, and, sometimes, changes in the people that are working to complete the project.”

Many things change during the project. As Andrew mentioned, not only requirements will change. Even people might go into other projects before the current project completion.

Here an analogy:

A 100 meter sprinter trains for 10 years to run the 100 meters in under 10 seconds.

At the day of the sprint, the client says, we need also 5 hurdles along the way.

Then the sprinter will say, “but then I will not be able to run it under 10 seconds” and the client will say “for what did you train the last 10 years, kindly do it under 10 seconds”.

This same thing also in software projects. Clients and Project Managers will bring in new requirements because “Oh, I forgot this very important functionality. It needs to be in the software, otherwise it will not be useful for us”.

These requirement changes will come usually during the complete project. It’s like adding a pond, a wall, a ladder, etc., in the way of the sprinter, expecting him/ her to still do it under 10 seconds.

4) Architecture not checked properly

Especially when things are not done from scratch and third party tools (WordPress, TYPO3, Drupal, Magento, Shopware and many others) are used and those should be customized to do something particular it can come to wrong estimates.

In these third party tools we cannot just change everything we want. Simple things like the URL structure or other things need to be followed.

As in point 1) in this text, not everything is easy to implement. Once it has been found out, that the current architecture of the third party system is not supporting a specific functionality, it is always better to avoid that specific functionality and use a work around which does the same job, but using the existing architecture.

Note: This issue/ problem will also arise, if the project is done from scratch with tools like PHP, ASP.NET, Laravel, Zend, Symfony, Java, Ruby on Rails, Node.Js, etc. and some initial, wrong assumptions were made about the architecture of the system.

5) The “one sentence” or “one word” show stopper

I had already mentioned the example of the 5 page document, which will be provided by the client. Once the development is almost finished or under way, the client will say: “There is an important functionality missing. On page 3 at line 22 it is mentioned that we need – a reporting tool -”.

But building this reporting tool, which is mentioned only shortly in the document, itself will take the same amount as the whole project. And because the “reporting tool” is mentioned in the document, the client of course will insist on its implementation.

6) Winning the project

Let’s suppose you have the feeling that many companies are bidding for the same project. Now you definitely do not want to be the proposal which charges the highest amount of hours. You want to be the one which shows the lowest number of hours. If a client can choose between 100 hours and 500 hours, definitely everyone will opt for the 100 hours.

In reality, in an ideal world, everyone needs the same number of hours. So even though 100 hours was quoted, it will end up being 500 hours.

7) Unknowns/ Waiting Times

There are several unknowns in software projects:

• a) Technology change: If one of the development tools (e.g. Android) gets a major update, then more work needs to be done, to incorporate those technology changes.
• b) Experience of the team members: If a senior developer works on the project, it will take less time, if it is a junior developer, then it will take most probably more time.
• c) Feedback comes late: Clients are usually not much interested in the project, they want great results. So when the client is approached during the project, they might not be willing to give a reply within one hour. It might take several days. During that time the project will lay idle and the service provider might even charge hours during that time, if the developers are sitting idle because of the delay in responses.

8) Project is too big to be estimated correctly

Let’s suppose the task is one, which needs several developers over a period of several months.

It is almost impossible to break down the tasks in such small chunks of work, so as to get the right estimate.

The other things mentioned in this article will of course also play a role.

Conclusion

The best approach is:

• Make an approximate estimate
• Mention that it is best to reduce the functionalities, if the project takes too long and takes many hours (e.g. create a priority list of functionalities, do only the most important one’s)
• Use the agile methodology for development and billing

In case you want an exact price/ hours, then it is usually only possible in smaller projects, which will last a few weeks.

Other interesting articles regarding the topic:
How to Estimate Software Development Project In Man-Hours Realistically
Why Software Development Time Estimation Doesn’t Work and Alternative Approaches

Picture Source: Flickr.com/ Michael Kappel/ Judit Klein/ Markus Spiske

The author: Sascha Thattil works at Software-Developer-India.com which is a part of the YUHIRO Group. YUHIRO is a German-Indian enterprise which provides programmers to IT companies, agencies and IT departments.