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