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.

Next: An example of how Up: FunctionPoints Previous: Step 5: Calculate the