Q: How does business-driven IT differ from other forms of technology implementation? And why does this distinction matter?

RZ: The major difference is that it's IT-driven from the business side. You have to start with the business needs and figure out how IT is going to leverage your attempt to meet strategic objectives. It firmly places business in front.

DL: Too often in an organization, the technology itself drives people's views of the potential of what can be done. Then technology options are placed before executives, and we say, "Would you like to do this or that?" If the proposal generates some interest, they then proceed with some kind of business case and a project gets launched.

But in fact, it ought to start at a higher level and from a different direction. It should start with the questions: What is the business strategy, and how can IT deliver that strategy? When this is driven from the business side, it, in effect, defines all kinds of things about IT itself. It defines the way IT is structured, the leading edge of technology that IT pursues, the investment levels in IT as well as where in the organization the spending should take place. On the other hand, while we firmly believe that the business is in charge, there are certain things that IT has to do properly in order to make it successful. That's why both elements are presented in the book.

Q: The opposite approach might be labeled technology-driven IT. Is there anything wrong with companies saying, "Here's an interesting new technology; how can we apply it?"

DL: There's nothing wrong with that at all. There is a great benefit in looking at the bleeding edge, understanding the bleeding edge, and experimenting with it. In my IT organization at U S West, for example, I had a group of people in what I called the "skunk works" who were allowed to play with new technologies. Out of that came some interesting ideas. But that isn't the way you run your major IT investments. It could turn into that if you discover an element that could generate competitive advantage. But that usually takes place after a bit of time has passed in the evaluation of the technology, its cost, and its impacts on the business and existing architecture. I'm in favor of working with the bleeding edge, but I'm not in favor of having that piece of it drive the whole direction of IT.

Q: Whose job is it to ensure the alignment of IT and business strategy? The CIO and other IT managers? Or the CEO, CFO, and other business managers?

DL: To some extent, it is all of the above. But there really is a lot of weight on the CIO's shoulders. He or she has to be part of the business team, be someone who understands the business, and still be able to lead a technology organization successfully. If he or she can develop strong relationships with the key business leaders, then that CIO will, in effect, become a partner with those leaders. The CIO should know where IT can deliver on the business side of the ledger. Delivering on things that help the business will build trust between the business side and the CIO, so that the business brings the CIO into its strategy as early as possible. Then you have a two-way street that can be very beneficial to the business. It is also very helpful if the CEO clearly indicates that there's an expectation that the IT strategy be aligned with the business strategy. This tends to put teeth into the cooperation of both sides.

Q: In your book, you address a mutual perception gap: IT managers don't understand business strategy, and business managers don't understand technology. Which is the more serious problem?

RZ: Both are serious problems. One of the ideas behind the book was that by presenting this broad range of questions, we could give readers a summary of what the technology is about, as well as a summary of the business issues. And this would help people talk with each other.

DL: As to which is more serious, that depends on the company. Certain companies have very savvy businesspeople who understand how important IT is to leverage their competitive advantage, and they work hard with their IT counterparts to deliver that. The corollary is, in some companies, the IT people—particularly at the leadership level—may have a strong background on the business side in addition to their IT expertise. Therefore, they understand the business issues and come alongside the businesspeople as true partners. In other companies, they don't have a clue and are focused on the technology as an end unto itself. When the "no-clue" camp is in charge, you have that gap you refer to, and it's a serious problem. It usually leads to many IT projects being branded as failures.

Q: What can CIOs do to work more effectively with their business managers?

DL: IT people have to get to know the business, understand what the leverage points are, and understand what the business processes underneath that are. That's because everything is not just a technology-oriented solution. It could be a business-process solution that involves little or no technology. If CIOs understand the business well enough, they'll be able to help the business decide whether the use of technology is the best approach. In addition, CIOs need to help the businesspeople appreciate the complexity, difficulty, and cost of what they sometimes ask for. Business folks need to realize that the delivery of a technology solution doesn't happen overnight and that they'll have a role, certainly in terms of redesigning business processes, training, testing of the new systems, etc. It's the understanding that it's truly a two-way street that's important here. That issue—and that answer—probably hasn't changed in the last 10 years. But because people haven't learned that answer very well, we emphasize the point in the questions and answers presented in the book.

Q: You point out that one reason IT projects are so difficult is that they span four different disciplines: the technology itself, project management, financial systems, and strategy. Have people figured out how to get these very complex projects to work?

RZ: The broader the background that managers have in terms of the different areas—the technology, the strategy, the financial, and the organizational issues—the less likely they are to make mistakes in terms of making decisions that have implications, or ripple effects, for other areas.

DL: IT failures have been pretty well-documented over the last couple of years, and you could categorize them into a set of four to six areas for why the failures occurred. Those failure areas—soft spots or risks—are now starting to become known within professional IT management circles. Certainly they are known at the consulting firms. So there should be a strong trend toward the systematic elimination of those risks. The implementation section of our book lays out the risks and suggests practical ways to deal with those types of risks. Books like this and other literature and analysis that've been done in the past are all available to help minimize that situation. There really is no reason for rampant failure anymore.

Q: Who's your intended audience for this book? Technical managers? Business managers? Both?

DL: We think there's a market on both sides. On the business side, a lot of businesspeople aren't very familiar with the key issues that IT faces. They need to understand what the IT side deals with. They also need to understand how technology projects work within their companies and how that links to strategy. Frequently, that isn't done very well.

On the technology side, folks in the technology area will be very familiar with the tech side of the book, but they won't be familiar with the other critical issues that will help them understand their business clients—things like the linkage to strategy, how to get business cases approved, the impact on the organization, and the company's culture. The book is designed for both sides, so hopefully they will understand each other's issues and in that way help make IT more successful.

Q: To put the book together, you assembled more than 60 contributors. Why not just write the book yourselves?

RZ: There are relatively few people who know the answers to all the questions. People like Dave, who have served as CIOs in larger companies, probably do, but almost everybody else doesn't. We also wanted to tap into the deep expertise that's available in the [Colorado] business community, and we thought it would be a good way to create linkage between the business community and the business school.

DL: What we didn't realize is that editing it was just about as much work.

Q: For your 100 critical questions about IT, how did you decide what to include?

DL: The concept for the book started when I looked at the graduate class in technology management at the business school of the University of Colorado at Denver. Ray was teaching the class at the time, and I looked at it from the viewpoint of asking: What kind of individual or graduate would I want to hire into my organization? And, does this class give them what they need to know for me to want to hire them? Although the class was good in many areas, it didn't cover enough of the subjects that I thought were really important. So I came up with the idea of the 100 questions that everyone needs to know about IT. We designed a course around the 100 questions, but realized that, not only was there no textbook for the course, but such a book would have broad application for people in the business community.

RZ: We took an original, shorter list of questions to a lot of people—both university faculty and people in the business community. They looked at the list and added questions they felt needed to be talked about. So we found it pretty easy to come up with the 100 questions. The uniform reaction was, "If you ever get the answers to all these questions, I want a copy." That was part of the genesis of the book.

Q: Your questions were answered by people in the industry, including individuals at EDS, Oracle, and PricewaterhouseCoopers. How did you select them?

DL: It was a combination of various individuals' networks. With my background, I had a large network of people in the IT community; the dean of the business school has a large network of people; and individuals on our editorial committee are also well-connected within the IT community. For the most part, we knew all the people who participated. We knew what their expertise was and how they could contribute. We also knew them well enough to ask them to do this work and donate it to the University of Colorado at Denver's business school. All of the royalties from the book have been donated by all the authors and editors to the school. That makes the book a truly unique animal. I don't think so many people have ever been so generous with their time and intellectual property.

Q: Speaking of the university, what's your take on the next generation of business managers? Are they much savvier about IT than previous generations or do you see the same old misunderstandings?

RZ: The problem is that business schools have treated IT as a functional area. For students to use IT effectively in companies when they become managers, they need to understand the systemic role that IT plays throughout the entire business organization. That means IT's linkage with finance, strategy, and all the other areas. There's going to be a change in business schools over the next few years. They'll try to make IT a more systematic, broad-based area for students to learn about.

DL: We're actually seeing a big shift in the focus of business schools and their treatment of technology. In the past, there was a required class in IT, but it was primarily a class in what I'll call the nuts and bolts of technology: hardware, software, architecture, security, and the like. What was missing from the most recent generation of educational focus was the concept of managing IT. Business schools are now migrating to that quite rapidly. We think our book is clearly right in the center of that migration because of its focus on the management of IT and how to make IT work in an organization.

But I don't think you want to write off the previous generation of graduates. Unfortunately, a lot of them have had to learn on the job, which is painful at times. It's also one of the reasons there are so many failures in the IT world. That's why we think this book is so appropriate at this time.