Every time we start collaborating with a new client, our web and mobile app development company prepares two comprehensive documents that reveal all the finest details related to the costs of our client’s project.
Perhaps you’ve already read about why and how we make rough estimates (if not, you should definitely do this). And now it’s time to uncover everything you’ve ever wanted to know about the detailed estimates in MindK.
What is a detailed estimate?
A detailed estimate is a meaty document that provides you with a comprehensive breakdown of costs for your project.
It divides the whole scope of work into elementary parts — features.
Each feature is estimated separately by our cross-functional teams.
The time it takes to finish each feature adds up to form a detailed budget for your app.
Detailed estimate vs. rough estimate
If you want us to put a price tag on a basic idea you’ve just shared with us, we’ll gladly send you a rough estimate. It can give you only a general idea about the costs of your project.
A detailed estimate is a much more nuanced and extensive document.
In rough estimates, we divide your app into huge blocks of functionality called epics.
In detailed estimates, we take a step further and break each epic into features.
Before we can write the detailed estimate, we have to gather and document all the requirements, clear up all the open questions, and write the specification (in case of a Fixed price engagement model used for the project).
This way we are able to find out all the necessary details beforehand and provide the most precise estimate as the result.
There can be no assumptions on this stage, only assertions.
Detailed estimate vs. accurate estimate
Truly accurate estimates are only possible after finishing the Discovery phase, prototyping the solution, writing the specification, and approving the detailed scope of works.
For the fixed-price projects, we draw up a detailed estimate only after the Discovery phase is completed. We usually bill this phase as a separate project.
For the Agile/Scrum projects, we use a different approach.
According to this methodology, product development is a dynamic and highly flexible process. Its main aim is to produce a ready-to-use solution every 2 to 4 weeks and adapt to the users’ feedback.
Making a definitive estimate for the whole project doesn’t really suit this approach.
In most cases you can’t really predict the shape your app will take months and years down the road. That’s why for Agile projects we prefer to use what we call Guesstimate.
It allows us to prepare approximate, yet extremely detailed estimates without wasting a ton of time on the Discovery phase.
What constitutes a detailed estimate?
A detailed estimate in MindK usually has three sections: the estimate itself, software-related costs, and risk analysis.
1. The Estimate
The section gives you a feature-by-feature breakdown of costs for your project.
For the Fixed-price projects, we just write down the precise cost of each feature, but for the Agile projects, we can only provide a guesstimate.
In this section, we include nothing but the features that are 100% confirmed by our clients. If they at some point decide to add a feature, we estimate it separately and update the document.
If a project is a complex one (i.e. you need both a web application, an iOS /Android app, a chatbot, and so on), each of these components is estimated separately.
Each feature is written down in the form of a user story. This is a simplistic way to render a piece of functionality from the user’s point of view.
It typically reads: As a <role>, I want <feature> so that <advantage> (i.e. as a blog owner, I want a subscription form, so that I can get subscribers to receive updates on the new blog post.).
User stories are short, concise, and flexible. But most importantly, they are extremely easy to understand, even if you’re a total newbie in the world of software development.
The detailed estimate includes the breakdown of costs for every type of work:
- Business Analysis;
- Markup (HTML);
- Quality Assurance;
- Project Management (PM).
The cost of PM usually accounts for around 25% of the bottom line. The exact percentage depends on many factors:
- The more complex a project gets the more communication and management it requires.
- The bigger the team gets the more challenging becomes its management, which results in the additional PM hours.
- The number of third-party integrations can also influence the management costs. In addition to being yet another feature to implement (and manage), third-party API often require our PMs to contact the service providers.
For instance, the communication with large companies (big banks, large corporations, etc.) as API providers can be a real pain in the neck. The high level of bureaucracy and rigid hierarchy structures can turn such a simple task into an excruciating chore.
In a separate subsection, we list all the standard features.
Our experience with the mobile and web development tells us that certain features and tasks are present in all the applications. They can, for example, include setting up the servers and development environment, project management, Google Play release (for Android apps) and so on.
2. The cost of third-party solutions
When it comes to the software development, reinventing the wheel is a costly and often pointless endeavor. Thankfully, every standard task or frequent problem in the IT world has at least one ready-made solution. Sometimes they are free, but in most the cases you have to pay for them.
If to complete a project we need to purchase some third-party software, service or library, we estimate their cost and include the figure in the document.
If your project, for example, supports SMS messaging then we’ll have to pay for an SMS gateway.
If your website design is based on a specific ready-made template you want to use, then we’ll add its cost to the estimate.
Or if our clients want us to help them with the hosting, we suggest them the best options (such as Amazon Web Services, DigitalOcean, or other proven services). Thus, the costs associated with the hosting and server maintenance will appear in this section.
3. Risk analysis
Every project carries some inherent risks. The Project Manager’s job is to identify them and develop the strategies to deal with them.
These estimations will then serve us as an insurance against a wide variety of dangers that threaten the development of your project.
Here are the examples of risk categories that occur in the product development:
- Quality/Technical/Performance (i.e. use of new or exceptionally complex tech, technology modification, impossible output targets);
- Project Management (i.e. faulty allocation of funds and time, insufficient project planning);
- Organizational (i.e. lack of consistency between the cost, time, and scope goals, poor prioritization, irregular backing);
- External (i.e. changes to legislation, problems with vendors and subcontracting parties, climate).
After the risks are identified, the PM prioritizes them and performs a risk analysis.
Its aim is to find out each particular risk’s probability (i.e. the odds of its materialization) and impact (the consequences of its materialization).
As I’ve already mentioned, the API providers can be slow to respond. They can hold off sending the necessary documentation or offer subpar support. This is a real risk that we should warn you about in advance. So we put it in the risks section and at the same time develop an effective risk-management strategy to minimize the threat’s probability and its impact.
Now you know what to expect from the detailed estimate in MindK. The document will give you an exhaustive answer to the question of your project’s price and also help you with the budgeting. Finally, it will provide a clear picture of what you will pay for.
Is there anything else I could tell you about the detailed estimates in MindK? Just drop a note in the comment section and I’ll give a detailed reply!