For many custom development service providers calculating man-hours required to complete a software development project is a rocket science and a huge pain in the neck. As a rule, rough man-hour estimations that clients receive from developers is a far cry from the actually spent hours, which results in overheads and unhappy clients who don't trust their provider and believe they add up hours to make more money from their project. In fact, that's not true in most of cases! Today, we're facing a tough competition for price points and software development providers rarely blow up client's budget in order to win and retain them.
That's a typical reality for many clients in software development:
And that's the reality for project developers:
Each time we receive a request for quote (RFQ) from a prospective client, we provide general estimate in man-hours that's based on our experience with similar projects and our historical data. The problem is that many companies looking to outsource their project development to a 3rd party developer provide very little initial information about what they're going to build, so it's next to impossible to create a precise estimation in man-hours.
See below our typical responses to requests lacking detailed specification / information about the solution to be built:
Question: How much would it take to build an IoT app for connected car (using Android Auto and CarPlay SDK)?
Our answer: 1,000 man-hours in total: 520 for Android only and 480 for iOS only.
Question: How much would it take to create a web and a hybrid mobile app for FinTech?
Our answer: 3,000 man-hours including a prototype and all required integrations.
Question: How much would it cost to build a simple Android application?
Our answer: 368 man-hours: 160 for front-end development, 50 for backend development, 40 for custom web forms, 32 for QA, 38 for UX/UI design and 48 for PM / analysis
Question: I'm choosing between building a native app for iOS and Android and creating a cross-platform app for eHealthcare. How much would it take to build each?
- Native development: 3,138 man-hours including iOS development - 1,041 man-hours, Android development - 1,062, QA - 442, UI/UX design - 184, PM / analysis - 409.
- Hybrid development: 1,616 man-hours including PhoneGap development - 1,002, QA - 290, UX/UI design - 113, PM / analysis - 211
Factors that affect any initial / rough project estimation are as follows:
- Availability of detailed technical requirements specs
- Type of project (no matter how similar projects seem to be, each one is unique and may require different technologies and tools to execute)
- Functional features expected in the application and their robustness
- Complexity of backend integrations, and many others.
I bet 90% of service providers never complete the project within the initial estimate they provide! Correct me if I'm wrong.
Also, since today's software is built the Agile way in iterations and clients always want to improve their solution, each change request or scope increase will add up man-hours to project development.
When developer doesn't meet own estimation, it can have the following consequences for the company:
- Missed milestones and delayed release
- Budget deficit
- Overtime work
- Poor team morale
- Lost revenue (especially in case of fixed price projects)
- Unhappy and disloyal clients
- A lot of stress to cope with!
Now let's review some available options that can help developers estimate projects more realistically and precisely.
1. Poker estimate
Bring together a team of programmers and BAs, voice client's request for them, let each do own estimation quietly and then compare and discuss. Those who give the highest and lowest estimations provide arguments and the whole team should negotiate on the realistic and doable amount of man-hours to be sent to the prospect.
2. Comparison to similar projects
Here you need to compare the current project to the actually spent man-hours on a similar project in the past, but not to the initially estimated scope! There's also a complexity factor that should be defined and multiplied by man-hours planned.
3. Bottom up & top down
Step one is to decompose your main task into several or many sub-tasks and estimate each separately. Then sum up the results to get a final estimate.
Step two is to estimate the task as a whole. If discrepancy between bottom up and top down estimations is huge, you need to find a reason and negotiate a compromise.
4. External expertise
If your team has issues estimating the project in man-hours, get some help from a team next door.
Project management methods
Always include 15%-20% on top of your estimation to cover risks. Post factum, risks sound like "as was determined in the development process your database design will have to be changed..." The most risky parts of project are those that are most complex or most unclear. If you've already decomposed your task, you can include 15%-20% on top of relevant sub-tasks only.
6. Part-time resources
7. Out of scope
As mentioned above, many clients like improving their original ideas while the project is in progress, which is absolutely OK nowadays! It's absolutely NOT OK to believe the initial estimation will cover these changes! Did the client update project requirements? Respond with "that's great, please see the updated estimation which includes these new features".
In their book Manage the Unmanageable Mickey W. Mantle and Ron Lichty claim that on average developers code 55% of their time and spend the rest of time communicating with PMs / tech leads, colleagues, testers, designers and the client, doing code review, research and switching between tasks. If we look at the project as a whole, 1/6 of time is spent on primary coding and 1/2 on testing and bug-fixing. Having worked in IT services industry for 12 years now, I can say for sure this data is true!
9. Admit your estimation errors in a timely manner
It's absolutely OK that your initial estimation will be updated after the discovery stage. The more details the client provides, the better you know how many man-hours to plan for each process. And the sooner you find out the initial scope has changed, the better, as you can always discuss with your client how to curtail the scope, change a milestone deadline or add more roles to your project team.
In a best case scenario it's developer's PM / tech lead who should first notice that team is lagging behind the planned scope, but in real life you also need input from developers. That's especially relevant in situations when PM / tech lead is involved in several projects at the same time and/or is too busy to delve into each project details.
By the way, at Intersog we never allocate one PM to oversee multiple projects, as such practice proves to be ineffective and even detrimental for some projects! We only supply a dedicated PM / team lead for each project to make sure the client is getting the best from our expertise.
10. Individual speed of work
In real life, projects are not always executed by those people who estimated them. As most of development processes are very agile today, teams often scale up and down depending on client's current situation and project needs, so it's quite likely that the project will be done by those who weren't involved in initial or rough estimation. That's especially relevant in situations when provider brings in external help to estimate project scope (see p. 4 above). As such, common practice is to estimate man-hours based on the average speed of a mid-level developer in your company.
Don't forget it requires some time to get familiarized with project scope and tasks, and explore workarounds and available solutions. Always plan 8-16 hours extra time for research prior to project launch.
12. Avoid gaps in estimation variants
If you choose to provide your prospect / client with 2 or more estimation variants (e.g. high end and low end; pessimistic, realistic and optimistic), make sure you don't show a big gap in a proposed range of hours. This difference shouldn't account for more than 20%! Estimation range of 200-1,000 man-hours will frighten and frustrate any client. So be consistent and realistic! However, a big gap in ranges is acceptable provided that you have very little knowledge about the project details or if you'll be expecting unpredictable performance of a 3rd party library or service.
Companies that send RFPs/ RFQs your way normally expect each estimation to include the following key aspects: coding, design, analytics, management, QA and unit testing, code review, user manuals and documentation, automation. Always specify which of the above are included and which are excluded from your estimation to avoid future misunderstanding and issues with client.
The Intersog Approach to Project Estimation
In order to eliminate rough estimation errors, we entice our prospective clients to participate in an interactive workshop (1 or 2 days) that's normally held in their office or virtually. The workshop allows us to collect as many project details as possible, complete successfully a discovery and ideation stage, assist with technical requirements specification and milestones planning. This approach allows us to come up with precise estimations. You can read more about our Workshop and its takeaways here.
And here you can read about costs of application developments in 2017!
Inspired by https://dou.ua/lenta/articles/estimate-development-time/