How do you get more value out of IT, if not your CIO? How can technology teams make the strategic value of IT real for executives? George Westerman, a research scientist at the Center for Information Systems Research at MIT's Sloan School of Management, says it mostly boils down to one key concept: business agility. However, reliable and sustainable agility depends on a set of essential IT capabilities, ranging from on-going delivery of basic IT services, to accountability for IT. In fact, his book, IT Risk, Turning Business Threats into Competitive Advantage (co-authored with Richard Hunter),Westerman provides some rigorous research-driven advice and tools for treating IT risk as business risk in order to achieving strategic advantage.

Enterpriseleadership.org recently sat down with Westerman to discuss the research findings in his book, and the ways CIO can manage risk to improve their business agility. Here's what he had to say:

EL: What types of agility does an organization need in order to respond to different types of change?

GW: In the book, we define agility as the ability to change with managed cost and speed. That doesn’t mean being infinitely responsive. You need to understand what types of agility you are most likely to need. Are you integrating new acquisitions or launching new products? Are you changing business processes or reacting to unexpected daily events? Some of my other research shows that the ability to change business processes is the most commonly needed type of agility. That’s not the sexy kind of agility to launch new products or enter new markets, but it does appear to be what many organizations need most.

A well-structured, well-managed foundation of IT assets that is only as complex as necessary can better enable IT agility. But even then, organizations can have a tough time managing different types of agility at the same time. And, although IT is essential to some forms of agility, it's not the only element. Agility also requires the right kinds of people, empowered and able to make decisions. And it also requires leadership to manage organizational changes.

The mix of organizational, leadership, and technological requirement varies for different types of agility. It’s also important to understand that, just as different parts of a company may need different types of systems and processes, they also may need different types of agility.

EL: What changes have you seen in IT to make companies more agile?

GW: Our research shows that agility for IT comes from a couple of elements. You need first to get to the point where you have a very solid, well defined, and a well understood platform of technologies, business processes, and knowledge. If the platform is very well structured and very well understood, then you know where you need to make each change, and you can do it. When you make a change, you make it in one place and in one way, as opposed to all over the place like firms must with legacy spaghetti. And you know the links to business process and organizational elements so you can help your colleagues change those too. The well-structured, well-managed IT foundation forms the basis for many types of agility you need to get done.

EL: Can elaborate on the qualities of a well-managed IT foundation?

GW: So, one of IT’s key jobs is to make this foundation happen. Some firms with very well-structured foundations, such as TD Banknorth that can acquire new banks very rapidly and can expand services in a straightforward way. That's a great way to start. But most firms don't have that well-structured foundation. They need to gradually transition from their existing complexity into a more rationally-defined foundation. Firms in this situation improve agility gradually by helping people understand that each new change they want to make has to be part of a larger goal. Each change has to help move your platform strategy forward as opposed to taking you away from it. Governance processes that help everyone understand how to move the foundation in the right direction can help you gradually improve agility from IT.

Building on a solid foundation, governance, relationships, and project delivery processes must be improved to increase agility. Governance processes cannot become so bogged down in bureaucracy that they restrict speed. But they also cannot be so loose that they allow the foundation to become more complex. Project delivery processes must include the necessary controls to manage risk, but also must be agile enough to respond rapidly to changes in the business. And relationships must be strong enough to not only think about the future but also to have the tough conversations.

EL: Before you can get to agility, you need to think of risk. How do you define risk?

GW: Most people, when asked about IT risk management, think only about avoiding the downside or negative consequences of IT. To these people, IT risk falls into two categories: business continuity and security. What happens if our systems go down? What happens if a hacker gets into our system and causes havoc, or if somebody sells confidential data about our customers or products? But there’s more to IT risk.

Risk management can have an upside. If you want to take a risk, you can gain a tremendous return on it. You have to be willing to manage the downside, but you shouldn’t avoid risks because they have a potential downside. Many innovators and investors think about risk this way. But people don't often think about that for IT. And they should.

Our research shows, although risk is part of every major IT decision, decision makers need to think about IT risk more broadly than they typically do. IT risk is not just technical risk. Today, technology underpins all of our processes. Many of our decisions can affect business risk. And, managing risk not only avoids loss of value, but can also increase value available from IT.

EL: Can you describe the four elements of IT risk mentioned in your book?

GW: Availability refers to how can you keep the processes running and what happens if we don't. Access determines if you can provide information to the right people and not to the wrong people. These two risks fall clearly into most peoples’ preconceptions about IT risk. But there are two more that are equally important, though less-often considered when thinking about IT risk.

Accuracy refers to whether the business is getting accurate, timely, and complete information, and the negative consequences if it doesn’t. In the wake of Sarbanes Oxley, managers are paying attention to accuracy of financial information. But accuracy risk goes well beyond financials. Accuracy can also be the single view of your supply chain, or your customer, or your global view of what the organization might need to make decisions. Some inaccuracies, such as inventory record inaccuracy, create insidious problems that often fly below the radar. Others, such as inaccurate information on prescriptions or medical tests, can be life-threatening.

The last element is agility. People rarely think of agility as being a risk for IT, except it is -- all of the time. But, when people are resigned to delays and inflexibility from IT, they don’t always think of these issues as something they can manage; an option they can trade off against other options.

EL: Can you give an example of a company that could move fast enough to carry out a strategic opportunity?

GW: We studied Textronix, a prime example of this. In the late 1990s, Tektronix couldn't divest a division because its systems were too intertwined. To do so, Textronix would've needed to give a copy of all of its systems to the buyer of that division. Textronix spent three years and many millions of dollars untangling its systems. The transformation not only enabled it to divest and acquire businesses more easily, but also improved its global management visibility and customer responsiveness.

Insidious agility and accuracy risks can slow down the way you act. You figure IT isn't going to get things done fast enough, or you can't count on IT to deliver. As a result, business executives build shadow systems or they find other ways around the core IT group. And that adds complexity that increases all four IT risks.

EL: Which of the four risks is most important?

GW: All are important. But at a given time, for a given firm, one is usually more important than the others. For example, some financial services firms are considered "national financial infrastructure critical", meaning that, if their processes fail, markets fail. Availability is a critical risk for them. But, once they have the right availability safeguards in place, they can focus on other risks.

We find that people often focus most on the most visible IT risks: availability and access, and don’t always focus on accuracy and agility. But, accuracy and agility often are the most damaging to the firm in terms of financial impact. It’s just that the impacts are not as apparent as they are, for example, in a major outage.

EL: You write that the CIO often gets stuck carrying the burden of IT risk.

GW: Much of the cause of IT risk in the organization does not stem from mismanagement. Of course, some firms just don’t manage their IT operations very well. That's a problem. But, much of IT risk occurs because of complexity. That often arises from IT continually trying to meet today’s business needs without being able to impose the kinds of standards and strategic viewpoint that can lead to the well-structured foundation we discussed earlier. You wind up with the kind of legacy spaghetti that many managers have experienced in their firms. Complexity makes it difficult to manage for availability. It's tough to grant and control access. It's difficult to get accurate information when you are linking all of these disparate systems. And it’s just not very agile.

Business folks tend to delegate IT risk to IT folks because it contains two very naughty words -- one is IT and the other is risk. Many business executives don’t feel comfortable discussing IT – they just don't feel they understand it enough to have conversations about it. And, of course, very few people enjoy talking about risk.

As a result, business executives delegate IT risk management to the CIO. But, the CIO is not equipped to manage all of the elements of IT risk. He or she can manage infrastructure-related risks – a big component of availability and access risks -- but cannot even do those alone. The CIO cannot make changes that affect business process without business involvement. And, without business involvement, CIOs cannot put the policies and decision frameworks in place to prevent risk from increasing in the future.

EL: Isn't it the CIO's job to know how to speak to the business units?

GW: They should be able to. And many good IT executives can – both at the CIO level and lower in the organization. But even they can improve their conversations by discussing risk systematically.

Many discussions and debates between IT and business are really about differing views of risk. What is the tradeoff between having something that is more bulletproof versus something that is more flexible? Do you want to make something so easy to access that we can’t secure it properly? Do we need to meet our big deadline at all costs, or can we delay the deadline so we can do things a little bit better?

We have found that non-IT executives are comfortable using these four A's to have conversations about risk. They've done been able to do this before. They can quantify the importance of how to get better availability and what it's worth to them. They can quantify the cost of missing a major strategic change and what they are willing to do on that. They know how to talk in these terms. Now they have conversations about what risk tolerance and what are tradeoffs on the four A's. They no longer hand off risk to the CIO. Talking in terms of the four A’s allows you to make the decisions you can make, and gives IT people the information they need to do what they’re best at.

--

Additional Reading - Sponsor Link:
Managing the Business of IT: Maximizing the Power of Service Resource Planning, the Next Step in Business Service Management

Elizabeth M. Ferrarini - She is a technology writer from Boston, MA. Reach her at elizabethferrarini@yahoo.com

If you ask a global CIO like Gary Cantrell of Textron to name you one of his goals for 2008, he'll tell you he wants his IT organization to become more agile. No one knows more about what Cantrell is trying to do than Michael Hugos.  Up until 2006, Hugos was the corporate CIO at Network Services Company, an $8 billion cooperative distributor of janitorial products and disposable food services items. He received a CIO magazine 100 Award in both 2003 and 2005 for improving the agility of Network Services' supply chain initiatives. He also received an InformationWeek 500 award in 2005 for innovative use of an IT wholesale distribution system.

Hugos now sports the titles of business agility mentor and CIO-at-large to several companies. He also writes books about supply chain management and business agility. The second edition of Essentials of Supply Chain has become the top selling book in its class on amazon.com. He recently published The Great Innovation Since the Assembly Line -- Powerful Strategies for Business Agility. In addition to writing books, Hugos often writes about agility in his Computerworld column and on his CIO magazine blog. He also conducts workshops on what he calls the 30-Day Blitz to becoming agile.

enterpriseleadership.org recently sat down with Michael Hugos to get a better understanding of business agility and IT agility.  Here's what he had to say:

EL: What exactly is agility and why what does it  offer an organization?

MH: Agility applies to a wider range of activities. Just as lean manufacturing advocates using easily reconfigured machines in flexible production sequences, agile methods advise the use of short and iterative development cycles for rapid response to changing conditions and customer demands. Agility also places a greater focus on customer satisfaction rather than internal operating efficiency.

EL: Can you explain what it  means for an organization to be lean and what is the relationship between lean  and agile?

MH: Lean grew out of the popular manufacturing principles in the Toyota Production System and Just-in-Time manufacturing process. It emphasizes two things: the elimination of non-value added activities that customers don’t pay you for, and the elimination of wait times where products or work in progress accumulates and waits. These ideas relate mostly to manufacturing or supply chain processes. However, lean also advocates ideas that overlap a lot with agility. For example, a rapid response to changing customer demands can occur through using appropriately sized and easily reconfigured machines, and placing those machines in flexible production sequences that can change quickly as situations change. These are very much agile ideas. 

EL: Apparently,  supply chain experts have merged lean and agility to create leagility.  What's  the story behind this term?

MH: Leagility applies mostly to the operations of lean and agile supply chains. We can discuss these concepts well enough with the words lean and agile. By making up a new word like leagility, you create more confusion in the discussion.

EL: What are some  of the characteristics of companies that are either agile or lean and agile?

MH: Lean and agile companies display a handful of key characteristics. The most important characteristics include decentralized decision making procedures, and individuals and autonomous operating units that are empowered to decide and to act on their own initiative. At lean and agile companies, senior management makes the goals clear to everyone, and trains and trusts employee to do the right things to accomplish those goals.

These characteristics have become necessary for agility. Why! We live in a world where things change quickly. People at the scene of the action need to assess events and act quickly in order to be agile. If they're required to pass information up the chain of command and wait for orders before they can act, they won't respond effectively because situations will change while they are waiting for orders. Opportunities will disappear. People will become frustrated and passive. This scenario creates the inertia and lethargic behavior that bureaucracies are so famous for.

EL: Can you provide  an example of an organization that has done a super job of becoming both lean  and agile?

MH: The United States Marine has done a good job of becoming both a lean and an agile organization. Its basic tactical unit consists of the 20 to 40 person autonomous platoon. Specific platoons of infantry, artillery, and armor become task forces to handle specific assignments. The commander issues mission orders which spell out what the platoon must do to accomplish its assignment. The senior commander doesn't tell people how to do their jobs. People closest to the scene have been trained and are trusted to figure out how to do what the commander wants, without asking permission before they act.

I'll admit business isn't war. Business creates opportunities; war destroys. You can learn many lessons for business by analyzing successful military operations. I've learned a lot about agility from reading U.S. Marine Corps' 110-page book called Warfighting. Everyone from the Commandant of the Marines to the newest recruit has to read and live by this book.

EL: When it comes to  agility, what company has a lot in common with the U.S. Marine  Corps?

MH: Both Whole Foods Market and the US Marines -- two very successful organizations -- use very similar operating models. They both consist of small, autonomous operating units, empowered to act on their own initiative. Senior management in both organizations says what they want but does not micromanage. Instead, they train and trust their people to figure out how to do their jobs. These two organizations come from very different lines of business and very different world philosophies.  Because they have both independently arrived at similar operating models, you can easily conclude that there some universal truths about agility and the way effective agile organizations operate.

EL: What are some of  the hurdles an IT organization has to overcome if it wants to improve its  agility?

MH: It needs to overcome three big interconnected and self-reinforcing hurdles, which are tough to break down. These hurdles include the tendency to use bureaucratic organization structures and operating procedures; the tendency to engage in long development cycles that last between 18 to -36 months, and the tendency to design and build very complex systems.

For centuries, people have used the bureaucratic operating model. Most companies today use this model, not just IT departments. Bureaucracies work well in situations which don't change that much. They can handle lots of details and complexity, and produce predictable results. Problems arise when we try to use the bureaucratic operating model to deal with situations that change all the time. The rapid pace of change can easily overwhelm these bureaucracies. They react by trying to slow things down. They become even more rigid and intransigent. IT and business must cope with rapid change. The rigid bureaucratic behavior of many IT groups really drives business people nuts. IT needs to adopt a decentralized and flexible operating model.

EL: What are some of the  programs with long system development?

MH: Traditionally people have the tendency to engage in long system development. Long development cycles work when things don’t change much, but they don’t work well in high change environments. The bureaucratic process don't respond very well to change, especially for the waterfall approach of collecting requirements, creating system specifications and then implementing the system. People first spend three to six months analyzing situations and collecting requirements. They next spend another 12 to 24 months developing systems or selecting and implementing packaged solutions.

During this time, significant changes will occur, and business people will want to come back and alter the system requirements to reflect the changes. This process starts up a whole dysfunctional cycle of behavior where bureaucratic IT project organizations resist the change requests, business people resent being put off, and nobody is happy. Because business people have a lot of political power and influence, IT usually gets the blame for whatever happens. IT needs to be able to get things done in shorter periods to respond well to change.

EL: So how do you deal  with the complexity hurdle?

MH: Because we organize ourselves in hierarchical bureaucracies, we then use bureaucratic procedures to do analysis and requirements gathering. We spend months analyzing things. And the more we analyze things, the more complexity we find, the more complexity we build into the specifications for the system we're developing. We become overwhelmed and intimidated by the apparent complexity. We attempt to design systems that can handle every eventuality, no matter how rarely it may occur. This practice leads to specifications for a very complex system, which you can't build on time or on budget. We need to work in shorter development cycles and deliver working systems that address the most pressing problems first, instead of trying to solve all problems at the same time.

EL: You say that an agile  organization is one with a network organization. Can you briefly explain?

MH: Agile organizations have a network organizational structure. It provides the best way for autonomous operating units to act quickly on their own initiative, to coordinate their activities with each other, and to deliver benefits for the entire organization. Network organization structures can make best use of an agile operating dynamic.

Traditional pyramid shaped hierarchies just move too slowly. They restrict decision making to those at the top of the pyramid. Since those people are several levels removed from the action, it takes them a while to analyze the reports they get and understand what is happening and then issue their orders. Merely putting in expensive business intelligence and reporting systems does not shorten the decision cycle enough or make the decisions that are made much more effective. Since the people who have to carry out the decisions where not involved in making them, people often make a half-hearted attempt to carry them out. To counter this tendency senior management often indulges in micromanagement of lower levels which only reinforces the dynamic because people have no initiative to think for themselves and are reduced to merely following orders.

EL: Many CIOs use metrics from scorecards, such as the Balanced Scorecard, to evaluate the effectiveness of IT process. What criteria (such as number of projects done on time, or number of projects done on budget) does an agile IT organization measure?

MH: As CIO at Network Services Company, I developed a suite of e-business and supply chain systems that we developed and iteratively enhanced for several years. The project office produced a simple set of weekly reports and scorecards that enabled me, as well as everyone else in the company, to track progress on projects and our performance against budgets. I needed to know how projects were doing as they progressed. I needed to see early on if problems had developed so I could get involved when necessary. Reporting should enable effective intervention and mid-course correction, not just keep score.  You shouldn't measure things, such as the number of projects done on budget, if they don't have any value to the business people who use the systems.

Author: Elizabeth M. Ferrarini - She is a technology writer  from Boston, Massachusetts. Reach her at elizabethferrarini@yahoo.com.