How Software Projects Are Estimated (Part 1)

When you employ a software development company to implement your custom project, the first things you want to know is whether the project is implementable, how long it will take, and how much it will cost. The latter two points are closely tied to each other. You have to plan your project budget, so you ask for an estimation to reveal everything, but here's the problem: this estimation isn't precise. You are told that the project may take more time and efforts from both you and your developers - more than it can be actually estimated. You may cite the waterfall development model and fixed cost as a good way to give definite estimations and minimize your own risks. The waterfall model can help you create perfect specifications, but in the end you are most likely to receive an irrelevant product. How can that happen, you'd ask? Why can't a software project have precise terms and costs?

These are the problems faced by every client who naturally wants to know what he/she's paying for, and who doesn't want to take unnecessary risks. What seems to be the problem? There's a task to do, just tell the client how long it will take. A simple project is easier to measure. For example, a branded website, designed as a showcase. The process is quite straight, it can be done using WordPress, within a fixed cost agreement. Projects, which take about a month, can be forged one by one. The estimation is usually doubled and presented to the client - it isn't much time anyway, and the risks are set within these terms. And if the client suddenly wants changes - the deadlines won't be violated.

Why Waterfall Model Is Not The Solution
But the larger the project is, the more complications can emerge. If it's expected to take months of work, if it has several constituents (the server part and the mobile part), it's nearly impossible to give a precise estimation from the very beginning. Even if the company doubles the estimation, the project still can take much longer. Does it mean that you have addressed a bad company? The answer is no.

The waterfall model is a seemingly perfect solution. Development stages go one by one: requirements, design, development, deployment, and maintenance. Each next stage begins only when the previous one is finished. Nothing starts unless requirements are fully specified and approved. But if we take a closer look, we'll see that this model is actually not omni-viable.

The client and the company can communicate until every single detail is revealed, until everything is in its place and each requirement is crystal clear. Everything is explained to developers, and there are no ambiguities, everyone knows what to do. Each feature and technical risks are estimated, there's an opportunity to create specifications, which are nearly perfect, and the estimation is far more precise. It's a paid stage of the project, which results in full, detailed specifications. But here the client will face two major problems.
One - this stage does take time.
Two - in case the client comes up with changes in the project, the stage can start over, because it requires new complete specifications. And then it goes in circles.

How To Treat The Ever Present Changes
What's more, everything is constantly changing in both business and technology. Even if during the requirements stage nothing changes, come the stages of design and development, which have to be finished. Everything may go clockwork and in time, but no changes are applied for the sake of the fixed cost and deadlines. Finding a point to introduce changes is problematic. The resulting software is outdated. For middle and large projects such irrelevance is a huge problem. That's why many companies offer agile, iterative approach in creating mobile software. It's a solution to the ever changing environments of business and technology - it helps these two branches closer cooperate and get each other's feedback.

Iterative approach solves an ever acute problem: the problem of insufficient requirements. The thing is, the client may not know exactly what he/she wants - that's a commonplace situation. In turn, it's harder for developers to understand what the client wants. If the project is huge, communication doesn't go quickly - one discussion isn't enough. But again, the client asks for an estimation, and is provided with an approximate one - whether the project will take weeks, months, or years of work.

It's up to you to choose the way your own software project will walk. At the initial stages, you might not fully understand what you want and what your end users need. You are most likely to change requirements, up to colors of buttons - it's a normal situation. Iterative development maintains the relevance of your project. But it's a fact that the initial estimation and the final cost may differ not by percentage; the real time spent on the project may be not even twice as much. That's why it's vital to have reserve budget.

Such is the answer to one of the most frequent questions that clients ask. Custom software development is no factory work, it's a unique product created for the peculiar client only. The specificity differs for every client. There is nothing that can perfectly measure the future software product and give a clear estimation. Meanwhile, the very first task of a development company is to make things less vague for the client and the company's team. That's why projects usually start with design. Design gives the first measuring instruments: number of screens, buttons, users. All of these can't give a perfectly exact estimation, but at least it's much more exact than before.

See also:
★How Software Projects Are Estimated (Part 2)
★Cheaper Mobile Development: Should You Go For Junk Food Apps?
★Why Is Fixed Cost Bad For Software Owners?