Rants
Questions
Soapbox
Best Practices
Apply today for a FREE subscription to CIO Magazine!
Sun, Nov 11, 2007 4:39 EST
|
Posted by: Michael Gentle in Best Practices Topic: Applications
Current Rating: |
If a stock you invested in dropped 20% overnight, you or your stockbroker would definitely be aware of it the very next day, and after an analysis of the situation, might take action to sell or monitor closely. If however the expected benefits of an IT project dropped by 20% compared to original expectations (over a period of a few months, never mind overnight), the business sponsor probably wouldn’t even be aware of it, because benefit monitoring of IT investments is rarely carried out, or because the numbers are fudged to ensure that the original expectations are “achieved”, or simply because the bad news never reaches him.
The fact that such a situation can exist today, with companies routinely spending 2–10% of annual revenue and up to 50% of capital spend on IT, and then failing to monitor their investment performance, is probably one of the best indicators of a failed business model. This model equates IT to the construction industry, which assumes that software can be conceived upfront like a house, and subsequently scoped, spec’d and signed off for commitment by both client and vendor - and that the documented business benefits will remain unchanged and start flowing once the solution has been delivered.
NO FREE LAUNCH
The main focus of business benefits today is to get a project launched - usually based on a subjective business case, since projects are usually centrally funded, with ineffectual pricing or chargebacks. Not surprisingly then, there is little or no incentive to check that the benefits actually materialize as planned.
Once the project is under way, the original business case is more or less forgotten and IT gets on with the job of delivery. Ongoing project monitoring by investment committees or project review boards focuses mainly on budget and schedule. Nobody however owns the benefits side of the equation – as in being accountable and responsible for its delivery – so it gets left by the wayside.
And yet, as we all know, business requirements, costs, benefits and risk are changing all the time! Who hasn’t yet been 3 months into a project and realized that the original business benefits are no longer achievable, because of challenges linked to business processes, data quality or user buy-in? And how often during such cases could IT do nothing about it, and have to see the project through to its inevitable demise? (I don’t know about you, but I’ll take the 5th on both those questions…).
HOUSES OF ILL REPUTE
The solution to this disconnect lies in accepting that building software is not like building houses. You can specify requirements for a house or a building because the desired outcome is relatively easy to conceive and visualize. You can then have it built to spec by a vendor because the corresponding specifications (weights, dimensions and forces) cover standard mechanical components (beams, widgets, tiles) and are applied to the hard sciences (physics, engineering and mathematics) to produce relatively predictable results. The business benefits that the client will derive from the house (eg better resale value in a new neighbourhood) or building (eg office space leased) are totally divorced from the construction phase, and will only kick in after delivery. The construction industry can therefore monitor project progress using mainly budget and schedule.
Building software however, which is about business processes and human behaviour, is another matter altogether. It is difficult to specify requirements because it is not easy to visualize the desired outcome, since you are usually trying to do something you haven’t done before. You can’t nail down costs because you don’t usually know at the outset what the technological solution