by Susan Cramm

How to Do More With the IT You’ve Got

Dec 01, 20056 mins
BudgetingIT Leadership

IT’s capacity for change lies within its architecture.

It’s futile for CIOs to try to explain why IT projects cost so much and take so long. No one is interested in hearing about the cumulative impact of having to chase after ever-fickle, self-interested business partners with a series of uncoordinated, short-term development activities built on the technology du jour. When IT leaders do this rant, they sound like teenagers who aren’t taking responsibility for wrecking the car. It’s up to CIOs to push out the dents in their architectures and get their (or really their company’s) money’s worth.

This article is the third in a series examining promising concepts to improve IT-business alignment. Last time, we equipped Ernest, a real CIO at a large company, with two mechanisms for managing IT demand: corporate strategy-making and IT value accountability. But improving demand management is only part of the answer to Ernest’s challenges. His IT department is stymied, day in and day out, by an expensive and inflexible architecture. Unless he addresses his supply of IT—that is, the capacity of IT to effect change within his company—Ernest will be unable to make progress toward alignment.

Where has all the money gone?

As in many IT organizations, Ernest’s capacity for change is severely limited because 70 percent of every IT dollar goes to nondiscretionary expenses (in support of the existing applications, infrastructure and user base) rather than new capabilities. There are many ways to reduce these “lights on” costs of IT, such as vendor contract renegotiation, systems and process standardization, technology retirement, strategic sourcing, automated tools, and tiered pricing and service levels. Unfortunately for Ernest—like so many of you—he has no idea what is driving his costs. His monthly financial reports, with costs broken down by General Ledger account number, are useless. The byzantine after-the-fact cost allocations result in more questions than insights.

Effective cost reduction programs require an understanding of where Pareto’s Law is located in the numbers—for example, which 20 percent of the applications, technologies, services and customers are driving 80 percent of IT costs? Ernest has heard of activity-based costing (ABC), in which all IT charges are allocated to categories on an hour-by-hour and invoice-by-invoice basis. He has also heard nightmare implementation stories about ABC, such as the CIO who invested $10 million over two years to implement an ABC system that is dying on the vine due to the impossibility of managing to the level of process and data complexity required by the system.

Instead, Ernest needs to explore activity-based budgeting—calculating the actual costs of last year’s products, services and consumption, setting rates for IT services to match, and basing next year’s IT budget on that. This is a reasonable first step (and possibly the only one he will need to take) to understanding IT cost drivers. With this level of insight, CIOs can not only identify cost reduction opportunities but also influence future consumption, by having conversations with the business before the budgeting process begins. CIOs can show business managers what products and services they consume—at what level and at what cost—and brainstorm approaches to lower their consumption, reduce their rates or both. By reducing the “lights on” costs, activity-based budgeting frees up the supply of IT.

The new IT staffers: architecture students

Another way to increase IT’s capacity for change is to improve its architectural flexibility. CIOs can implement technology development approaches that promote integration and reuse. In Ernest’s case, this will require a big attitude change from his IT group. The company’s legacy systems are a mess, but his team needs to make the most of what it has, because there will never be enough time or money to do it right. The old expression, “systems are like pancakes—throw the first one out,” may be true, but it’s impractical. Some of Ernest’s “legacy” is only two or three years old because his predecessor, when chartered to replace existing systems, faced the familiar constraints—lack of time, people and knowledge—and developed stand-alone inflexible systems. By failing to consider integration and reuse, that CIO re-created the past that the company was so desperately trying to leave behind.

Ernest needs to clean up the existing infrastructure and leverage what strengths it has as he delivers new functionality. It so happens that Ernest is a former enterprise architect—a background that will serve him well. He understands implicitly that the future of IT consists of layered architectures, including separation and modularization of business logic, encapsulation of data structures and sources, and utilization of standard services. It’s time for him to dust off the plans that, in his former architectural role, he could never get anyone to adopt. Ernest can integrate his company’s disparate systems by using messaging and service-oriented architectures.

Even while upgrading his architecture, Ernest can deliver new IT capabilities. He can identify the intersections between his current architecture, his likely IT projects and business/IT strategy (to learn how to incorporate business strategy into IT maxims, see “Your To-Do List for Managing Demand”). For example, Ernest can create a centralized view of his company’s customers by utilizing messaging with his existing databases as he builds out call center and warehouse management capabilities. He can also enhance the company’s supply chain by knitting together existing applications with an integration layer. Finally, he can use any new development effort as an occasion to start building a service library. (While it’s true that dramatic development cycle time and cost improvements can only be realized with a fully featured service library, this approach will give Ernest a way to deliver new capabilities without the unrealistic burden of redeveloping existing functionality.)

Although Ernest now has the right tools for IT-business alignment, he is just one man among many. The road to alignment is perilous, and he can’t go it alone. In the next and final installment on alignment, I will emphasize the importance of leadership from all levels of the organization in enhancing capacity and flexibility.