How to Estimate Software Development Project In Man-Hours Realistically

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?

Our answer:

  • 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.

Classical 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 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

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.

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!

Best Practices

Continue reading in Intersog blog…