Nobody owns the Change Monkey

Joe Pucciarelli of IDC discusses the changing buying behavior of enterprises when acquiring IT capabilities.

Interview conducted by Vinod Baya

Joe Pucciarelli is the program director at IDC, where he provides wide-ranging research on IT leasing and financing strategies for both providers and IT organizations; IT organization management practices, such as chargeback, funding strategies, and capital allocation strategies; and IT organization financial practices, such as equipment and software capitalization guidelines, vendor management, and on-demand contract management. He provides research coverage for leading IT financing providers, such as CIT, HP Financial Services, GE Capital, IBM Global Financing, and Microsoft Financing, and he also provides supporting financing program pricing, residual risk management, and distribution strategy analysis.

In this interview, Pucciarelli discusses the changing buying behavior of enterprises when acquiring IT capabilities.


PwC: You’ve studied the IT acquisition habits of enterprises. With software acquisition, what is different now from the past?

JP: In large enterprises, two different types of buying are happening with software acquisition. First, the operation of the core IT infrastructure meets the needs of most business users, and a lot of that is locked and loaded. It’s being supplied by vendors arguably in almost an oligopoly position. The level of innovation has slowed down. Most companies implemented the first round of ERP [enterprise resource planning] software in the late 1990s. What is not appreciated is that most companies capitalized that software over seven to ten years. They capitalized the implementation. So only right now—in 2007, 2008, 2009—are they paying off the cost of that first round of ERP software.

Companies have paid off the software that’s in. After they capitalized the software  in ’96, ’97, and ’98, they had to capitalize a whole bunch of new software in 2001 and 2002, because that was the second generation of updates to accommodate the Internet interfaces. The first generation of technology, as crazy as it sounds, really didn’t anticipate the Internet very well. So it’s only now that we have the opportunity to really begin thinking of new enterprise software.

The other thing is that software technology moves in roughly 10- to 12-year cycles. You move through a period of coalescing. Then you move through a period of dispersion. Right now, enterprise software technology is in a period of dispersion. It’s beginning to fragment. So you see things like—my favorite is mash-ups—taking a bunch of software that’s all disconnected and creating a seven-layer architecture to try to solve a problem and calling it an enterprise application. It’s a tactical solution at best. In my opinion, it’s basically taking a prototype and implementing it on a test basis. It has the advantage of speed and time to market but sustainability and reliability are concerns. I think these new technologies will continue to be explored over the next three to five years.

PwC: We’ve all heard that changes in the business environment are accelerating and that IT is called upon regularly to be agile in responding to such changes. How can enterprises use sourcing choices to be more agile with IT capability?

JP: Most companies and individuals have the following tendency: what you measure me on is what I’ll produce. If you’re looking for optimization of price, then I as an individual will create a scenario where I optimize on price. In many organizations, at least 40 percent of the time we see a focus on acquisition price and a disproportionate focus on on-going support and maintenance costs.

By 2008, you would think we had accepted the fact that we need to do total cost analysis and life-cycle analysis when buying products and technologies. But, by and large, most IT organizations buy IT equipment, software, and services with an incomplete evaluation of the life-cycle cost. The notion that we’re then going to factor into that a consideration of the ability of technology to change—that really challenges the ability of an organization to creatively structure an acquisition contract to consider that.

PwC: How is enterprise buying behavior changing to accommodate a changing business environment?

JP: So if I were to survey the IT budgets, IT budgets are going down, but IT spending is going up. It is still growing, although at a slower pace, so where’s the difference? Let’s call the difference X factor. More and more, the line of business gets involved in funding this X factor when a company needs IT capability to enable business change. Say a company wants to expand its operation in India or in Western China. It needs IT infrastructure to do that. How does it do that? The answer is that the company needs to make a significant investment. But that’s not in the IT budget—that’s outside the scope of IT’s budget. We continue to see business expansion and change being funded directly from business development budgets – subsidizing the IT budget.

Now, what’s interesting is that business buyers acquire technology differently from the way IT people do. IT people view their value proposition to the enterprise as fulfilling the requirements at the lowest cost. The business buyers tend to wrap a proverbial sheath around the componentry and look at inputs and outputs. In other words, in the IT vernacular, they buy solutions. So, as the business gets more involved in directly funding IT initiatives, expect the spending locus to move from the domicile of the IT organization—which wants to weigh the price of each rivet—to the business domain, the business buyers tend to acquire solutions instead of components. That’s going to drive shifts in IT buying practices. It’s who in the enterprise is influencing the buying decision, rather than some organic change that’s going to occur within the IT organization.

PwC: Do you think business organizations would be better able to accommodate future needs when making decisions about the solutions?

JP: The business people are buying business solutions. They’re not buying technology componentry. If your job is to buy technology components, you buy the cheapest components, right? And if your job is to buy a solution, you’re going to provide qualitative assessments and buy the best solution, however you or your organization define them. During the last year we conducted a survey of who’s involved in the buying process, and the key finding in our research was that there are four basic constituencies.

First, 83 percent of the time IT is involved in technology specs. Second, anywhere from 50 to 70 percent of the time the line-of-business buyer is involved in the IT solution. So, in other words, even on a mundane aspect of IT technology, a businessperson often weighs in and provides approval—and in times of economic stress, they may provide funding. Third, 91 percent of the time you must go through procurement, who says, “Yes, we got a good price.” Finally, 93 percent of the time the finance person has to look at it and says, “Yes, this makes sense. It’s in the budget. We can afford it. We’re going to buy it.”  So in the future and what’s going to drive changes in procurement models is something that’s not obvious, but I think the shift of power within the organization among the buyers will drive changes in procurement models, as opposed to just changes in attitude within IT.

PwC: How can enterprises think about contingencies, such as mergers and acquisitions or restructurings, and incorporate that in their IT planning process?

JP: I saw this wonderful article that laid out how to manage the players’ salary cap for a professional sports team. I had never thought about applying sophisticated mathematics to managing a salary cap. Before I’d thought about it, if you’d asked me, “How do you manage a salary cap?” I would’ve added up the salaries. That’s a very simplistic way of looking at it. But, there are many more nuances: What’s the probability that a particular player will be with the team in two, three or four years? You could look at the player’s position and create a Poisson curve for each player by position. If I did a present value analysis, I could completely change the dynamics of how I evaluate my players’ salary cap. Now, after I have read that article, it was as if I went from thinking about salary cap management in three dimensions instead of two dimensions.

The question you asked is how do I analyze my portfolio, and how do I do change analysis? To me, there’s a metaphor and a parallel between the two. In most organizations, we get out the adding machine, we run a total on things, and we say, “Well, we’ve hit the cap.” I don’t see scenario planning. I don’t see probabilities being factored into budgets. I’m not talking about taking this to an extreme level of complexity by using advanced mathematics like real options analysis. I’m not talking about anything more complex than simple probability analysis and maybe a little PV [present value] analysis. The answer is that I think it would be a really exciting experience to go through a budget portfolio and simply test a couple of different scenarios. I think a lot of companies would find that their scenario planning is so simplified that they’re leaving considerable opportunity on the table.

PwC: How would you assess where the industry stands today in this regard? Is anyone doing such a forward-looking analysis?

JP: I work with many different organizations, some of the best in the world. I was with a pharmaceutical company this past spring—one of the largest, most sophisticated pharmaceutical companies in the world. Pharma companies spend a lot of money on IT, and it’s also a differentiator in business process. So here you have a high-margin industry, which is driven by innovation, in which IT plays a role, and we were looking at their process for managing IT projects. Initially they were very proud that they had this process where they had individuals in each of the business units, and they were making incremental change. But when we looked at how the IT budget for innovation and new projects was being spent, more than 90 percent of the money was being spent 10 cents at a time on incremental change in 10,000 pockets around the company, and little of the budget was being invested on large, enterprise transformation type projects.

If you look at how change should be managed, you could argue that you should establish bands of projects on the basis of size and strategic impact. A percentage of the projects should be, for lack of a better term, shoot-the-moon projects. You should be doing projects that are on the far edge of experimentation and have big potential paybacks. To do that, you have to strike this balance between how much money you spend on the small incremental changes that bubble up from the bottom and the galactic change that drives down from the CEO or business leaders. The business leaders look at the market and say, “We have to face this challenge heads up, and we need to put a third of the IT budget against this.” In most organizations that would create havoc, because there are 10,000 constituencies that would not get their extra two digits added onto a screen and that would be viewed as the IT organization being unresponsive.

So I’m looking at one of the finest, best-managed pharmaceutical companies in the world, and that was the level they had reached. They self-appraised themselves and said, “We are doing such a poor job, we don’t even want to talk about it.” They recognized what they needed to be doing, and they said, “Wow, this is how far we have to go.”

PwC: You have said that financial considerations dominate the acquisition of IT solutions. Lack of changeability or responsiveness of IT solutions can expose an enterprise to risk, such as opportunity risk. How should enterprises address such risks in the acquisition process?

JP: The problem is nobody owns that monkey—who owns that risk? That’s the problem. That’s why you look in the studies, and the CEOs are worried about whether they can get the organization to change fast enough to respond. Because nobody owns the monkey. Lots of people own the monkey that, if their application is down, then there’s going to be a problem. If the customers’ needs aren’t met, there’s going to be a problem. We can quantify all that. But the risk of not growing and of not responding, who owns that? No one in IT owns that risk. IT owns the risk of nonperformance. If I own the risk of nonperformance, I’m going to make darn sure that I don’t have instances of nonperformance, so I’ll make conservative decisions. I’ll overstock, overfill, overstuff. I’ll put padding around everything so that once I have two levels of failure, I’ll still have some basic capability. I know that’s not a technical assessment, but we spend a lot of time talking about who owns the monkey here. Who owns the risk – the risk of failing to achieve, to change, to capture the new markets?