If you ever had to deal with mobile app 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 can 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 our company gets into a situation when people come to us with a cost estimate made by "fakers" saying, "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, which happens quite quickly. Or, we can do our 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 then 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 no doubt be 100% different 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 of the above questions are answered.
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, research, a survey of target users, etc.
So, how do we estimate costs at MLSDev?
We follow the lean approach in our work, that says to take small, tangible, and fully transparent steps. We have distinguished 6 stages in a perfect project. Within each of them, the lean approach and agile development methodologies are also applied.
To estimate the cost of this stage, the only thing we need from our client is an idea. We approximately understand the scope of a project. We also understand 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 we don’t 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 our clients even if they choose to work further with another company. Yet, in 90% of cases, it does not happen!
Here the magic begins, a designer steps in. He works closely with other professionals (developers, other designers, and business analyst, of course).
At this stage, we estimate the cost of:
- UX Wireframes;
- App map screens (relations between screens)
There seems 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
We come to this stage fully prepared. We and our customer completely understand each other. Despite the fact that the UX engineer, who did the previous stage, can often do UI too, we sometimes practice transferring an app cost estimate (and as a result, the development of the stage) to another professional of the department. It helps to bring a fresh perspective to a project, which is very important for development.
At this stage, we estimate:
- 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 does a UI engineer participate, 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 has recently appeared in our process, but it has increased 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 culmination of many technical things. In addition, here the team together with a 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 end point. If at this moment, we ask clients to look back at all the progress we have made together, 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 we plan 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 our 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.
Here our company usually works according to monthly plans or cost estimates of the tasks from a backlog, which is already stuffed with new interesting points.
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, we 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", which is 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.
So, what was this all about? Do not fool others with flattery!
This article was written by Ivan Mak