Paul Strassmann: I actually bumbled into computers purely by accident. In 1953, I was a graduate student at MIT, and I had to make a living, so I took a job as a consultant helping to study the traffic patterns of the New Jersey Turnpike (in those days, the New Jersey Turnpike was one of the largest generators of punch cards). At the completion of this project, I wound up writing the first dissertation on business uses of computers at MIT. That was in 1955. Ive remained in computers ever since.

In 1962, I joined General Foods and got quickly promoted to Director of Information Systems, a position which at the time was equivalent to CIO. At the time, Kraft was having similar problems as General Foods, and I was just about the only living CIO those days doing complicated billing. Consequently, in 1964 I moved on to become the global CIO for Kraft.

In 1965, when IBM could not deliver 360s, I was one of the few CIOs or Directors who actually started buying Honeywell computers. This caused a tremendous uproar on the East Coast. IBM actually tried to get me fired. Luckily, the guy who tried to get me fired left IBM to become the Executive Vice President of Xerox. And when Xerox bought a computer company, he told the Board of Directors, I know just the guy who knows how to kick IBM computers out. The moral of the story, of course, is that you always do whats right. After all, you never know how things are going to turn out.

So I became the Global CIO of Xerox. I started off in the Executive Committee of the company but when Xerox started generating astounding research at PARC, I became Vice President of Strategic Planning. I remained in that position until 1986 when I retired from Xerox.

During the course of my career, I had always served on a variety of government committees. Consequently, after leaving Xerox, I was called in to help evaluate the projected cost savings for the Department of Defense, in the anticipated event that the Soviet Union was to dissolve. When the Department of Defense and Mr. Dick Cheney, then Secretary of Defense, discovered that we were 70 billion dollars short of the dividend- the so-called Peace Dividend that Congress had declared we were to remove from the Department- I got hired as the DoDs first CIO. At the time, the position was known as Director of Defense Information. I was charged with the task of removing 35 billion dollars worth of IT costs from DoD.

When the new administration came in, I retired from DoD. However, many of these same people who were in the Department of Defense moved over to NASA, and when they ran into trouble there they called me out of retirement, and so I spent a year at NASA as the acting CIO, patching things up until we could put a longer term CIO in place.

Paul Strassmann: The amazing thing about NASA was that, on a budget of 15.5 billion dollars, the IT spending was 2.2 billion. This 2.2 billion was way over 15% of total spending. In fact, thats just about the highest ratio you will find anywhere. So I wanted to go over very carefully where the money was going. Naturally, this puts you into conflict with a lot of entrenched bureaucracies, very deeply entrenched bureaucracies consisting mostly of experts on the subjects of computers. At NASA, everybodys an expert.

Paul Strassmann: I think the biggest challenge is getting IT positioned into the budgeting and planning process, directly positioning the CIO to be there at the table when management makes decisions on how to allocate resources.

Most CIOs dont sit around the table when decisions are made about where to spend money. They come in and make their presentations, and they wind up being perceived as just a cost center, not as an investment center. And very often an organization wouldnt even know the full cost of their information resources or the lifecycle costs of their information resources. All of this makes the implementation of capital budgeting and strategic alignment very challenging.

Paul Strassmann: The managerial challenges can be quite formidable, too. For example, how do you bring a newly minted CIO into a position when, previously, there was no CIO? To further complicate things, the responsibilities of your new CIO will overlap with those of the CFO, who has traditionally occupied this role. I spent the first 30 years of my career basically extricating IT from the clutches of the CFOs. And that is not a graceful separation.

Paul Strassmann: Ive looked at all sorts of numbers claiming to explain what has happened to software productivity, particularly lines of code metrics and function points metrics. Frankly, I do not find any of these statistics very viable or supportable, except for some very micro-level analyses conducted by Capers Jones.

I would say, though, that much of the waste in software development is related to managements shifting objectives and the continual tearing up of code to meet these shifting objectives. I like to call this the junk-build-junk cycle. If you continue to junk and destroy and re-juggle and then re-integrate software, your productivity numbers are not going to look so good.

Paul Strassmann: My approach to increasing productivity is to focus on the infrastructure. This is actually the over-arching theme of everything that Ive been pursuing for the past 30 years. Specifically, if you have an infrastructure that is robust, and are able to add applications on top of that infrastructure, you will be able to deploy, test, and upgrade applications very rapidly.

A robust infrastructure means that security, reliability, and recoverability are all solidly in place, on the infrastructure side. One should not muck these issues into an application. Thats where people get lost. I frequently see large organizations and government agencies struggling with horrendous projects that cost a fortune and that last for years and one of the biggest reasons for these problems is that they are always attempting to build their own unique infrastructure. What they end up with are escalating costs and escalating frustrations.

Paul Strassmann: I am going to be a contrarian now and tell you that nothing works as well as a good story. In fact, whenever I move into an organization, whether its as a CIO or as a consultant, the first thing I look for is something that will make a contribution. And that usually takes the form of an anecdotal story that people will enjoy. So Im in favor of anecdotes.

Eventually, however, you will have to get to the numbers and to the benchmarking. That is the next thing you have to do and if youre lucky the anecdotes will provide with you with the cover and the management support to do this successfully.

Paul Strassmann: First of all, the percentage of annual revenue as a percentage of IT spending is in my opinion a totally bogus number. It should never be used. I can make that number come out any way I want, depending on how I do outsourcing. For example, two companies doing the same business can have totally different ratios, if only because one of the companies buys more of their materials from the outside whereas the other uses their own mines and their own labor.

Regarding a CEOs expectation and how this should be measured discretely, this will vary depending on your competitive positioning. You must keep in mind that CEOs are very concerned about competitive position. Theres always somebody gaining on you if youre a leader and dropping out if you are a loser. So if you are at the bottom of competition in a business that is highly concentrated, your spending of IT is going to be limited to very demonstrable examples of cost savings. On the other hand, if youre one of the top dogs, one of the top three or top two companies, then your IT spending should really be looked at in terms of how well it is deployed in order to maintain your lead position.

Paul Strassmann: One of the most interesting ways of looking at the IT budget is to break it down into what is contributing value to the firm (e.g., marketing, development, and research) and what is simply supporting the infrastructure (e.g. the e-mail systems, the HR databases, the financial systems, etc.) What I find increasingly to be the case is that less and less IT money is available for value-added, competitively useful work and more and more is just being sucked into the infrastructure. There are companies that have hardly any new money available, except for keeping the existing applications alive and patching them, or upgrading them. Consequently, if you want to cut back on waste and recoup some savings right away, my advice is to get your infrastructure straightened out. That usually means outsourcing a big hunk of it.

Paul Strassmann: There is a time to outsource, and there is time not to. You just need to know the difference.

For instance, in cases involving the coding of very complex applications, I have frequently been impressed by the fact that many offshore operations, to overcome the cultural and linguistic problems they face, haven risen to maturity levels which are much higher than those found here in the states. When viewed from this perspective, sending your coding, testing, and validation offshore can make a lot of economic sense.

However, weve really got to look at the overall project costs. Coding is just a very small part of overall project costs. The big problem with projects today is systems integration. These costs, the system integration costs, can totally dominate overall project costs. And systems integration cannot be outsourced. For better or worse this has to be done organically, inside the organization.

Paul Strassmann: Well, you dont get tenure by writing about maintenance. Thats just the way it is. If you want to be successful in this field, you write about development. The system is rigged against maintenance, against the bulk of the costs.

However, I have two books that deal with this issue rather exhaustively and that skip over the issue of development almost entirely. The first one is called The Business Value of Computers. The second one, my most recent book, is called The Squandered Computer.

Paul Strassmann: My favorite book is actually a cartoon book. After writing a couple of 500 page books, my son, a PhD from MIT, explained to me that nobody reads the damn things. He advised me to publish something with cartoons, something that everybody would understand. So I joined up with a cartoonist by the name of John Klossner and we put out a very funny book of computer cartoons- The Irreverent Dictionary of Information Politics.

Klossner was actually the illustrator for a much more serious book I wrote called The Politics of Information Management. This focused on information management as a political process, rather than a technological process.

Paul Strassmann: If youre a bureaucrat, and you want to secure your position, in the old days you just had to make sure that your name showed up on the organization chart and in procedure manuals. But nowadays, procedure manuals can be changed very rapidly. Code, on the other hand, can not. So why not develop or maintain an application in such a way that it effectively welds your position into code? Once code is in, it is very difficult to dislodge. This is where the politics of information management has its origin.

I should mention that, because of the demand for this book, I have actually posted it on Google. If you do a search on Politics of Information Management you will find that you can read it online. Google has scanned the entire book.

Paul Strassmann: Talk money, dont talk technology.

Paul Strassmann: I think one of the key metrics to track is how many times you build communication interfaces or file recovery routines. Theres actually a whole list of things that people build into their applications that can be tracked like this. For example, how many security filters do you put on individual networks? How much labor is being spent continually upgrading and putting in bridges and patches? How much money goes into this? You really have to trace the dollars, and then you have to do whats called value engineering.

Value engineering is what people do in the auto business. You take an automobile, you take it apart, you lay it on the floor, and then you go over each part and ask, Why do we have this part here? This is how they discovered that automobiles could use the same carburetors and the same nuts and the same screws. At the time, each engineer had been designing their own material bill. And in the absence of common parts, the parts costs and the acquisition and procurement costs were horrendous.

This is the same discipline that has been used so successfully in materials and purchasing streamlining. It is understood and widely used in manufacturing and across many industries. However, with the exception of Google, the technique, to my knowledge, is not being applied to IT in any kind of consistent way.