Why You Need Software Project Estimation: The Expected Result

by Darya Kazovskaya

8 Feb 2017

Before starting the development process, it’s critical to figure out how the final software product is going to look like in the view of business owners and the development team. To understand how close the vision of the business is to the vision of the developers, we need to define a route from start to finish. The best way to construct this route is through the process of software project estimation.

If aren’t familiar with software project estimation, this is a process that demonstrates what time is needed for a development team to implement every task for creating modules and components of a future software solution. In fact, it helps to draw the map of the route that is going to lead us to the expected result. Every route section on the map represents implementing specific project tasks.

The deeper a project team dives into the task, the easier it is to get a more precise project estimate and come to an agreement with the client.

In our experience, there are three options to get an estimation of effort in software projects. In fact, the scope of work doesn’t change, but every option has a different degree of approaching the vision:

Express estimate – In modules and components: 1-2 days

Every client of ours is provided with an approximation of cost based on previous projects and case studies. Here both sides have to compromise: a quick estimation means an uncertain result whereas a precise estimation needs more input data and time. Express estimate has the risk of not delivering a project on time and within the approved budget.

The deeper a project team dives into the task, the easier it is to get a precise estimate.

As with any other process finished at short notice, express estimate doesn’t allow us to look deeply into the details and find potential pitfalls in time. For example, if we decide to use a readymade component in the project. However, nobody measured its productivity. Let’s suppose that the component isn’t effective for some of the tasks. As a result, the project team has to write this part on its own. It leads to a bloated budget and the completion schedule shifts forward.

Middle estimate – In large-scale tasks, in details: 3-4 days

Additional questions to clients and their detailed answers help to reach a common understanding of every task. For instance, a client asks to develop an authorization form for a website implying only the standard fields of login and password. At the same time, a developer includes in this task the creation of the form, ways of personal data input, features for password recovery, and confirmation using messages. It would seem that the task is the same, but regarding the vision of project participants, it means different functionality. Hence, additional questions and detailed work over the job helps to approach the same vision.

In practice, a client knows about the task more than the project team. For example, there is a task to develop a standard E-commerce online shop. It’s very important to clear up what a standard online shop means, which features it will have etc. All these issues can be solved with understanding the requirements.

It’s widely believed that software project estimates are wrong most of the time. And so it follows that projects become longer and more expensive than initially planned. This situation happens because a client often asks a project team to hurry and hope to get the final calculations here and now without understanding the requirements. The desire of business owners to speed up the process is quite understandable – they need to launch their software product earlier than their competitors. However, if you run to the finish without looking at the road, you could miss it all together.

Software project estimation is an essential stage of the development process. It requires a delicate approach both from the project team and the client. This is the only way that guarantees a highly precise estimation and a thoroughly satisfactory result.