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.