MobiDev Webinar: How Software Projects Are Estimated (Part 1)

Share Article

MobiDev Corporation, a software development company, has recently conducted a large in-house webinar dedicated to software project estimations - a critical point in communication between a client and the company's representatives.



MobiDev Corporation, a software development company, has recently conducted a large in-house webinar dedicated to the ever present issue of software project estimations - a critical point in communication between a client and the company's representatives. This webinar actually concerned not only business development managers, but also project managers and developers, since clarifying the client's requirements and making estimations is an inherent part of the whole development mechanism.

When a software owner (the client) employs a software development company to implement a custom project, the first things he/she wants 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. The client has to plan the project budget, so he/she asks for an estimation to reveal everything, but here's the problem: this estimation isn't precise. It is often stated that the project may take more time and efforts from both the client and developers - more than it can be actually estimated. The waterfall development model and fixed cost may be cited as a good way to give definite estimations and minimize risks. This model can help create perfect specifications, but in the end the client is most likely to receive an irrelevant product. So why can't a software project have precise terms and costs?

These are the problems faced by clients who naturally want to know what they are paying for, and who don't want to take unnecessary risks. What is the actual problem? There is a task, and the client must know 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.

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 the client has 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 a closer look is taken, this model will actually be 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 be 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.

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 the client to choose the way of development. At the initial stages clients usually don't fully understand what they want and what their end users need. They are most likely to change requirements, up to colors of buttons - it's a normal situation. Iterative development maintains the relevance of their 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 for the client 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.

Share article on social media or email:

View article via:

Pdf Print

Contact Author

Oleg Lola
Follow us on
Visit website