Client:“I have an idea for an app and I want an accurate estimate right now.”
Contractor:“I cannot give you an exact estimate because there is not enough information/specifications/wireframes etc.”
Client:“But I can’t start and give the project to you without having that estimate.”
Any contractor dealing with this situation will fall into one of two types: “fakers” and “honest” ones.
Fakers (unfortunately, the majority of contractors fit 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 that 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’d like to save time and communication with “fakers,” you should first know how to choose a development team for your project. It’s not easy and every step requires careful planning.
Of course, many clients fall for flattery when getting acquainted with a contractor. “Honest” companies often get into a situation where people come to them with a first 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’s no sense in arguing that a faker’s cost estimate is far from reality — a client is likely to consider it a dirty trick. Instead, it does make sense to wait until a client faces first difficulties, which happens quite quickly. Or they can do their best to explain what is necessary to make a detailed and exact app cost estimate.
The Standish Group reports that only 32 percent of projects meet their estimates; the remaining 68 percent of them (!) are underestimated.
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 research to estimate the cost of their development.
A big team works together with a Business Analyst (Producer) at this stage and consults with him.
Without going 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.
At the end of this consulting, you should end up with:
A document (Consulting Report)
Business Model Canvas
Sometimes, a fundamentally different idea, if research shows that the market is oversupplied with competitor products or an idea is not realizable with modern technology
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 shouldn’t happen:)
Here the magic begins, and a designer steps into the process. He works closely with other professionals including developers, other designers, and a business analyst, of course.
At this stage the team estimates the cost of:
App map screens (relations between screens)
The above-stated information is priceless in establishing 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
After the first two steps, 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 this stage) to another professional of the department. It often brings 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. Warning: The cost estimate of this stage consists of a great deal of boring technical things. :)
In addition, at this stage the team works together with the client to:
Groom a product backlog (a detailed list of all app features in the form of user stories and test cases)
Write test cases
Develop technical specifications (if necessary)
Plan project architecture
5. MVP development
Finally, we reach the point everyone wants to get to — and it’s often a great moment to look back at what clients and contractor have come up with together working up to this.
Now, the app development estimate is the most complex and complete. 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 their 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…
It’s important to summarize by saying that this approach does not always guarantee 100 percent hit in timeframes. But it reduces the industry average percentage of misses from 68 percent down to 20-30 percent of the accepted minor ones.
In 2013, MLSDev did more than 100 projects. In 2015, we did only about 20. Why is the difference so great? 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!