Few companies can afford to launch projects that will not deliver tangible business value – even regulatory compliance projects need to deliver results, even if that is just to keep the company’s leadership out of jail!
New product release projects, or mergers & acquisitions should have measurable financial results. The waters start to get murkier as we get into business process (re)engineering projects and get downright muddy once we get into back-office technology projects.
So what are some challenges with defining and proving quantifiable returns on technology investments?
1. Technology projects are rarely revenue-generating
One only has to look at the business cases offered by many back-office technology vendors regarding “operational cost savings” incurred by implementing their solutions to know that this is pure snake oil. The majority of these business cases are based on the assumption that freeing up skilled staff time from administrative drudgery automatically translates into higher productivity – if the resources spend more time at the water cooler or on Facebook, those savings are never realized. Business cases built on FTE reduction were great a decade or two ago, but few companies have a lot of low hanging “dead wood”. On the other hand, the acquisition, implementation and ongoing operational support costs of these technologies are quantifiable and when put on the spot, few vendors can truly claim a positive ROI that would stand up to scrutiny.
2. Technology projects deliver products and services that change almost from the first day they are released
Few technology projects are completed with the end products remaining in a static state for more than a few weeks. Bug fixes, vendor upgrades and change requests all change the very nature of what the deliverables are. Given this, how long can a business owner continue to claim benefits from a project before it is clear that the service has changed too much for this recognition to remain valid? I would be surprised if a measurement period longer than a year after release would be considered valid. This supports the application of release management practices to technology services – instead of continuous changes, plan scheduled release projects that will roll-up the upgrade, bug fixes and service requests. This way, it is possible to distinguish between the benefits achieved from the original product as compared to subsequent releases.
3. A lack of operational metrics or no base line data
Aside from those organizations that have undertaken operational excellence initiatives requiring the definition and capture of key metrics, the majority of companies do not have well defined non-financial KPIs and even those that have defined these may not have sufficient historical data to be able to prove that a particular technology project made a tangible difference.
As Levitt and Dubner discovered in their Freakonomics research, establishing a strong causal relationship between an action and a positive outcome is difficult in a system as complex as the operational environment of most organization. Could it be that improvements to a particular KPI were less a result of a technology project, and more related to turnover in staff or indirect influence from individual training plans? Can a technology project by itself make a bigger difference than a process enhancement or a staff quality improvement?
I’m interested in receiving your comments on this topic given that it is a core expectation of most projects these days.