If you ever had to deal with mobile apps estimates (from the point of view of both a client and an estimator/contractor) then you would have definitely had the following conversation at least once:
Client: “I have an idea and I want an accurate estimate of my app right now.”
Contractor: “I cannot give you an exact estimate because there is not enough information/specifications/wireframes etc.”
Client: “And I can’t start and give the project to you without it.”
There are two types of companies this situation defines: “fakers” and “honest” ones.
Contractors of the first type (the majority belongs here) let their clients push them around. They assure a customer that a project will cost $N and usually send a huge (often typical) commercial offer with a quasi step-by-step plan of project implementation. In other words they say things a client wants to hear — it could be compared with flattery, in some way.
Honest contractors are always in the minority. They tell their clients directly, they can provide only an approximate cost estimate and then specify it as they learn more about the project (or move step-by-step).
If you would like to save your time and avoid communication with “fakers” you should first know how to choose a development team for your project. It is not easy and every step requires careful planning.
Of course, many clients fall for flattery when getting acquainted with a contractor. Often “honest” companies get into a situation when people come to them with a cost estimate made by “fakers” and say: “Why can’t you say how much the app costs? These guys gave me an exact figure…”.
There is no sense to argue that a faker’s cost estimate is far from reality, a client will consider it a dirty trick from our side. It does make sense to wait until a client faces first difficulties, what happens quite quickly. Or they can do their best to explain what is necessary to make a detailed and exact app cost estimate. If you belong to the above-described category of clients go on reading, you will find out a lot of interesting things :)
According to statistics from The Standish Group only 32% of projects meet estimates, the remaining 68% of them (!) are underestimated.
This research confirms the observations of our company.
So, why is it impossible to evaluate the cost of the entire project at once, and why should you refuse services of a company if it has provided you with such an estimate?
Consider the following example: you are asked to organize a barbecue party. The first question to you is: “How much will it cost to do it?”. If you are an experienced organizer you can give a relatively clear answer at this stage, but it will 100% differ from the actual cost of the party. To give a more detailed answer you need to collect some information starting from the simplest things:
- How many people will come?
- Do they want any entertainment?
to more complex ones:
- How old are your guests? Will they drink alcohol?
- What do they prefer to drink?
- What kind of meat do they like?
Now imagine yourself in the shoes of this poor organizer, who is forced to fix the cost before all the above questions are answered, and, moreover, an amateur neighbor is dumping.
Do you agree that such simple specifying questions help to make a cost estimate much more accurate? It is more complicated with IT projects because an answer to each question requires hard work, a research, a survey of target users, etc.
So, how to calculate the most precise app cost?
Following the lean approach is a good solution here. It says to take small, tangible and fully transparent steps. There are 6 stages that could be distinguished in a perfect project. Within each of them the lean approach and agile development methodologies have to be applied too.
To estimate the cost of this stage, the only thing needed from a client is an idea. It gives an approximate understanding of the project scope and whether there will be a need for nontrivial solutions or innovations that could require a research to estimate the cost of their development.
There is a big team that works together with a Business Analyst (Producer) at this stage and consults him.
If not to go deep into details, a simple series of hourly talks with a client helps to estimate an app development cost much more precisely, but this estimate will still be flattery, so it’s better not to do it.
This is what our client gets at the end of consulting:
- A document — Consulting Report;
- Business Model Canvas;
- Sometimes — a fundamentally different idea, if a research shows that the market is oversupplied with competitor products or an idea is not realizable with modern technical equipment.
2. UX Development
The outcomes of the previous stage are a great start for clients even if they choose to work further with another company. Yet, if you do your work properly, it does not happen :)
Here the magic begins, a designer steps into the work. He works closely with other professionals (developers, other designers and business analyst, of course).
At this stage, the team estimates the cost of:
- UX Wireframes
- App map screens (relations between screens)
There seem to be no need to explain how priceless the above-stated information is for a precise cost estimate of the next stage (UI). Our experience shows that we never (!) exceed the UI development cost if a client agrees to the UX stage.
3. UI Development
Both the client and the company come to this stage fully prepared. They completely understand each other. Despite the fact that the UX engineer, who did the previous stage, can often do UI too, it is also fine to transfer an app cost estimate (and as a result, the development of the stage) to another professional of the department. It allows bringing a fresh perspective to a project, which is very important in the development.
At this stage the following points are estimated:
- Design analysis of competitor products;
- Development of several versions of a logo;
- Development of several styles for main screens;
- Development of interactive mockups;
- Preparing of Design Guidelines.
This stage is of great importance. Not only a UI engineer participates in it, but also developers, other designers, a project manager, a business analyst, a QA specialist and sometimes even end users. In other words, the work is coordinated between all interested key parties at each stage and their feedback is maximally taken into account.
4. Early Planning
This stage increases the accuracy of the development estimate by several times.
The entire team takes part in it.
The cost estimate of this stage consists of a great deal of boring technical things :)
In addition, here the team together with the client:
- Identifies MVP (sets up a list of features for it);
- Grooms a product backlog (a detailed list of all app features in the form of user Stories and test cases);
- Writes test cases;
- Develops technical specifications (if necessary);
- Plans project architecture.
5. MVP Development
Finally, we reach the point everything has been started for. If at this moment to ask clients to look back at what they have come with, it will make them smile :)
This app development estimate is the most complex and bulky. Nevertheless, it is already just a trick to do it relying on the results of the titanic work the team has done at previous stages.
In fact, this estimate is a ready backlog with user stories and test cases to implement.
In addition, the estimate of an app development cost may include the evaluation of:
- Work of a QA specialist;
- Work of a project manager depending on a role: from a ScrumMaster to a Product Owner (if a client doesn’t have time for this);
- Time, the team needs for SCRUM meetings;
- Work of a DevOps engineer.
6. Ongoing development/Support
This stage begins when a product goes on the market and becomes successful, of course. By this time the client already has a huge amount of information from his first users, which usually influences the future of a project dramatically. It cannot be foreseen at the beginning, and there is no need in that.
In a nutshell…
Drawing a conclusion, it would be good to say that this approach does not always guarantee 100% hit in the timeframes. It only reduces the industry average percentage of misses from 68% to 20–30% of the accepted minor ones.
In 2013, MLSDev did more than 100 projects and in 2015, it was only about 20. Why is the difference so great? It is sad to confess but we were among the army of “flatterers” at the beginning because of lack of experience. As a result, our clients were unsatisfied and we had to look for more projects to keep our load steady.
We have radically changed our approach in recent years. Unfortunately, people still love “flattery”, that’s why we do fewer projects now. Nevertheless, the ones we do, we treat like our own, which makes them successful. Thereafter our clients return with a greater scope of work, positive references, and new ideas. This kind of philosophy has allowed us to leave a classical outsourcing model of work behind and turn into an outsharing company.
What was it all about? Do not get fooled by flattery!
The article was written by Ivan Mak, the CCO and co-founder of MLSDev and first published on MLSDev blog.