As a software house's client, you should be prepared to go through a process of estimating the cost and time needed for developing an app. While this seems straightforward and most of the estimation work is done by the software house's team, there are many areas which you should approach with mindfulness. To be successful, within budget, and on time, it is best to work closely with the development company.
Here is a 9-step guide that will help you and your provider work better together.
Prepare yourself before you reach out
Before you ask a software house for estimation, get prepared. The more precise the description, business goals, user scenarios, the better. Even if you are looking for a company who will offer an analyst to refine your requirements, it is good to have a starting point. The following items are always welcome by the development company before they start crunching the numbers:
- Business cases
- User scenarios
- Wireframes
- Designs
- Video walkthroughs
- Diagrams explaining functionalities
- User activity projections (how many users per day, hour, minute?)
Be open for honest conversation
After you send your documentation to the software house, be open to having a lot of honest conversations. Even if your documentation is precise, there will be a lot of deep digging before the estimation can be finalized. Be ready to answer even the simplest and most general questions. Sometimes it’s enough to have an e-mail exchange but expect a few web conferences too. If the development company does not have enough input, they will estimate very conservatively, and you may receive a very high estimate that will factor in the unknowns.
Invest in analysis
If you’re not sure how the application should work in detail it is worth investing in business analysis. Together with a business analyst, architect or a senior developer you will be able to refine the business case and user scenarios. Investing in this stage will save you money and time later. This is an optional step, especially in the case of larger and more complex projects.
As a result of such analysis you should receive documentation. Such documentation should be clear enough for any software company to start working with it.
Expect a detailed estimation
A detailed estimation should include a breakdown of costs. This will allow you to understand better which parts of the apps are the costliest ones. It will help you make an informed decision about striping down the functionalities, if you need stay within a budget. A sample breakdown of a smaller application cost may look like that:
Front-end
- Layout design - general (10 man-days)
- Layout design – 16 views (20 man-days)
- User alerts (2 man-days)
- User profile (5 man-days)
- Charts and graphs (25 man-days)
- Etc…
Back-end
- database setup (2 man-days)
- database - architecture (3 man-days)
- database repositories (2 man-days)
- deployment - AWS (1 man-days)
- user import - CSV (2 man-days)
- mail sender (2 man-days)
- email template to PDF (2 man-days)
- Etc…
Machine learning component
- Basic neural network PoC (10 man-days)
- Ci for neural network (2 man-days)
- Etc…
Total cost: 88 man-days
Make sure the estimation is complete
Double check if all costs are included in the estimation. Some of the work that is not actual coding, but is also paid work includes:
- Project management (or scrum master)
- Analysis
- Quality assurance (testing)
- Internal and client meetings
This work may be factored in the tasks or be a separate part of the estimation.
Alternative estimations
If a software house understands your needs, they may offer more than one estimation. For an example, there can be a full version, and a basic version. The basic version would be stripped down from all parts that are not critical. You may also actively ask for more than one version of the estimation.
Be aware that whichever version you choose to follow, it has to address your needs. A basic version of the app may be good for a simple proof of concept that will be tested on a closed group of users and shown to prospective investors. If the application is aimed at productive environment and its launch is aimed at real users, a basic-stripped down version may not be the right choice.
Cross-check your estimation
It is good to have at least two estimations from two different providers. This will help you compare the effectiveness of work of different companies and find out more about the work done so far. If the estimations are close (less than 20% difference between them), the estimations can be considered as consistent. This means both providers have a similar understanding of the project.
If the difference in estimations is significant, it may be due to several reasons:
- The providers have a different understanding of the app – you should probably have more conversations with both to make sure that they have enough information.
- One of the providers has a more conservative approach – higher estimation is a form of insurance factoring in the uncertainties.
- Man-day estimations are similar, but the cost of the man-day is different – this may mean that one company is more expensive than the other, but there might be other reasons. Some companies would include project management (and analysis, QA, etc.) in the cost of one man-day, rather than show it as a separate category in the estimation. It is best to have a detailed conversation about and have clear understanding of the the pricing model.
Fixed price or time & material?
Discuss the cooperation model with the provider early in the process to avoid surprises. There are two main cooperation models with a software house – fixed price and time & material. Fixed price means that the client knows the exact cost of the development upfront. It is good in certain situations, especially when each cost has to be precisely budgeted for. In time & material model the estimation is a point of reference, but actual costs may be both lower and higher. While there is no 100% control over budget, the time & material model is actually safer for both the client, and the development company. Here is why:
- Flexibility during development – certain functionalities may be left out if you understand that they are not crucial after you start
- No need for long documentation – the client may guide the development company as they work together
- Ongoing cost control – since all the development tasks are logged in a time tracking system, the client knows how much was already spent and make further decisions accordingly. If the costs are lower than expected, additional functionalities may be developed. If they are higher, some functionalities can be left out.
- Cheaper service - as a rule, the fixed price model assumes a degree of uncertainty and a margin is added on top of the actual estimation. This helps software houses manage the risk and uncertainty. Thus, a client may end up paying more than they would in a time & material model, where only real work makes it's way to the invoice.
Man-days, velocity & calendar weeks...
An estimation usually gives you an indication of how many man-days it will take to develop the application. This measure simply says how much time in total will be spent on development tasks. It does not give you any idea how many calendar weeks or months it will take to develop.
Why?
It is because each developer, or each team, has a certain velocity. While a man-day means 8 hours in terms of work, it is rare that a developer spends exactly 8 hours every day working on just your application. She or he will be eating lunch, taking holidays, attending training courses, which will impact the actual velocity. Let’s assume that on average a team member will work for three quarters of each day on your application, this means that her or his velocity is 6 hours (out of eight).
To estimate the calendar time needed to develop an application you may use a simple equation:
Real time needed = estimated man-days / (number of team members * velocity )
Let’s say that in case of our sample estimation (see above) there will be 3 people working on the app. This means that:
Real time needed = 88 man-days / (3 team members * 6/8)
Real time needed = 39.1 days = ~8 weeks
Estimating the development time and cost is usually a complex task, and mature software houses are open to cooperating closely with the client to reach the most accurate result. The more answers you provide, and the more questions you ask - the better.
