Artificial Intelligence
Consulting
Development ServicesFor many custom development services providers, calculating man-hours required to deliver a client's software project is both a rocket science and a huge pain in the neck. That's because software development time estimation is often based on assumptions, comparisons and expert advice.
As a rule, rough man-hour estimations that clients receive from developers is a far cry from the actually spent hours. This results in overheads and unhappy clients who no longer want software outsourcing services, as they believe their tech vendors are just padding their bill with extra hours.
In this article, we will guide you on how to develop a realistic time estimation for your software project and achieve both your and your client's goals. Here are 13 best practices that your software company can follow when calculating developer time for their clients' projects.
Factors Affecting Time Estimation
There are a number of factors that make software development time estimation complex, including:
- a number of tasks (programming, system design, testing, etc.) that are to be delivered in a single project;
- difficulties in estimating the dependency between those tasks;
- past and present trends that affect the development time of software products;
- the importance of quality control checks; and
- the nature of client expectations.
While these factors may be inherently complex, they have an adverse effect on the accuracy of estimation. For instance, there may be a high level of uncertainty in determining the amount of effort that is required to write a software system's code. Similarly, uncertainties are generated during the estimation of software development efforts when a particular task is dependent on other tasks.
This situation is quite common because many software projects have elements happening concurrently. For instance, a project may involve designing and building an application, while performing maintenance work on an existing application.
The following infographics describes a typical reality for many companies dealing with software development estimation practices:
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 software delivery to a 3rd party developer like Intersog 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.
Typical Q&A about Time Estimation
See below the typical answers to requests lacking client's detailed specification / information about the solution to be built:
Question #1: How much time would it take to build an IoT app for connected cars (using Android Auto and CarPlay SDK)?
Answer: 1,000 man-hours in total: 520 for Android only and 480 for iOS only.
Question #2: How much would it take to create a hybrid mobile app for FinTech?
Answer: 3,000 man-hours in totla, including a prototype and all required API integrations.
Question #3: How much would it cost to build a simple Android application?
Answer: 368 man-hours in total, including this time breakdown:
- 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 #4: I'm choosing between building a native app for both iOS and Android versus creating a cross-platform app for eHealthcare. How much would it take to build each?
Answer:
Would you like to learn more
about talent solutions
- 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.
Deloitte's Outsourcing Survey Report refers to around 85% of IT service providers failing to deliver clients' projects within the initial software development time estimate.
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 the developement company doesn't meet their own time estimation, the client suffers from the following consequences:
- Missed milestones and delayed release
- Budget deficit
- Overtime work and pay
- Poor team morale
- Lost revenues (especially in case of fixed price projects)
- Unhappy and disloyal users
- A lot of stress to cope with
Now, let's review some available options that can help developers estimate software project duration more realistically and precisely. We organized 13 methods by 3 groups, as follows below.
Traditional methods
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 time estimations provide arguments and the whole team should negotiate on the realistic and doable amount of man-hours to be sent to the client.
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. They can estimate the project for you and give feedback on your team's estimate. The most important thing is to accept the external team's feedback without criticism.
Project management methods
5. Risks
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
Assume you only have 80% of your IT resource availability. Let's say your JavaScript developer Mike works 32 instead of regular 40 hours a week. Make sure to apply this 80% to your milestone dates planning, but NOT to the estimate itself.
As such, you estimate 40 hours, but inform the client that task will be completed in 6, not 5 days. It allows you to secure possible sick leaves and other unexpected moments as your project is being underway.
Estimate your Software Dev Team cost in just 5 clicks with our Calculator.
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".
8. Statistics
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!
Would you like to learn more
about talent solutions
Best Practices
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.
11. Immersion
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!
