Think Past Internal Boundaries to Justify IT Projects

In a flat budget world how does one justify IT projects and validate claims of return on investment (ROI) and value? IT purchasers are not only requesting ROI justification, they are demanding it. IT project sponsors must validate their proposals in precise and measurable ways.

New EMA research seems to validate the “word on the street” about IT budgets in 2008-2009. A survey carried out in February 2008 showed that 37% of IT budgets increased, 37% decreased, and the balance were unchanged. 37% - 37% + 0% = 0%. Put another way, the IT budget world is flat.

Making decisions is a measure of risk and reward. We know the investment. We think we know the rewards. Industry statistics peg the IT project failure rate at around 70%, and while the costs to the industry are staggering, worse is the poor reputation we in IT have with the money people.

Basing service value primarily on desired business outcomes is the message of ITIL v3. Further, using risk to (evaluate) those business outcomes is probably the most effective way to get business' attention, as well. Measuring service value by risk is a wonderfully clarifying process because it quickly shows whether a project is justified. A secondary benefit is that virtually every business manager got their position by making sound risk vs. reward decisions so it enhances business/IT alignment.

IT traditionally does not “speak business”, and often falls back to techno-babble instead and the ever-present use of “9’s” to describe IT value and performance. How can one make a business decision based on a statement of uptime? A better way is to transform IT performance into business impact, expressed as quantified risk. However, one can only understand business impact by reaching outside the boundaries of the enterprise and this is uncharted water for most IT managers.

Of primary concern to IT should be the performance of customer and user assets (e.g., end-user, end-customer, enterprise product) because without them there is no way to value a service. Without the context in which the customer (or user) uses the service in support of enterprise objectives it is difficult to define value. Thinking outside the box means we have to understand transaction boundaries.

A Concrete Example

Here is an example. Imagine you work for Colorado Concrete Company, “CoCoCo.” Your business is making and delivering concrete. The sole reason for any employee of CoCoCo is to sell, service or support end-customers and end-users consuming the product of the enterprise. Now lets think about how to value a new project at CoCoCo, an IT service, say, a new radio dispatch system. How might you approach justification of this project?

The classic IT way is to say, “It’s cheaper than the old system,” or, “It will be up more often and thus more useful, we will move from three 9’s to four 9’s.”

This is necessary but insufficient to justify a project in today’s flat budget reality. Instead, we need to think outside the corporate boundaries of CoCoCo, and think about the end-customers and end-users of our concrete products. This is hard for many in IT. It is common for IT workers to have stilted, simplified or incorrect beliefs about the business in which they work.

Thinking about the end-customers of CoCoCo, one could discover that they are unhappy with the inability to shift deliveries, for example. Following up with the end-customers, we might discover they have chosen to work with other suppliers for this very reason. Further research shows the reason CoCoCo cannot shift deliveries is the lack of ability to know the precise location of the delivery vehicle—an unexpected finding, and a source of measurable ROI.