The Value of Counting Function Points

Okay, I showed you the ``how'' of FP counting, but I'd like to return to the ``why'' of FP counting, because I think motivation is a very important driver here. You need to asking yourself ``Why should you add as much as 1% to your overall software development effort?''

My experience with FP counting has shown all of the benefits I mentioned earlier in this document. Once you have a history of developing applications and you also have FP counts for all those applications, you can now add to your software development arsenal these capabilities:

1. The ability to accurately estimate:
   1. project cost
   2. project duration
   3. optimum project staffing size

2. The ability to determine other important metrics, such as:
   1. Project defect rate
   2. Cost per FP
   3. FP's per hour (a productivity rate; I tend to refer to it as ``Velocity'', a term I like from Extreme Programming)
   4. The productivity benefits of using new or different tools

So, the question to you is ``What are these abilities worth to you?'' 

For me, the biggest benefit of FP counting means that my company can get into fixed-price software development projects. When a prospect says ``Al, can you do this project for $100,000?'' I can run around the corner, scratch some numbers on the back of an envelope, and give them a Yes or No answer. And while doing this I can be pretty well assured that the company won't go bankrupt on this project.

Why is this important? Because I've never met a developer that likes to estimate programming work, and the bigger the work, the worse is gets. I don't blame them; estimating is very hard, especially on larger projects. I've met a lot of developers, and some always estimate low, some always estimate high, and others go both high and low. As a manager, I'd much rather have some cold statistics that I can rely on in times like this, even if it's just as a point of comparison. 

• An example of how this works