Project spending PUT on hold?
It is becoming clear that once the project business case for a software investment is put to bed, few organisations revisit the project to determine the returns achieved.
It is becoming clear that once the project business case for a software investment is put to bed, few organisations revisit the project to determine the returns achieved.
Many claim lack of resources but there is an assumption that once a project has been approved, it must deliver. Experience at Whirlpool, Hershey, Nike and others would suggest otherwise.
Lack of post-implementation analysis explains why claimed benefits rarely get put into the context of performance. For example, when was the last time you saw a statement from a CEO extolling the virtues of an IT investment in the annual report?
One of the problems is that IT departments rarely have a financial perception for project assessment because it isn’t part of their core skill set. IT is about control, cost containment and conservatism; not value delivery. This means they find it hard to understand concepts like return on investment.
Vendors want to sell into IT departments because they know that’s the place they can impress with their ‘bits and bytes’. But it is only recently vendors have recognised the merit of helping IT to create credible business cases that push their pet product to the top of the spending agenda.
But when assessing choices, does IT actively engage with finance? In many cases yes, but the response is invariably reactive rather than proactive.
There are exceptions. At Durham county council finance and IT are working closely together with good results. But finance found it difficult to pinpoint hard measures that would justify their investment.
However, the council expects to see real reductions in paperwork and improved efficiency.
Durham’s experience is not unusual – if anything it typifies the current mood where projects are only going to be accepted if there is a clear payback or where survival mandates change. But if organisations are struggling to measure payback and not looking at post-implementation success then how does anyone realistically select software except on a fuzzy, qualitative basis?