The Value of Counting Function Points

Okay, we showed you the "how" of FP counting, but we'd like to return to the "why" of FP counting, because we 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?"

Our experience with FP counting has shown all of the benefits we 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:

The ability to accurately estimate:
- project cost
- project duration
- optimum project staffing size
The ability to determine other important metrics, such as:
- Project defect rate
- Cost per FP
- FP's per hour (a productivity rate; We tend to refer to it as "Velocity", a term I like from Extreme Programming)
- The productivity benefits of using new or different tools

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

For us, the biggest benefit of FP counting means that a company can get into fixed-price software development projects. When a prospect says "Can you do this project for $100,000?" we 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 we can be pretty well assured that the company won't go bankrupt on this project.

Why is this important? Because we've never met a developer that likes to estimate programming work, and the bigger the work, the worse is gets. we don't blame them; estimating is very hard, especially on larger projects. We'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, We'd much rather have some cold statistics that we can rely on in times like this, even if it's just as a point of comparison.