Recently the correlation between seeking the best gasoline prices and software project overspending collided for me. On one hand, IT projects will easily outspend their budgets, and on the other hand, in our private lives, we are doing all we can to save pennies in our personal budgets.
From time to time I have found myself pondering whether to drive the extra 5 miles out of my way in order to beat the system and enjoy the best gasoline price in my area. I don’t believe I am alone in this quest as evidenced by the websites that publish the lowest gas prices within a certain radius. Typically the competing stations have very small differences between their prices. If I play my cards right, I may be able to save a total of $.50 - $.75 for a fill up. In almost all other walks of life $.75 is not even worth a second thought.
This got me thinking about the phenomena that I see almost every day as I spread the word about the advantages of parametric estimating. Plainly put, there is widespread tolerance for losing money on IT projects. It’s not an intended facet of the project, but a very digestible one due to its frequency. More than once I was told, quite explicitly, that projects can hemorrhage hundreds of thousands, and in some cases, millions of dollars before any corrective action is even considered, let alone enacted. However, losing $50 of our own personal money carries much more pain. The dynamic of this contrast is easily understood – the corporate budget is not our money…but in the end it really is our money, as indirect as it may be. And the ability to stem the loss is within easy reach, but the appetite for doing so seems pale.
Projects that I’ve been privy to seem to have this unwritten and unspoken built-in accommodation for budget overages. There’s a high tolerance for overspending by X dollars. Many of these projects share a common denominator: unrealistic schedule and budget expectations born out of improbable project estimates. Admittedly I’m a tad biased toward using parametric tools to estimate projects only because I’ve seen the positive results from doing so. Heroes and heroines are made and careers are bolstered when projects stay within budget. The simple fact is that project estimates based on sound historical data will likely yield realistic budget targets.
But there is some force at play in the marketplace that fights this notion. Perhaps the cost benefit of a historically tuned project estimate is too abstract, or seemingly too overwhelming to make it a compelling action. From my experience, it’s a matter of several hours of assembling historical data in order to glean big savings on software projects.
Years ago, I had a new client attend our training class to learn how to use the SLIM tool to estimate budget, schedule and risk of his projects. As I typically do, I visited the class during a break one day and asked him how the class was going. He responded “Great! Incidentally, how come you never told me how easy it is to save money with SLIM?” His question was delivered with a sense of incredulousness, despite me having explained this notion several times leading up to his visit. On one level, I get it – sometimes I feel like the door to door window salesperson and I are making the same promise of saving our clients money, with the exception that the savings is easily measured on a software project. Just think if we could accurately budget all the projects in our portfolio – the cumulative effect would be truly impactful.