Oleg Lola CEO of MobiDev
Atlanta, Georgia (PRWEB) October 23, 2013
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 project is unique (and they are unique in one way or another), innovative, or complex, it's impossible to present a precise estimation at the initial stages of communication between the client and the contractor.
It may seem to the client that the problems of unclear and changing requirements are just fanciful, artificial. How can it be hard for a company, that has years of experience behind its shoulders, to seize it at once? There are no constant innovations and radical changes in the mobile world, and the company claims to keep up with the pace of time and the latest tech. The client doesn't want to pay specialists to receive all the risks with these estimations. Why can't the company understand what the client wants, why can't they simply estimate the required time and cost?
To answer these questions, development can be compared with another service, for example, home improvement and repair works. What can be imagined here? The same typical professional contractors, the same typical actions of getting acquainted with what the client wants. How would the client budget both of these activities? What does it all begin with?
The first conversation between the client and the software company is something like ''I need to refresh my apartment, how much will it cost?'' Is this question enough for an answer? Probably not. The contractor needs much more information to say anything reasonable. The client starts telling about the apartment (or the software project). It can be an average apartment, or it can be something that resembles a palace. That's why here the contractor cannot name the scope of work and cost either.
The contractor needs to take a look at the apartment. The client shares more details, ''I want a wooden covering for the floor, blue wallpapers and a new ceiling lamp.'' Still the contractor can't name the price for that. That's because everything needs to be measured, the client must specify that exact hue of blue color; at last the contractor may furnish a room with either a cheap ceiling lamp, or a beautiful crystal chandelier, if that's unspecified.
There can be also mentioned a popular way of refreshing the rooms - changing wallpapers. There is often a situation when the contractor gets rid of the old ones and finds a defect in the wall - up to a large hole. Surely the client is informed of it. This defect can either be repaired to the client's cost, or left as it is, with new wallpapers placed upon it - the client has the final say. This can happen when the client brings the drafts that should be reworked to make the software better.
There is also a misconception ''There are just five screens in the app, why should it take so long to make it?'' But it's like saying ''I've got just two rooms to furnish''. The contractor may charge any cost and that won't be incorrect. Either the contractor will furnish each room with nothing more than a bed, a table and a chair - all will cost, for example, $200; or these two rooms may be furnished with exquisite items for half a million - with an antique longcase clock and elegant stucco work included. Size of these rooms may also differ. The same with apps - screens do not measure the required time - it's all about the functional filling of the client's application.
That's the way requirements are clarified, and the estimation is prepared: works, materials (cost and quality), designer's work (if needed). Meanwhile the first conversations between the client and the developers are really close to ''I have an apartment and I want blue walls.'' After that developers need to find out more about the ''apartment'' and the ''materials'' needed. And of course, there is a hard job of figuring out what the client wants, and delivering it. When there are risks (e.g. changing requirements, third-party APIs, creating web services), they are always discussed between the client and the development company. If the developers claim to take all the risks, it's either a very simple project, or it will be overpriced, or the developers simply don't know what they deal with.
It will be good to conclude with one thing that is usually absent in home improvement, but highly crucial in software development: end users. In the former case, clients are usually the end users. But in software development, although the client sets requirements, the app is built for users, and there's an additional work of understanding the users' needs and studying rival products, so that the deployed software would meet its share of demand on the mobile market.