For over 20 years I’ve been an advocate of using metrics for improving IT processes. Shortly into my career as a COBOL developer, I was introduced to Function Point Analysis; and ever since it’s been the most powerful tool in my toolkit. After all: size matters! Once I learned to quantify the amount of functionality delivered by a project or an application, I could zoom in on cost, effort, duration, productivity, and quality because I now had a normalization factor to perform comparisons (Cost per Function Point, Hours per Function Point, Defects per Function Point, etc.).
Shortly after getting my Certified Function Point Specialist certification, I became obsessed with the different measures and metrics pertaining to software and IT. Soon I became a Certified Software Measurement Specialist, where I learned everything there was to know about how to measure everything there was to measure in software (or so I thought). It’s a pretty powerful feeling being able to help organizations baseline their current capabilities so they could determine if implementing the latest and greatest silver bullet was really going to give them the gains in productivity they had been striving for.
I spent several years traveling abroad, helping international organizations implement measurement programs based on function points so they could realize the productivity gains of outsourcing their development work to major system integrators. This was a fantastic method of starting organizations down the road to process improvement. Unfortunately, this solution fell short. Vendors began complaining because they weren’t getting paid for the “non-functional” activities they were performing. And the productivity gains they had hoped for were not being realized, at least, not to the extent anyone had expected or assumed.
It wasn’t until about 5 years ago when I joined QSM that I finally connected all the dots; the tools in my toolbelt were only part of the answer. Why? Because it took the SLIM tools to account for the non-linear tradeoff between effort/cost and duration. I thought I had all the calculations (in a spreadsheet) to determine how many hours it should take to develop or enhance a certain size application, or how long it should take in person months. I could even tell you by platform.
What I couldn’t tell you was that doubling the staff does not cut the schedule in half, or that putting too many resources on a project to meet an insane deadline has negative impacts on quality. And, as it turns out, adding just a couple of weeks to a project’s duration decreases cost, improves quality, and might free-up some costly resources to perform other critical work in your organization.
The fact of the matter is, I couldn’t tell you a LOT of things (even with my spreadsheet and knowing the size) without the use of the Putnam Equation - aka "The Secret Sauce." Hey, why don’t you join me July 16 - 18 for QSM’s SLIM-Estimate Training, and I’ll let you in on all kinds of secrets you should know. Trust me I sure wish I had known about this stuff 20 years ago!