|
|
AS OF 7/4/2008 8:34PM EST
|
May 1, 2004 —
Return on investment (ROI), risk analysis, requirements analysis, alignment with strategic objectives-it's a given that these methodologies should be used for judging the merits of a software investment.
So, why do our hearts sink at the prospect of doing these analyses? The answer is simple: They don't work. Oh, they might be fine for big-ticket enterprisewide software, but for lower-cost software these heavyweight techniques don't work for several reasons.
One is that predicting the value of an uncertain asset over time is counterproductive when it can more easily and accurately be demonstrated in a trial.
Another is that analysis processes often introduce "paralysis by analysis" into organizations; people are unwilling to invest time and effort into getting something approved. In many cases, the ROI predictions are often incorrect due to errors in assumptions or calculations. Also, a predictive approach encourages bloatware, with large unnecessary feature sets satisfying a requirements analysis but not necessarily benefiting users.
Imagine you've used a product intensively for two weeks and found that it meets all of your requirements at a reasonable cost. It would be pretty galling then to be told by some manager to try out three similar products, write a report and make a presentation to top managers.
An evaluation is a far more productive use of resources than a prediction, which often relies on false or exaggerated claims from the vendor. The best way to determine a technology's potential and value is to put it to the test in your environment.
Paralysis by analysis. The company I work for sells software tools for software developers, DBAs and application testers. The people interested in our products are intelligent, highly trained and generally well paid. They work on projects that involve spending hundreds of thousands, often millions, of dollars. You would think that they'd have little difficulty justifying the purchase of inexpensive tools.
Wrong. Often developers, DBAs and testers can order software only after they jump through lots of time-consuming hoops to justify the purchase to management. Not surprisingly, some don't bother going through the laborious requisition and evaluation process, despite really needing the tool; the process is just too painful. I pity the folks working in government departments and large multinationals, who often tell us that they need the tool right away but can't get it approved for another three months.
ROI calculations are normally wrong. The sad truth is that the extensive ROI calculations favored by many organizations almost always contain fundamental mathematical flaws. I used to do such calculations for Shell, and I confess to being guilty of a few howlers myself.
Moreover, the assumptions that are required for an ROI determination are more often guessed than measured: "How many person-years will a better bug-tracking system save in the next three years?" No organization can make such a prediction with any certainty.
You get what you measure. Any predictive approach focuses on product characteristics that someone judges as providing underlying value. The natural path is to buy a product that lists the most features. This leads to bloated, overpriced software solutions that claim to do a lot of things, but don't do anything well enough to justify their cost. Generally, the more features and tick lists a product satisfies, the harder it is to use and the more difficult it is to support.
Years ago, a month after I started my first proper job, I attended one of those "management meets the new employees" lunches. I was seated next to the CTO, who asked me, "So what could we do that would make your lives easier?"
Without really thinking much about it I said, "Why don't you just let us spend the money that is needed for our projects without lots of hoops and other justifications?" There was a ripple of uncomfortable laughter around the table: "How ridiculous! We couldn't let people do that." Aside from that gentle, slightly horrified rebuff, no proper response was given on that occasion.
Since then, I've heard these explanations when I've posed the same question: "There would be no control over cash flow." "Spending would not be aligned with corporate strategy." "Fiscal chaos would ensue."
Yeah, right! Even low-level IT employees make US$50,000 per year, and yet giving them a budget to spend up to $2,000 a year on choosing the right software for their jobs is going to cause chaos and cash-flow problems?
The real issue is enforcing management authority. That might make sense for enterprise decisions, but not for a software tool that costs a couple hundred dollars. If $2,000 worth of tools might make them 10 percent more productive or efficient, or improve the quality of their work, isn't that a good investment? In many cases, the answer is "no."
If you think I'm just being cynical or naive, then ask yourself this: How often has anyone gone back and analyzed the actual ROI of small software purchases? When it comes to anything but very expensive enterprisewide software, management requires that you follow corporate protocol for justifying a purchase, but doesn't see the need to verify the value of that purchase after it has had some time to prove itself.
If the concern really were ROI or husbanding organizational resources, there would be as many post-mortems as there are prepurchase analyses.
The drawn-out process of proving value before implementation is the wrong approach when considering small software purchases. Allowing low-priced tools to prove themselves after they've been tried and then purchased would empower employees to make small decisions that will benefit the wider organization. This reduces paralysis and allows organizations to refocus on core activities rather than expensive guessing games that only demoralize an organization's most vital asset: its people.
Simon Galbraith is marketing director for Cambridge, U.K.-based Red Gate Software Ltd., which sells database, load-testing and debugging tools.
|