Ten ways to justify technology

It was 1997. ERP and Y2K spending was in high gear. SAP did not have Value Engineering. KPMG (now BearingPoint) had not dreamed up its R2I methodology. And at Gartner, I kept getting requests for payback templates. And kept listening to claims from vendors for coming payback from client/server, workflow etc. "Rapid implementations are incompatible with returns" a salesman once told me "more important to get the system in".

So, I wrote a research note called "Ten Ways to Justify Acquiring Packaged Applications"

Almost a decade later we are hearing similar "trust me, there is payback" around SOX, SOA and other IT initiatives.  And even a debate on whether IT investments can really be justified.

I thought I would dust off the research note and present the technology "justifiers" I had identified back then:

1. Savings from the technology automating what was previously manual
2. Savings from data rationalization - e.g. through Master Data management facilitated by the technology
3. Savings from business process changes the technology facilitates
4. Savings from structural changes (e.g. moving to shared services enabled by the technology)
5. Savings from optimized information (back then constraint based decision tools were starting to allow for smaller physical asset bases)
6. Savings from not having to invest in Y2K fixes
7. Savings from disbanding other legacy systems (e.g. through data center consolidation. Key word is disbanding, not keeping it around)
8. Revenue increments clearly attributable to the new technology (rare back then - and even today)
9. Infrastructure investments - it was my cop out for Investments that "have to be made". My suggestion was not to burden a specific project with all those costs but to hold them  in a corporate account and amortize them over other projects which also would leverage that infrastructure.
10. Intangible or soft justifiers - no monetary calibration

(For copyright reasons I cannot share the full report - but you can still get it at the Gartner store -  TV-000-254 dated September 25, 1997)

Too many 9s or 10s were and continue to be a red flag for me. 8s I am usually excited to see since they are rare. As you can imagine I saw way too many 6s in the late 90s.

Love to hear reader's experiences around more contemporary projects.

Comments

[Zoli Erdos]

My favorite is #8, or similar: not just revenue increment, but keeping existing revenue, i.e. not losing it to competitors.

Case study from my SAP Implementer life:
The Client, a major test and measurement equipment manufacturer had no real-time visibility of their available-to-promise inventory throughout their own plants accross the US and several countries in Asia and Europe. It typically took them min. 3 weeks to be able to promise a delivery date to customers. Needless to stay they started to lose business. After the SAP implementation customers could receive the promised delivery date in real-time. For this company the key driver was not savings, but the need to stay in business.