IT GOVERNANCE -ITIL Power

When Mead and Westvaco—the country’s two largest forest products and packaging companies at the time—merged in early 2002, Jim McGrane, then the vice president of process development at Mead, was promoted to CIO and assigned the unenviable task of standardizing the new entity—$7.2 billion MeadWestvaco—on a single SAP system. McGrane had started redesigning Mead’s order management and financial processes four years earlier, so it was natural this new job would fall to him. But something about the project didn’t sit right. Even though he was standardizing the processes the business would follow and providing users with a system that would enforce these new, more efficient processes, his own department was continuing to operate the same way it always had, following what was basically a collection of ad hoc practices. “There was no focus on process for IT,” says McGrane. The contradiction was obvious: The group responsible for developing and enforcing a set of common business processes didn’t have a process of its own. Consequently, the IT department wouldn’t be able to hold itself to the same standards it was applying to the rest of the organization.

McGrane and his senior staff spent the better part of 2002 coming to grips with this disconnect by developing a vision for the future of the IT department and figuring out what core processes it needed to get there. McGrane wanted a lean department, one that could anticipate and solve problems before they happened and adapt to changes in the business as quickly as the business itself changed. The team started with the governance frameworks available but invariably hit a wall. “We would look at stuff from Gartner and IBM and other places, but it was never at the level of something you could implement,” McGrane says. “They would give you a description like ’availability management.’ But [they] never really said what these terms were.”

Then one of McGrane’s staffers discovered the Information Technology Infrastructure Library (ITIL), a collection of best practices for IT operations first developed by the British government 20 years ago. It differed from the other process frameworks they had found: It was high-level but had enough detail to make the meaning of each term clear and show how it could be applied to an organization. Intrigued, McGrane bought 10 copies (ITIL is available only as a set of books or CD-ROMs) and he and his team read them over the December holidays. At the end of the first quarter of 2003, McGrane formalized a plan to rebuild his IT department using the ITIL framework. Although MeadWestvaco’s transformation is still ongoing, to date the company has eliminated more than $100,000 annually in IT maintenance contracts and recognized a 10 percent gain in operational stability. McGrane credits these gains and savings to ITIL.

A confluence of circumstances, including the need to demonstrate IT’s contributions to the company in an era of outsourcing and the increased financial oversight mandated by the Sarbanes-Oxley Act, is leading CIOs to look harder at process frameworks for running IT. Frameworks help bring consistency, an ability to measure performance and some much-needed scientific rigor to a field that, despite the term “computer science,” historically has thought of itself as an art. Some of the more popular frameworks include the Capability Maturity Model (better known as CMM), Six Sigma and Control Objectives for Information and Related Technology (Cobit).# Each has a particular area of emphasis (see “The Power of Processes,” for a comparison of the different frameworks).

What sets ITIL apart is its strict focus on IT operations. When used properly, ITIL helps IT departments improve their quality of service, including increased system uptime, faster problem resolution and better security. ITIL has long been popular in Europe, and now it is gaining steam in the United States. At its 2004 data center conference, Gartner polled 164 attendees, most of whom were from large companies based in the United States, and found that their awareness of and familiarity with ITIL had both increased from the previous year, and that 41 percent reported using the methodology to some degree, up from 31 percent in 2003.

But putting ITIL in place isn’t easy. McGrane says the process change is so substantial that CIOs should treat an ITIL project the same way they would treat an ERP implementation, measuring progress in years, not months. Also, CIOs expecting easy answers will be disappointed: ITIL doesn’t offer any advice on how to actually implement the best practices it catalogs, a lacuna that can be shocking to CIOs used to highly detailed software development methodologies. Perhaps for that reason a recent Forrester Research survey of CIOs at 65 large global companies found that, despite widespread interest in ITIL, only three percent were using it as their primary methodology. “It’s in many more organizations [than three percent], maybe at the help desk,” says Bobby Cameron, vice president of Forrester’s CIO group, “but that doesn’t mean that there is organizational acceptance or that it is part of an overall strategy.”

For many companies, however, ITIL will soon become much more evident. Both the U.S. and Canadian governments will soon require IT contractors to use ITIL, as will General Motors. And the potential benefits of ITIL—including staggering improvements in customer satisfaction and operating efficiency—are so great that Forrester has concluded that it is just a matter of time until ITIL becomes the de facto standard for all IT shops. “ITIL is absolutely the best framework available for IT operation,” says Cameron. “There are no competitors.”

“[With ITIL] we now have the ability to assess how we are performing at any point in time,” says Suresh Kumar, CIO of the brokerage firm Pershing. “As a result, we can continuously improve our processes. We’ve identified [where we had problem] bottlenecks, and now the total number of problems is going down. And we have evidence to show people that we are improving.”

ITIL at Work

When someone at Pershing has an IT systems or hardware problem, he calls the service desk and is directed to one of four specialty areas: desktop, network, mainframe or distributed systems. Thanks to ITIL, which Pershing adopted in January 2004, the specialty staffer who answers the phone has a list of previous similar incidents and how they were fixed. If the issue has not been resolved after 10 minutes, a service desk menu automatically identifies and pages the appropriate subject matter expert. That person gets one hour; if the incident hasn’t been fixed by the end of the hour, the IT department’s senior management, including Kumar, get involved via a conference call. After two hours, Kumar calls the business unit heads to discuss the incident’s implications and what action to take. Since the service desk was restructured according to ITIL guidelines 12 months ago, Pershing’s incident response time has dropped by 50 percent. Additionally, since incidents are tracked and managed every time they recur, it’s easy for IT staff to spot trends and eliminate many previously chronic problems by performing a root-cause analysis. Similar processes for making system changes and installing new releases prevent many system conflicts from ever happening in the first place.

This is ITIL in a nutshell. Because IT processes are designed to flow together, the value of each set of guidelines is increased. “A company may have an outstanding network or mainframe group,” says McGrane. “But if each group is focused on optimizing the value of its area, they may not be creating value for the organization as a whole.” ITIL provides the language and processes to coordinate all of an IT department’s efforts, allowing it to function like a world-class orchestra.

ITIL was first developed in the late 1980s by the Central Computer and Telecommunications Agency, a now-defunct branch of the British government, as a catalog of best practices for government IT departments. Its use soon spread to the United Kingdom’s private sector, then to European companies, and over the past several years it has made its way to the United States. Now in its second version, ITIL comprises seven books, each of which is about 200 pages long and costs around $115. Each volume is devoted to a single practice area: service support, service delivery, planning to implement service management, security management, ICT (information and communications technology) infrastructure management, application management and the business perspective (see “ITIL in Brief”).

To date, the majority of U.S. companies adopting ITIL have undertaken only two of its practice areas, service support and some corresponding practices in service delivery. (ITIL newcomers be warned: Many U.S. CIOs and consultants will use the term ITIL to refer to just service support.) Because service support is the easiest area for many IT organizations to improve, most CIOs and ITIL experts suggest it as a starting point.

There are five processes within the service support book (some people refer to these processes as books also, but that is technically inaccurate), each of which complements the others. These service-support processes are incident management, problem management, change management, configuration management and release management. These processes are intended to help companies gain control of the incident lifecycle—that is, the time from when an incident first develops up until a system change or a new release permanently fixes it—says Brian Johnson, a member of the original ITIL development team who is now ITIL worldwide practice manager for Computer Associates. Gaining control of the incident lifecycle should ultimately translate to improved service levels, he says.

That was the attraction of ITIL for Jim Strande, vice president of software engineering for the College Board, the organization that administers standardized tests such as the SAT. He didn’t have a formal service-level agreement with the business for IT operations, but it was clear that he wasn’t meeting its expectations about maintenance of the company’s website. Even though Strande’s IT department had achieved 99.9 percent uptime, that still left around nine hours a year when the site was down. Almost always, these interruptions occurred during the 40 or 50 days when the College Board either registers test takers or reports scores—the time the business most needed the site to be up.

Strande turned to ITIL to assess his department’s operations. The review helped him understand that the IT group did not sufficiently track the causes of incidents. In ITIL lingo, they didn’t distinguish between incidents (nonstandard occurrences of any kind) and problems (underlying flaws in IT systems, often identified as a result of multiple incidents). As a result, problems with the website were left unresolved and incidents were recurring.

Using the methodology outlined in the ITIL service support book, Strande reorganized and clearly delineated the incident and problem-management functions within the operations group, training the staff to respond in specific ways to key events. For example, if the website loses its connection to its credit card processor, service desk staff now know the root cause and the correct response: The telecommunications switch between the College Board and the processor must be reset and the server that handles the transactions must be recycled. Overall, there have been fewer recurring problems, Strande says, leading to improved service levels.

When the IT department at Pershing can’t solve a problem after two hours, CIO Kumar has to call the company’s top executives—even if the time limit happens in the middle of the night. “It can be very uncomfortable calling the CEO at 2 a.m.,” he says. Yet he’s done it several times. Recently, a settlement clearinghouse (an outside company that reconciles a day’s trades in overnight batches for brokerage firms) suffered a system crash. Pershing needs to complete approximately 12,000 batch jobs every night to update its books and records, prepare online systems for the next day, back up databases and files, receive and send electronic transmissions, and produce electronic and paper reports. Kumar arranged a middle-of-the-night conference call with about 30 executives, running the gamut from legal issues to manual workload processing requirements, to decide on the best course of action.

“If we have 9,000 [updates] that won’t get run, it is difficult to understand all the implications,” says Kumar. “Usually no one person has the answers, so we try to have a good representation.” In this case, the consensus was to have managers come in early, assess the workload and staff their areas accordingly, while the IT department looked for a solution to work around the problem and support the business areas by generating additional reports. “I have found that people are never upset” when he calls in the middle of the night, says Kumar. “They understand that there is a problem and that we have to fix it.”

The Heart of the Matter

The ITIL service support book provides organizations with processes for tracking incidents, identifying problems and making changes to solve them, but ultimately people must follow the processes. The best way to ensure this happens is to give IT staffers a system that does it for them.

Meet the configuration management database (CMDB), the technical underpinning of all ITIL projects.

“The CMDB is the core of ITIL,” says Christine Rose, director of global IT at Finisar, a computer hardware manufacturer that adopted ITIL in 2002. “It allows you to track your assets and gives you a running history of everything that you have done.” The CMDB is essentially a map of every piece of technology a company owns—systems, routers, servers, PCs and so on—as well as a catalog of every change made to each asset, the incidents linked to the asset, and the asset’s relationship to the larger technology environment.

For example, Rose ran a report against the CMDB that found Finisar’s FTP server was responsible for several recent incidents. This server was used to provide technical support to end users, and heavy usage was overwhelming its hard drive. Rose was able to solve the problem by simply adding more storage space. “If we did not have a history of the server, we would not have noticed the trend, since the business didn’t convey its needs to IT,” she says.

Most of the CMDB products commercially available now have incident-, problem- and change-tracking built in, but even if they don’t, says McGrane, it is easy enough to link these processes together. MeadWestvaco’s original configuration management system was actually built by seniors at the University of Dayton as part of a school project. “We didn’t realize how critical [the CMDB] was at first,” says McGrane. (The company has subsequently bought a configuration management product from BMC Software.)

A CMDB can help with what-if planning to find out if a proposed change could have unintended consequences on any other systems in the environment. ITIL’s change management methodology also requires alerting business users 72 hours before a major change is made. That way the finance department, for instance, can request a delay to an ERP change if it needs the system up to close the books. “There are a lot of things that the business does that IT just doesn’t know about,” says Rose. “This allows us to align ourselves with the business instead of just making them angry when something they need isn’t available.”

What ITIL Can’t Do

The biggest fault that users find with ITIL is that while it contains best practices for IT management, it is essentially just a list of things companies should be able to do. “You don’t implement ITIL,” says Johnson, the member of the original ITIL team. “You use it to help create organizational change.” Translation: ITIL doesn’t offer guidance on how to actually apply the best practices it catalogs; each organization must design its own processes based on ITIL principles.

“Since ITIL is only a framework, it puts you in a situation where you need to rely on somebody to fill in the gaps,” says Strande. The College Board hired consultants from Noblestar and Booz Allen Hamilton to help with its ITIL implementation.

This situation might not be accidental. While the original version of ITIL published in the 1980s was written by British government workers, all of the current version was written by consultants or vendors—the same people whose livelihood depends on companies needing help to implement the practices described.

“People need to have an ulterior motive for producing the material,” concedes Aidan Lawes, CEO of the IT Service Management Forum (ITSMF), the organization with day-to-day oversight of ITIL (the British government still owns the ITIL trademark, but for all practical purposes, the ITSMF manages ITIL). Lawes is trying to come up with a way of compensating authors before the next version of ITIL is published in about 18 months, in hopes of widening the pool of contributors.

Neither McGrane nor Rose hired consultants, but they admit that the trade-off is dedicating time and staff resources to building up ITIL expertise in-house. At MeadWestvaco, that meant a year of informal training, delaying the IT department’s reorganization until the third quarter of 2004.

And that is just the start, quite literally. Designing new processes may only take months, but the amount of change required can be so substantial that most IT organizations will need several years to implement them. MeadWestvaco, which is currently using only the service support and service delivery books, won’t launch some ITIL processes until the end of 2005—nearly two years after beginning with the framework. Even after the launch, McGrane advises, “it will be 18 to 24 months from the time you introduce it to the time you actually start seeing adoption of it as the way you do business.” Tom Thompson, MeadWestvaco’s director of process transformation, is more candid. “You could probably do it in four months but you would have a bunch of dead bodies,” he says.

Another drawback: Old habits are hard to break. Rose says that she had to give her entire IT staff new cell phone numbers to prevent users from bypassing the service desk and calling staff directly. Also, most CIOs say that layoffs are inevitable because some IT people just can’t adapt to the new processes. (Strande, on the other hand, hired several staffers after his ITIL project revealed gaps in how his IT department handled service-level and problem management.

But for many CIOs, the pain of ITIL is worth it. Since Finisar’s service desk was standardized, customer satisfaction rates have risen from 33 percent to 95 percent. And Rose has cut the amount Finisar spends on IT from 4 percent of revenue to 2.4 percent.

“To run IT like a business, you need to understand the key services that go into it,” says McGrane. “ITIL makes that work visible. It allows you to measure what is important, so you can emphasize the things that add value and take out the things that don’t.”

Senior Writer Ben Worthen (bworthen@cio.com) writes about business process in IT.