METHODS OF PROJECT ESTIMATIONS

METHODS OF PROJECT ESTIMATIONS

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.

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

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.