Okay if you are an Architect or PM  reader of my blog, you are about to receive a free gift, others will likely be bored silly by this one.  This gift is the result of hundreds of hours of research, real life practical experience and has successfully estimated many projects that completed on-time and on-budget. No royalties requested or expected.

Now some will tell you that Project estimation is a science. It is not. It is an art form.  It is an art because the best, most accurate estimate in the world is valueless unless you can convince your client that you are right. This methodology has the ability to make that proof.

There are 3 basic dimensions of the estimation problem.

– how much stuff do you have to do that you know about?

– how much stuff do you have to do that you don’t know about yet?

– how good are you at doing it?

Which really has two sub-categories

• How productive are you?
• How many mistakes will you make that you will have to fix?

So let’s put a metrics framework around these dimensions.

– Stuff you know about – Let’s measure it in Function Points (IFPUG standard) http://ifpug.org/

– Stuff you don’t know about – Let’s call these contingency Function Points

– How good at it are you – We’ll measure this in Hours per Function point.

– How many mistakes will you make that have to be fixed? – We will also measure these as contingency function points.

In it’s most basic (and useless) form. The estimate starts as

Now I will assume you can read the IFPUG guide and learn how to count function points. It is a well-established, architecturally independent mechanism for sizing any application existing or future. To grossly oversimplify it, it counts stuff the system does. The more stuff it does, the more functions points. The method then asks questions about non-functional requirements such as performance, security, networks etc and then bumps the count accordingly based on complexity. You can hate it or love it, but the method works, for sizing the application in question.

This will provide you with your Core Function Point count.

The next important selection is “how good are you?”

Here is what you need to know. It is both development environment and skill specific. Here are my magic numbers.

1. 3GL environment with a solid development toolset and highly competent resources – 16 hours per function point
2. OO language with solid development toolset and highly competent resources – 14 hours per function point
3. OO language with great toolset, strong re-usable library and team that has worked together before well – 12 hours per function point
4. OO the above, but a very small team (4-6 developers) with agile methods and customer who can make decisions immediately – 8 hours per function point

*** Note: Hours per function This is NOT just development time ***

This is the complete time required to deliver the functionality associated with that function point. It includes:

You may wish to change the percentages to reflect your own experience, but the numbers here are the industry standard for projects > 1000 function points and the averages of more than 3,000 reporting projects. This is the list you provide when your PM tells you they need 20% of the billable hours to do their job properly. If they do… time to get a new PM.

So lets assume team type 3 and a 2,000 function point system.  The base calculation is Total Hours = 2,000 FP x 12 HRs/FP = 24,000 Hours = 12 Person Years Effort

This provides you with overall hours (less contingency). Let’s use Ian’s magic estimator tool now to break this down for an actual project into a Unified methodology.

The spreadsheet provides a methodology specific breakdown of the hours based on best practice metrics.

You adjust the team size for associated schedules (with some caution on reducing the timeline below reasonable delivery windows)

The next step is to provide an average load by resource (initially equally balanced across the project to drive the cost numbers on a fixed run rate) and then load the resources to the average by phase (keeping costs in-line with the standard).

Now we add the rates for each resource class and you have a project cost without contingency,

So we have now modeled a 15 month project, with average FTE’s of 12 with a cost of $2.4 Million dollars without contingency.

Now we need to talk about contingency and rework. These are calculated on your basic plan.

Rework is likely the simpler to assess. Rework changes dependent on:

– how much you know about the business domain

– how expert your customer is about the business domain

ie. is it a new area or are they taking a very known process and automating it differently.

– how many true design or coding errors/bugs you will introduce into the system.

My rule of thumb is as follows:

2% of total FP’s if my team is unfamiliar with the domain and add it across the project

5% of total FP’s if my customer is doing something “new” to them and add it to the Inception and Elaboration phases.

0.6% of total FP’s for each if  any of the tools, libraries or resource experience level are substandard for the team level chosen and add it to stabilization phase.

use the average cost per function point $2.4 Million divided by 2000 = $1200

Example: We understand the domain  (let’s say Ecommerce) the customer does not and Team Level 3 meets all the criteria. I will then add 5% of the total FP as contingency.

2000 * 5% =  100 @ $1200 each. I add $120,000 to the inception and elaboration phase as contingency buffer only.

Applying this process has some art and some science. By working through it with your customer they will see the timelines based on industry methods and your confidence in delivery based on productivity.

It is also NEVER a discussion about rate and I always use this example with customers

2000 functions points @ 16 HR/FP = 32000 hour project @ $100 /HR  =  $3.2 Million

2000 function points @ 8 HR/FP = 16000 hour project @ $150 / HR =  $2.4 Million

You make the argument about productivity not the hourly rate. Smart customers pay for performance and high performance consultants are great value even at higher rates. Smart customers can also use this same tool to sanity check the quote they received for doing a build.

If you would like my estimation framework spreadsheet to try the calculations, feel free to email me.