How to Get the Maximum Benefit from a Software Development Estimate
Everyone wants predictability: we know in advance the cost of goods in stores and agree on the price of a car wash or maintenance work. So, in development, we expect predictability and stability too. The question is, is this possible?
Suppose you have a set of requirements: everything is described on drafts and maps, the functionality is explained in detail and you know exactly what should work and how. Now your task is to find a company that will develop what you want according to your detailed list of demands. Here is where you need a preliminary assessment - this helps you understand whether it’s possible to meet the budget expectations and deadlines, if any, and offers a first impression of the executing company.
We’ll take as an example the estimation process, part of Magora’s standard working model, to explain you what should be done and what results you must demand from the professional developer.
How Do We Estimate?
At Magora, an estimate is not just an approximate figure but a fully-fledged process.
Analysis
We assign a specialist with experience in developing projects of varying complexity: from small apps to enterprise automatisation software and internal systems. He or she studies all the information the client has: detailed technical specifications, descriptions, prototypes, usage scenarios etc.
Refinement
The less detailed the description, the more likely that the client and the specialist understand it in different ways. To avoid this, we communicate in person and discuss the details: both technical and business.
- Business issues concern the target audience and their tasks and needs. Here we determine the key features and the desired timeframe.
- Technical issues determine the number of users, the amount of data, platforms (native or cross-platform development), devices (smartphones, tablets, smart gadgets), integration with third-party systems and employee training. Immediately specify the preferences for design.
A Direct Estimate
After studying the materials, we divide the functionality into parts and evaluate it. If the application is large and there are a lot of features and big plans for development, we recommend starting with an MVP (Minimum Viable Product). We define the functions needed so as to estimate more accurately. This approach helps save time and money: in the first version we release the main features and look at user feedback, then release new versions of the product.
Once the tasks for the basic version have been defined, we involve a narrow specialist. For example, if you need a mobile bank, we connect you with a person who often develops banking apps. Their functionality is partly similar: a personal account, information on cards, transfers, ATMs. If the expert has already developed several similar apps, he or she knows how long it should take for each function.
For ourselves, we form a list of typical functions and hours allocated for their development. Thus we speed up the assessment and exclude subjectivity when evaluating typical tasks - it takes experience of real cases.
We consider integration separately. The same mobile bank works in conjunction with an online bank, CRM system and online chat platform. Here, the mobile expert consults with the backend developer, for example, to determine integration methods.
We form the team, and plan the timing, and start working.
Oops, Something Went Wrong...
According to research by the Standish Group agency, only 3% of large projects and about half of small ones go as planned.
Does this mean developers don’t know how to evaluate?
Not really. Often the developer makes an assessment in the belief that everything will go perfectly. In practice, it turns out that the server has dropped, the documentation has become irrelevant, or the person responsible for the project has fallen ill or resigned and a new specialist has to quickly join the project. This increases the initial estimates, since at the time of their preparation the data was different. As the price rises, the satisfaction of what has been done decreases.
In addition, everyone wants to add further features to the agreed cost, although these were not initially evaluated at all - so the cost of developing an application is also growing.
Why Evaluate at All?
Notwithstanding what’s been said, evaluation is an important stage before starting work.
What can be learned from it:
- Approximate terms and cost of the particular functionality you evaluated;
- Adequacy of the company: whether processes and communication are established and how much preparation will be needed;
- Professionalism of technical specialists: what questions are asked, is there any relevant experience, are they interested in the project;
- Response rate: if they’re already answering with delays within a week, what will happen next?
How to Get the Most from an Estimate
- Ask that the hourly rate of specialists be specified: one figure in the commercial offer is not enough. If the company has higher hourly rates, but the total amount is lower, perhaps some part of work is not accounted for;
- Ask that the evaluated functional be taken note of: so it becomes clear what exactly has been studied and evaluated and that no important function has been forgotten;
- Look at the development team: are there testers, analysts, managers? Writing code is not enough, it's important to put together all the parts to get a working product.
What if There’s Only a General Idea of the Future Product?
In this case, evaluation is also necessary. It will help the developer to plunge into the essence of the project and highlight the moments that need to be improved even at the planning stage.
Here we’re planning screens, defining the functionality for an MVP and the following versions, considering the possible design.
In any case, evaluation is a necessary stage in the planning and development of a software product, regardless of whether there are clearly formulated requirements or not. So, the more precise your requirements, the more clear and complete the budget estimation.
As Lewis Carroll told us in “Alice in Wonderland”, “If you don't know where you’re going any road can take you there”.
It is clear that in this case the estimate will be approximate, as the design may change and the functionality will be expanded or removed, but at the very least you, as a customer, will have an idea of the average functionality and of the development time and budget. The more detailed your requirements, the closer to reality the software development cost estimation.
Senior Project Manager
related
recent
recommended
