Can ITIL Do It All? Uh, No

Posted by Ann All

A few weeks ago, I spoke with Sheila Upton, a member of the Innovation Value Institute, about the institute's new IT Capability Maturity Framework, a five-stage maturity model used to organize and structure a framework for mapping IT improvement efforts. One of my questions to Upton: Why, with existing frameworks like the IT Infrastructure Library (ITIL), did CIOs need another one? Upton told me that members of the institute believed there was a gap in what existing frameworks did and what IT organizations, especially CIOs, needed.

I gleaned some similar insights from sources whom I interviewed for my recent story on ITIL. For instance, Bob Mathers, a principal consultant for Compass Management Consulting, told me it's not uncommon for organizations to integrate ITIL with other improvement frameworks such as COBIT (Control Objectives for Information and Related Technology). "That came out of their realization that ITIL wasn't necessarily going to solve everything they thought it might solve," Mathers said.

After putting in some of ITIL's core processes, some organizations "stepped back and realized they needed to be more realistic about the benefits any process framework can give them," he said. "ITIL may work quite well for some areas but be lacking in others."

Bad news, guys and girls. There is no magic formula for solving all of your IT ills. ( I feel a little like a jerk telling Virginia there is no Santa Claus.)

Version 3 of ITIL, introduced in 2007, attempts to address some of the perceived shortcomings of earlier versions of ITIL, said Mathers. But some organizations simply adopted aspects of COBIT or other frameworks to create a kind of hybrid framework. ITIL is most often the "foundation" for these hybrid frameworks, he said.

IDC analyst Fred Broussard, who wrote an HP-sponsored white paper on IT service management needs and adoption trends, told me ITIL adoption levels were higher in organizations using other types of process improvement frameworks such as COBIT or Six Sigma. That's likely because it's easier to "sell" ITIL to senior management at organizations already on board with the idea of structured process improvement, Broussard said.

Predisposition to improvement frameworks also may help explain why ITIL is most popular with large enterprises, which are more likely than their smaller counterparts to use other frameworks, said Matt Schvimmer, head of products, IT Service Management and Project Portfolio Management, for HP Software & Solutions. "Large organizations are generally able to be more proactive and devote more time to process effectiveness work. As you go downmarket, you get more into survival mode and find yourself doing more firefighting," he said.

All of my story sources agreed on the inherent value of ITIL and other IT service management initiatives. For a contrarian view, I found some thoughts from Robert Lewis, author of "Keep the Joint Running: A Manifesto for 21st Century Information Technology" and six other books, included in an interesting CIOZone.com piece.

One of ITIL's key tenets is to treat internal business units and their employees as "customers" consuming IT services. That's a mistake, said Lewis, as it diverts IT's focus from "real, paying, external customers."

Simply responding to the needs of internal customers prevents IT from assuming a leadership role when it comes to identifying new technologies that can solve business problems. The better approach, said Lewis, is one of working together to achieve corporate goals.

I also unearthed a link to a two-year-old discussion I had Hydrasight Managing Director Michael Warrilow in which he made the point that, for most IT organizations, best practices should be viewed as an ideal rather than a realistic target. Why? He said:

... When it comes to IT operations, the aim is quite simply "to do more with less" — as the saying goes. Why? Because the generally accepted rule of thumb is that more than 70 percent of IT expenditure currently goes to "keeping the lights on." There should be no doubt in anyone’s mind that best practice will increase the cost of IT operations within the vast majority of organizations, and hence increase the risk of doing less with more.

Making ITIL Work

by Ann All

I recently wrote an article and a follow-up blog post based on discussions I had with several IT analysts and with IT professionals on the IT Infrastructure Library (ITIL). They offered lots of great advice on how to effectively implement ITIL, only some of which made it into the article. I'd like to recap some of the advice in the article and mention some of the suggestions that didn't make it. Hopefully other folks with ITIL experience will join the discussion and share some suggestions of their own.

• Start with realistic expectations. If you start out thinking ITIL will help you cut IT costs in half, you will be disappointed.
  
• Begin with a solid baseline, looking at unit costs, quality and productivity.
• Measure in granular enough detail so improvements can be tied directly to an ITIL process or tool.
• Concentrate on your most critical business processes. Ask users to help you determine which processes are the strongest candidates for improvement.
• Enlist a strong executive-level sponsor.
• Invest time in educating users about ITIL's benefits, preferably with diagrams showing how workflows can be streamlined.
• Reassure staff that their roles won't be automated out of existence. Rather, ITIL will allow them to apply their time and energy to more strategic issues. They shouldn't have to spend as much time firefighting, and firefighting will become less stressful for them, when necessary, if processes are better defined.
• Focus on achieving small, incremental wins, and the momentum will take care of itself.
• ITIL is an organizational effort and thus cannot be confined to IT.
• Training is important. Make sure users understand how to use ITIL tools and processes.
  
• Change management can get costly if and when users try to circumvent ITIL processes. With the CIO's blessing, send a weekly e-mail listing all of the 'emergency' changes made the prior week.
• Pick and choose the ITIL principles that will benefit your organization. You don't have to adopt them all.
• Promote posiitve results to create enthusiasm.

Scoreboard: Who are the highest rated leaders in the tech industry?

Who is the best judge of a tech leader’s performance? It’s not Wall Street analysts or the general public, it’s the people inside the company. Based on ratings from Glassdoor.com, see how the tech industry’s top leaders, from Steve Ballmer to Larry Ellison to Steve Jobs, are rated by the people who work for them.

——————————————————————————————————————————————————

When I looked up technology executives on Glassdoor.com to see how they were rated by their employees, I was surprised at how they naturally divided themselves into two groups. I picked 14 leaders and they ended up dividing evenly between seven rated 62% or higher and seven rated 48% or lower.

I had already planned on making 50% the natural dividing line (and it was), but it turned out that none of the leaders fell in the 49%-61% window. To me, that meant that tech industry employees were generally not ambivalent about their leaders. The leaders were either widely admired or couldn’t gain approval from even half of their employees.

Before we dive into the list, keep in mind that Glassdoor.com is not scientific, but it is statistically significant (because nearly all of these tech companies have over 100 responses). The data is based on anonymous feedback from employees, who self-select themselves to participate. Glassdoor’s methodology requires participants to go through a fairly rigorous submission process, and that naturally limits the amount of false submissions. However, because it is anonymous, there’s no verification process to determine that the participants are legitimate company employees.

Nevertheless, the information from Glassdoor is extremely interesting, and in most cases it is consistent with information I’ve read or heard from insiders at the companies mentioned.

In the lists of the highly-rated and poorly-rated tech leaders below, I’ve listed them from high to low based on their approval rating. I’ve linked the company names to the full company profiles on Glassdoor.com, where you can see the updated numbers and lots of additional comments from the employees who participated. And I’ve also included the ratings that employees gave to their respective companies, beyond just the leaders.

Highly-rated

Steve Jobs, Apple: Approval: 90%, Company Rating: 3.8

Eric Schmidt, Google: Approval: 88%, Company Rating: 4.0

John Chambers, Cisco: Approval: 78%, Company Rating: 3.6

Mark Benioff, Salesforce.com: Approval: 73%, Company Rating: 3.7

Jim Balsillie, RIM: Approval: 70%, Company Rating: 3.8

Larry Ellison, Oracle: Approval: 63%, Company Rating: 3.2

Paul Otellini, Intel: Approval: 62%, Company Rating: 3.5

Poorly-rated

Michael Dell, Dell: Approval: 48%, Company Rating: 3.0

Steve Ballmer, Microsoft: Approval: 44%, Company Rating: 3.7

Sam Palmisano, IBM: Approval: 42%, Company Rating: 3.2

Mark Hurd, Hewlett-Packard: Approval: 41%, Company Rating: 2.8

Ed Colligan, Palm: Approval: 36%, Company Rating: 3.2

Jonathan Schwartz, Sun Microsystems: Approval: 25%, Company Rating: 3.1

Greg Brown, Motorola: Approval: 10%, Company Rating: 2.6

Commentary

It’s not surprising that Steve Jobs (right) is at the top of the list. He and Apple have been on an amazing run over the past decade with the rise of the iPod and iTunes, the resurgence of the Mac, and of course, the launch of the iPhone. Plus, he is an almost cult-like leader who inspires–and requires–absolute loyalty.

It’s also not surprising that Eric Schmidt and John Chambers are so highly regarded, since their companies have been on multi-year hot streaks. These three top-rated CEOs have widely divergent leadership styles, which shows that successful leadership is not about methodology or personality type.

Conversely, on the poorly-rated list it’s not surprising to see it dominated by CEOs whose companies have been in a tailspin. Palm, Sun, and Motorola have all been stuck in reverse, even before the current economic downturn, so it’s not much of a shock to see their chief executives mired at the bottom of this list.

However, it is a little surprising to see Mark Hurd (right) from HP in the lower list. After all, HP has jumped to the number one spot in PC and server sales under Hurd’s watch and produced a series of strong financial results. Despite all that, Hurd has a low 41% approval rating and employees gave the company a 2.8 rating, the second worst on this list. Only Motorola is rated lower.

When you have a leader who drives top-tier results but still has a company morale problem, that person is often called a “scortched-earth” leader–someone who gets things done but burns everyone out in the process. That could be what’s going on with Hurd.

The other mild surprise is Microsoft’s Steve Ballmer, who only had a 44% approval rating among his troops. While Microsoft’s stock price has been stuck in neutral for years and the company’s reputation in the general public is mixed, during the past decade Microsoft continued to grow its revenue and its product lines and expand its workforce. Its employees even rated the company at 3.7–only Google, Apple, and RIM scored higher.

The biggest problem Ballmer (right) may face with Microsoft employees is that he’s not Bill Gates. While Ballmer has been the Microsoft CEO since 2000, he remained in the shadow of Gates until mid-2008 when Gates retired from his full-time role at the company. While Gates was a visionary, Ballmer is simply a businessman. They complimented each other well, but without Gates what is Ballmer’s vision for the company and the computing industry? It’s unclear. And that is likely the culprit for his lukewarm endorsement from the Microsoft rank and file.

Beyond Survival – Thriving on Innovation in a Down Economy

from Metastorm

Introduction

Not everyone is affected equally by economic crisis, but regardless all organizations are facing a wealth of challenges and unpredictability as a result of the dynamic market environment that lies ahead in 2009. The initial and logical reaction is to hunker down, cut costs, and just get through it – survival at the expense of anything else. However, recent research by Gartner Inc. analysts Betsy Burton and John Rizzo echoes the need to continue to move toward the future. In their October 2008 report entitled, IT Innovation Will Be Key to Turn Economic Crisis Into Opportunity, they state: “Innovation is crucial as we transition from short-term crisis management to recovery.¹”

As many organizations struggle to control costs, increase revenue, and maintain their competitive status, it is easy to look at the perceived cost of IT and business initiatives and cut, cut, cut. But to do so without an eye to the future blinds many organizations to the opportunities that do exist to selectively expand and enhance their ability to meet future challenges. It is critical for organizations to find the balance between controlling costs, spending smartly, and continuing to create opportunities for growth. Innovation may seem counterintuitive during lean economic times, but it is during these times when it is most important, as innovation not only generates opportunities for new revenue, but can also be a key to creating value and controlling costs. This is also the time when the competition is in survival mode, and you have an opportunity to leap ahead.

Innovation

Innovation – it is often cited as a top priority of senior management to expand markets, grow revenue, and increase the competitive edge; however, it often falls to the bottom of the priority list. During down economic times, the focus may change from growth and innovation to down-sizing and efficiency. But innovation and efficiency do not have to be mutually exclusive. Innovation leads to new ways of thinking which in turn can lead to controlling costs by creating more efficient ways to develop products, fostering creative ways to collaborate with outside resources, or improving business processes in ways that reduce spending while also improving performance and outcomes. While reducing costs, all of these examples can also lead to growth and set an organization up for accelerated success when the economy recovers. The secret is in knowing what to focus on, making the right decisions with the right information, and continuing to look forward.

It is important to understand the kinds of innovation that an organization may undertake in order to understand how it can be used as a growth engine that can reduce cost.

* Process – Organizations can innovate their business processes to find more efficient ways to do things, lower costs, increase productivity, speed time to market, or enhance customer service.
* Market – Organizations can innovate to engage in a new market with a new or existing product or service, leveraging existing assets to drive new revenue.
* Business Model – Organizations can look for new ways to engage with customers and partners that can enhance relationships, foster collaboration, and optimize the extended value chain with the least cost and disruption to existing infrastructure.

Those organizations that have successful and sustainable innovation activities also have a solid foundation that includes: an understanding of their strategy, core capabilities, and business processes; active engagement of the company's network of partners, customers, and suppliers; and adherence to an effective set of repeatable, effective business processes.

Today’s environment provides the perfect opportunity for organizations to look beyond cost cutting and instead look for ways to be both more efficient and more effective while capitalizing on select opportunities to grow the business and position for future success.

Refine Business and IT Strategies

Innovation is often spurred by trying to do something in a new or better way. Ford’s assembly line, the first iPod, and the Toyota production system are all examples of innovations that borrowed from processes or solutions that already worked. Each brought new revenue, new markets, and greater efficiency with limited risk and faster time to value. By looking at existing business strategies, organizations can take a fresh look at their goals, objectives, and the underlying people, processes and technology that support them to find ways to create efficiency and improve business performance to address today’s issues while preparing for tomorrow’s opportunities.

To do this, companies need to be able to “see” the whole of the enterprise, and its underlying infrastructure to understand how it works. A series of questions needs to be asked in order to expose the relationships across the business:

* What are the top organizational goals and objectives?
* How are these tied to business processes and metrics?
* What systems support these processes?
* What will be impacted if a change is made to any of these corporate assets?

The best tool to provide the answers to these questions and to model a complete understanding of the enterprise is Enterprise Architecture (EA).

Figure 1 – A view of relationships
Source: Metastorm

Using EA and Business Process Analysis (BPA) tools to model the strategies, people, goals, information and technology of the enterprise presents a picture of the business that can be refined, manipulated, and analyzed to create new ways of doing things – optimizing use of the resources you have today and identifying the resources you need to support future objectives.

EA and BPA tools allow the analysis of how well processes are supporting the business strategy and how well the strategy is meeting goals. A view of the relationships across people, technology and information is made very clear and is a means to refine models and simulate “what if” scenarios to gauge the impact of any change prior to implementation. The business is spared radical shifts until the right scenario is found, thus lowering risk and increasing the likelihood of success. New business strategies and goals can be assessed and virtually implemented to gain the understanding of the value an innovation will actually bring.

Look Ahead

Once strategies have been reviewed and refined, it is necessary to plan for the transition to move from where you are now to where you want to go. As organizations rebound from the challenges of the current economy, the ability to react quickly and smartly to take advantage of new opportunities will propel well-prepared organizations into a leadership position. Planning, innovating and optimizing the use of your existing resources now will allow stronger companies to quickly take advantage of new opportunities and prosper when the economy rebounds. Those that concentrate only on survival cost reduction will be forced into a maintenance and rebuilding effort that leaves them behind.

Looking at the state of your enterprise via models, roadmaps, application portfolios and impact analysis reports allows decisions to be made quickly and more accurately. These decisions may include a change in IT direction, retirement of legacy system, consolidation of data centers, the creation of an enterprise service from an existing capability, elimination of duplicate functions, streamlining of product lines, or simply analyzing the impact of ongoing change to the business. EA and BPA tools and disciplines provide the most complete view of the whole enterprise, which provides information needed to develop new sources of revenue and/or to cut and control costs.

This is also a good time to reassess how use of technology and IT services can be improved to create a flexible a platform that can accommodate or anticipate change while minimizing disruption to daily activity. As the recovery takes hold, there will be a need to comply with new regulations, develop new opportunities, and respond to new market pressures. Business Process Management (BPM) technology can be leveraged to develop a flexible platform that provides automation, visibility, audit ability, and the ability to quickly respond to changes in business strategy, goals, and objectives.

BPM technology is a quick way to automate and respond to internal and external change. The use of BPM software in conjunction with Business Process Analysis, allows an organization to model, simulate and execute a business process in a matter of days or weeks with minimal disruption to underlying infrastructure. When a process is changed in response to a regulatory requirement, a new strategy, or a competitive pressure, this change can be modeled, simulated and implemented quickly.

Control Costs but Prepare for Growth

Most organizations are looking for ways to control costs, do more with less, and minimize disruption caused by reduced budgets. In most organizations, it is the CIO who is asked to cut IT initiatives and spending. While cutting would seem to be a simple task in down times, it must be done with an eye toward future growth and innovation. CIOs should rely on their Enterprise Architects to provide the big picture needed to understand the short-term and long-term impacts of any cuts not only on IT, but also on the business. Using this big picture, Enterprise Architects understand how to simplify and streamline the IT environment and how to reduce system overhead while avoiding impact to current and future business opportunities.

Figure 2 – Portfolio view of IT projects
Source: Metastorm


Enterprise Architects have a view across the portfolio of business processes and the applications that drive them. These applications are instantiations of business processes. Using this view provides the means to rationalize processes, applications, and systems and reduce redundancy and cost. EA and BPA tools provide a means to analyze the impact of any proposed changes. While this is seen as cost control, innovation is also possible as there is the opportunity to create new ways of doing business or new ways of using existing assets that will reduce cost, increase maintainability, and enhance business performance.

Enterprise Architects can analyze data regarding application complexity, underlying data stores, frequency of access, performance and capacity considerations, backup requirements, and a host of other factors that inform the planning process. Much of the discussion regarding how IT can provide value to the business can be centered on how the application portfolio will enable the business strategy and deliver the foundation for growth as the economy moves toward recovery.

Make It Happen

Aligning your understanding of the business and all of its resources and assets – Enterprise Architecture – with the effective execution of the business processes that drive results is critical to both smart cost reduction and the ability to effectively innovate.

By offering a unique and integrated software portfolio that combines market-leading Enterprise and Business Architecture, Business Process Analysis, and Business Process Management capabilities on a single platform, Metastorm Enterprise™ allows organizations to improve business results by unifying strategy, analysis and execution.

Strategy – Metastorm ProVision® provides a complete suite of enterprise modeling tools for both Enterprise Architects and business analysts. Key enterprise assets – including systems, data, resources, finances, products and suppliers – and their inter-dependencies can be modeled, shared and refined in a standalone or collaborative environment. Metastorm ProVision provides the platform to model strategy, goals, processes and the metrics that will be used to measure success.

Analysis – Metastorm ProVision also provides robust Business Process Analysis and simulation capabilities to define critical business processes and associated dependencies, facilitate requirements analysis, simulate multiple scenarios, and optimize processes and related enterprise assets against strategic objectives. Metastorm ProVision’s BPA capabilities help determine the best way to compose processes to optimize results, achieve goals, cut costs and create an agile framework that supports goals of the enterprise strategy.

Metastorm delivers powerful process discovery tools, as well. As part of the Metastorm ProVision offering, Metastorm Discovery™ replaces traditional methods of gathering as-is process information and formalizes process discovery activities. Metastorm Discovery eliminates the problem of having insufficient or inaccurate data to optimally leverage improvement efforts.

Execution – Metastorm BPM® is a highly-scalable, enterprise BPM suite designed to support automation, deployment, integration, analysis, monitoring, and improvement of both human and system-based processes within and across organizations. Metastorm BPM allows you to put your enterprise models into action – delivering value faster and allowing for change on a real-time basis.

By implementing Metastorm Enterprise to align EA, BPA and BPM initiatives, you gain a cross-functional platform that provides the strategic, tactical, and operational level views you need to identify risk across the organization, take advantage of opportunities for innovation, and improve business performance.

If there is a silver lining to the economic downturn, it may be the resulting need for aggressive change which can lead to innovations in products, services, and the way an organization operates.

Developing Actionable ITIL Processes

March 5, 2009 By Mike Tainter and Kristy Smith

A sound framework coupled with cultural transformation and results tracking are essential for successfully implementing ITIL, write ITSMWatch columnists Micheal Tainter and Kristy Smith of Forsythe.

Effective adoption of ITIL requires not only the application of ITIL best practices, but also a sound process development framework. Coupled with a campaign of cultural transformation and consistent measurement and results tracking, solid process development techniques will yield repeatable, integrated and actionable processes for managing services and operations across the IT organization.

The Pitfalls of Haphazardness

Haphazard processes can perpetuate inefficiencies, if not chaos, in an IT organization. For example, the complete set of knowledge of an IT organization's activities is usually spread among its many employees. This applies to process documentation, which is too often located in disparate repositories—such as hard drives, shared drives, email folders and people's memories—and is typically stored in many formats such as Word, Visio, PowerPoint, or not documented at all.

Thus, critical process intelligence can be lost or get out of sync when staff members leave, or when the organization grows, restructures or merges. The result is haphazard process development. Haphazard processes may have no clear entry or exit point, too much (or too little) detail, crossing lines, wordy or ambiguous procedure names, undefined roles and ownership, and a lack of clearly defined inputs and outputs to and from other processes.

Figure 1. Haphazard process development

A Sound Framework

A sound process development framework to support development of actionable ITIL v3 processes brings many benefits: centralized knowledge capture, repeatable results, reduced defects, increased collaboration, and a shared process language across the organization. It facilitates continual process improvement, and provides a consistent baseline for measurements, results tracking, and change control.

A good process development framework comprises an online tool built around a multi-layered process model. As depicted in Figure 2, each layer of the model parses the process into progressively lower levels of detail, leading the end user in an intuitive fashion to the specific actions required for thorough ITIL process implementation.

Figure 2. Multi-layered process framework

The four layers of the process framework are: process, procedures, steps, and work instructions and tool tips. Processes, procedures, steps and work instructions are housed within the online tool. The highest and lowest layers, policies and work flows physically reside outside of the online tool, but are still an integral part of an actionable process model. Each layer of an actionable process model is described in detail below.

Policies - A policy is a high-level overall plan that covers general objectives and expectations. For example, a common policy for Incident Management is to use the service desk as a single point of contact for all incidents, while common policies for change management are to establish a change advisory board (CAB) and to define rules for executing different types of changes such as emergency, standard, normal, etc.

Policy development is a responsibility and activity of management. It occurs outside of the process framework, and provides the goal posts toward which all process development is aimed.

Processes - Processes are high-level activities required to meet the policies and objectives of the organization during various phases of the IT service management lifecycle. The major activities for each process can be derived from the various books in the ITIL v3 service lifecycle. This is where it all starts and where ITIL paves the way.

Procedures - Each process should also outline the procedures that establish the set of steps required to complete the process activities. For example, the Incident Management process would have a set of procedures to identify and log; categorize and prioritize; investigate and diagnose; resolve and recover; monitor, track and communicate; and close the incident. Procedures are repeatable and static regardless of the particular incident or change request involved. A procedure is an action—its name always begins with a verb. Every procedure is triggered by a specific event or input, and results in a specific output.

Steps - Each procedure comprises a set of steps, arranged in flowchart fashion, that are followed to complete the procedure. For example, Incident Management contains a procedure to categorize and prioritize the incident. To complete this procedure, you would complete the following steps: determine the request type, record the incident details, identify the impacted configuration item, and determine the priority of the incident.

Work Instructions - Each step contains work instructions which document repeatable, role-based instructions for completing the step. Work instructions are where the processes and procedures meet the IT service management tool; as they explain how to utilize the tool to execute the step, when applicable.

To continue our example above, the work instruction for the step determine the priority of the incident would contain specific information about impact and urgency levels and criteria, and would describe how to indicate the incident's priority within the tool.

Work Flows - The lowest level of detail is the work flow. Work flows are repeatable, role-based instructions for executing a change, fixing a problem or producing a work product. Work flows are dynamic, consisting of the details tailored for each task that IT performs for the business. Documented work flows often reside in the IT service management tool in a pre-populated model or template, and are also referred to as standard operating procedures (SOP).

An example of a work flow is an incident resolution template, an automated service desk template that pre-populates an incident record with appropriate instructions for resolving a recurring incident. Other examples of work flows are standard change; a prescribed set of instructions for building, testing and implementing a repeatable change such as a password reset or a new employee setup; and a test script, a specific test scenario for confirming automated functionality.

Fostering Actionable Processes

Ensuring that ITIL processes are actionable is a challenge that goes beyond process development and documentation. The organization must recognize that a cultural transformation is required to foster acceptance of ITIL and to anchor new behaviors. In addition, a measurement strategy must be employed to track results of the ITIL implementation, to determine levels of adoption, and to promote continual improvement.

An ITIL initiative, like any change initiative, can potentially fall victim to the "dead salmon" syndrome: salmon swim upstream against the flow, lay their eggs and, ultimately, end up dead in the water. An ITIL initiative that is constantly swimming upstream against the cultural flow will likely meet a similar fate.

In his book Leading Change, John Kotter discusses an "eight stage process of creating major change" to effectively lead an organization through cultural transformation. The eight stages are:

1. Establishing a sense of urgency

2. Creating the guiding coalition

3. Developing a vision and strategy

4. Communicating the change vision

5. Empowering broad-based action

6. Generating short-term wins

7. Consolidating gains and producing more change

8. Anchoring new approaches in the culture

According to Kotter, stages 1 through 4 of the transformation process help break the status quo. Stages 5 to 7 introduce new practices. And stage 8 grounds the changes in the culture to help them stick.

The pressure to produce quick results often leads to a desire to skip stages or to execute them out of order. Don't be a dead salmon. It is important that all eight stages are followed sequentially. To curtail the desire of individuals to work against the impending change, and to actually nurture enthusiastic support, follow best practices for creating successful change before going down the road of ITIL implementation. Establish a steering committee, form a good foundation of management support, and communicate the vision before proceeding to introduce process and procedural change to the organization.

Change Through Measurement

An essential part of any ITIL implementation is to monitor technical and business results—such as process performance, quality, customer satisfaction, and levels of compliance—utilizing rationalized metrics, reports and auditing. Determine and baseline a set of critical success factors (CSF) with supporting key performance indicators (KPI) and operating metrics (OM). Determine a reporting strategy and schedule. These will be utilized by the steering committee, process owners and managers to measure process conformance, quality and performance.

Keep in mind that it is not reasonable to expect that process will be followed without proper inspection for conformance and performance. You can't expect what you don’t inspect.

Just as important is to measure cultural adoption of ITIL by surveying and interviewing IT staff to learn their attitudes. Are they realizing practical benefits as a result of the ITIL initiative, and does it seem worth the effort so far? Do they have an idea to contribute, or do they want clarification of an issue? This is crucial to making processes actionable and to ensure continual process improvement.

Mike Tainter, Forsythe’s ITSM practice director, has been managing technology and large-scale IT projects for more than 20 years, including IT service management, ITIL,operations management, process design, IT operations support system development, and IT logistical requirements. Tainter holds the Foundation Certificate in IT Service Management and the Manager's Certificate in IT Service Management.

Kristy Smith, ITSM associate consultant at Forsythe, has an extensive background in accounting as well as more than 10 years of IT experience including experience managing IT service management and ITIL implementations and developing ITSM methodologies. Smith holds the Foundation Certificate in IT Service Management.

Undervaluing the Need for Risk Management Is Risky

by Lora Bentley, IT Business Edge

As recently as last week, Yale University behavioral economics professor Robert Shiller told reporters the current mess in the financial markets results in part from a failure to manage risk. Last year, the Securities and Exchange Commission offered new guidance on a risk-based approach to Sarbanes-Oxley section 404 implementation. In between, companies like CA began offering governance, risk and compliance (GRC) products and services, and Standard and Poor's even began tracking enterprise risk management as a key to evaluating a company's financial health.

Risk management is the new hot topic in today's economic climate. Businesses are doing everything they can to ward off the fraud that caused Enron to collapse, Bernard Madoff's clients to lose everything, Lehman Brothers to enter bankruptcy, and so on. Ethics and Compliance Officer Association Executive Director Keith Darcy says his organization has more than doubled its membership in the last eight years alone. In that time, he says, the markets have seen a "flight to integrity." People are investing in businesses they trust and pulling their money out of those they don't trust.

But more than panic is driving the trend toward ethics and risk management positions in the executive suite. It's also good business. Jeff Smith, who serves as legal officer and risk officer for the Michigan-based Consulting Services Support Corp., says, "Once a number of companies begin to better manage and mitigate their own unique risks of loss, it only makes sense that other corporations that wish to retain competitive advantage and attractiveness to shareholders would follow suit." That, he says, results in the wealth of risk management and ethics-centered positions that are available today.

“The first challenge is often to help others realize that they have a reason to learn from you...”Jeff Smith, Consulting Services Support Corp.

The positions will differ a bit in terms of title, salary levels will vary, and some may have a broader set of responsibilities than others. For instance, Inter-American Development Bank in Washington, D.C., is seeking a "principal integrity officer." The person's responsibilities? Planning and executing fraud and corruption investigations. Smith's responsibilities at CSSC, however, run the gamut. He says simply, "I manage risk in the areas of insurance, law, compliance, ethics and any other areas that my CEO or I may identify within the organization."

Protiviti managing director Paul Schulz notes that the most effective risk and ethics officers are those, like Smith, at the executive level. He says, "Overall direction and management of enterprise risk is the key role... In essence, CRO and equivalent roles are at the fulcrum of creating and managing the mechanisms that cut across organizational and business unit boundaries to identify, manage, and mitigate risks in a wide variety of categories."

Darcy agrees. "The chief ethics and compliance officer must have C-suite status. They must have independence," he says, "They must have unfiltered access to the board, and they must have a seat at the strategy and policy table because that's where the big decisions are made."

Forrester: SaaS adoption is rising, but TCO remains a concern

This is a guest post from Larry Dignan of TechRepublic’s sister site ZDNet. You can follow Larry on his ZDNet blog Between the Lines (or subscribe to the RSS feed).

Twenty one percent of companies are piloting software as service applications, up from 18 percent a year ago, according to a recent Forrester research report. However, even as SaaS adoption increases during the current recession worries about total cost of ownership remains among software buyers.

Forrester surveyed 239 applications decision makers and found the following worries about SaaS:

• Total cost of ownership: As SaaS deployments grow and extend to large enterprises TCO matters. What are the deployment costs associated with licensing, staffing and training?
• Backup and security policies: Vendors need to detail guidelines for security, backup and data recovery based on known standards.
• Contract guidelines: SaaS contract templates are currently hard to come by and buyers often accept vendor terms because they lack existing contracts.

Overall, those gaps appear to be holding back SaaS adoption a bit. For instance, Forrester found that 21 percent of companies are piloting or using SaaS, up from 18 percent in 2007. However, 26 percent of software buyers said they were interested and considering SaaS in 2008, down from 45 percent in 2007. Meanwhile, 54 percent of companies said they weren’t interested in SaaS or didn’t know if they planned to adopt it. That tally is up from 37 percent in 2007.

Add it up and it appears a lot of companies have evaluated SaaS and decided it wasn’t for them.

This slide highlights buyer worries:

And those that are adopting SaaS are sticking to the familiar commodity applications:

Larry Dignan is Editor in Chief of ZDNet and Editorial Director of TechRepublic. See his full profile and disclosure of his industry affiliations.

Lowering Incident Management Costs

February 27, 2009
By George Spafford

There are many means to improve how incidents are managed but the first is implementing an formal Incident Management process, writes ITSMWatch columnist George Spafford of Pepperweed Consulting.

In today’s economy, IT is under pressure to reduce costs and "do more with less". As a result, IT managers are looking for ways to cut expenses wherever possible. Incidents and reactive work are being scrutinized for opportunities to cut costs and therein lies both challenges and opportunities for the groups that understand the type of costing benefit their work may bring.

Costing Overview

One of the concepts often promulgated by consultants, software vendors, and others with an agenda revolve around the costs associated with transactions. The basic premise is if you can remove costs from a transaction then there must be a savings. A common example is to cut the time it takes to do something and then extend it by a loaded labor rate and then display the difference as a “cost savings”. Those numbers then go into business cases and so forth only to make knowledgeable executives roll their eyes as another example of IT not understanding costing.

At the risk of oversimplifying, unless a change causes a reduction in payments, such as to a vendor, or a reduction in labor expenses, then there isn’t a true accounting cost savings. When improvements yield time savings to existing resources or enable less-constrained, lower cost resources to be used (which then free up more constrained higher level resources), then the improvements relate to opportunity cost savings.

Opportunity costs are an economic concept. The premise is if a resource is performing one task, then it comes at the expense of another. For example, if a senior engineer is doing break-fix incident work versus project work to get the organization closer to its goals, then the opportunity cost is that very loss—break/fix firefighting vs. true improvement. All things being equal, we’d prefer the engineer to be working on the meaningful project work.

The organization has opportunity costs as well. If an IT service is unavailable, can the business conduct operations? For example, if an order entry website is down and sales are not possible then revenue is lost and may not be recoverable. When looking at incident costs, as this example shows, it is important to look outside of IT for impacts as well.

What to Improve

With that said, there are typically many opportunities that can be pursued to reduce the costs of managing incidents. Each organization is different but the first step is to assess the current state, compare current practices to best practices and then identify which gaps will yield the greatest benefits to the organization given its stated direction, constraints, available time, budget, ability to change and so on.

The first step is to implement a formal Incident Management process. However, there are limits to the possible improvements within the Incident Management process itself. To generate significant result long-term requires the involvement of other process areas and their respective IT teams. The ITIL v3 lifecycle has five phases that contain opportunities to reduce the costs associated with incidents. The following are examples of phases that could impact the accounting and opportunity costs associated with incidents:

Service Design – If total requirements are understood, proper tools are used and personnel with the right skills are used to create and maintain services then the resulting releases will be of higher quality. The processes in this phase such as Service Level Management, Capacity, and Availability, can all be leveraged to understand and review service design requirements. All things being equal, if services are built correctly then incidents in production will go down.

• Service Transition – Releases should be project managed with proper oversight to ensure budgets, timeliness and requirements are met. Releases that are properly tested and production changes managed will result in fewer incidents long term. The Configuration Management System spans phases and will aid all stakeholders in having a logical view of the IT services being provided to ensure proper planning and fewer errors.
  

• Service Operation – A well designed and implemented enterprise Incident Management process that is followed will create an environment wherein incidents can be managed in an effective and efficient manner. Moving past that, Event Management can assist with a logical approach to identifying criteria relating to changes of state and approved responses further reducing the response times, skills required to respond and certainty of success. In addition, Problem Management and a Known Error Database can be developed to help reduce the number and duration of incidents.
  

• Continual Service Improvement (CSI) – This phase can help ensure that the various processes that affect incidents remain designed in a manner that creates value and mitigates risks. Note, CSI should not be viewed as a project that gets triggered after a failure but rather as an ingrained philosophy. Thus, there should always be a drive to improve how incidents are managed.

Many additional improvement opportunities can be pursue by moving outside of the Incident Management process and working with stakeholders in other processes and functions to improve processes in their areas that will reduce incidents over time. These reductions will definitely benefit the organization. With the current economic crisis, improvements that can cut costs while improving service are sorely needed.

George Spafford is a principal consultant with Pepperweed Consulting and a long-time IT professional. George's professional focus is on compliance, security, management and overall process improvement.

Where's the Fit? ITIL and Project Management Skill

It is always good for professionals to combine the right sets of expertise. For someone involved with IT infrastructure projects, ITIL is a great complementary certification. What I find is that often the specialty knowledge drives the PRODUCT of efforts, but the project management skills drives the PROJECT that produces the PRODUCT. On solid technical teams, that second mindset is often missing.

Background
When you get any level experience in the workplace, you realize that the world is a collection of operations and projects. We are always seeking to systematize where possible, to streamline operations, and to improve results. We are always trying to create a "business as usual", "runs by itself" environment, although in reality the full achievement of this is elusive. For more detail go to www.positive-idea.com We are always cognizant of change in external conditions, and of the need to be proactive in changing our operations when necessary. This intersection of operations and project management, is, I believe, where ITIL and project management come together.

The IT Infrastructure Library® (ITIL®) describes a set of best practices processes for stable, high quality IT services. Project management, as a discipline, provides the capability to implement a defined change in a controlled way, so that cost, schedule, and quality of deliverable are as expected. It would seem that awareness of ITIL in an environment where it is embedded would be an input to project management. Likewise, project management is a great skill to use in implementing and continuously improving the best practices provided by ITIL.

PRINCE2 and ITIL
PRINCE2 and ITIL originate from a single source, the OGC (The Office of Government Commerce) in the UK. While I do not have hard core statistics, ITIL seems to be more strongly on the radar screen in the United States than PRINCE2, probably in part because the PMI PMBOK is more heavily established. But the practice of ITIL does seem to draw on PRINCE2 to an extent due to its common origins, despite the fact that a project management framework such as PMBOK can, in my opinion, be just as effective.

Both ITIL and Prince2 have a mechanism for evaluating the change or project. The Post Project Review in Prince2 is the same as the ITIL Post Implementation Review. A successful review can therefore lead to the end of the project.

Where ITIL and Project Management Meet
IT Infrastructure Library (ITIL) is all about providing service within the operations of IT in an organization. This includes management of the Service Lifecycle, Service Strategy,
Service Design, Service Transition, and Service Operation. It also means continual improvement of the whole set of services that are in place. Management challenges within this realm include Service Desk and Incident Management, Configuration and Release Management, Service Level and Capacity Management, Problem and Change Management, Continuity and Availability Management, and Financial and Security Management.

ITIL itself, as a discipline, addresses the operations within the defined services realm. However, any changes to that services realm can and should be handled by applying a good project management discipline. The difference is that the ongoing operations will be concerned with maintaining and improving services as an in-place, as-is process. The project management discipline will be concerned with defining the beginning of an initiative, delivering the product of that initiative, and turning over the results of that effort to be incorporated into the operation before finally closing out the project.

The two disciplines are substantially different, and using the wrong one can definitely result in lower effectiveness. In the case of ITIL and Project Management, both disciplines will provide inputs the other. For example, ITIL will provide the current situation to a project. It will also provide certain procedures, such as configuration management, that must be followed within the confines of the project. The results, or "product of the project", will become the key input to changes or improvements to be implemented within the ITIL implementation framework in the organization. The professional that understands both sides in depth will be quite valuable to the organization and will have a leg up in knowledge and credibility.

A Little about ITIL (ITIL certification, that is)
ITIL certification has 3 levels: the Foundation Certificate, the Practitioner Certificate, and the Manager's Certificate. Project Management Training Online offers ITIL training in preparation for the Foundation Certificate.

In a nutshell, here is what these 3 levels are about:

The Foundation Certificate: There are no entry requirements, and the foundation test consists of a one hour long multiple choice examination testing a candidate's basic understanding of the principles and terminology of the IT Infrastructure Library. It is designed to provide familiarity with the IT Infrastructure Library (ITIL) best practices for IT Service Management.

The Practitioner Certificates: This is aimed at those who are responsible within their organization for designing specific processes within the IT Service Management discipline, and performing the activities that belong to those processes. The Practitioner's Certificates focus on the depth of understanding and application of those subjects, treating each subject as a specialty. Prerequisites include the Foundation certificate and mandatory attendance at an accredited training course.

The Manager's Certificate: Aimed at managers and consultants, 2 - 3 hour examinations test the practical application of the theory of ITIL, and the exam is typically preceded by a 10-day training event other assessments may also be required. Candidates must hold the Foundation certificate and mandatory attendance at an accredited training course is required.

ITIL v3 is Your Next Step in ITSM

February 20, 2009
By Eddy Peters

ITIL v3 changes enable service-driven processes instead of process-driven services, writes ITSMWatch guest columnist Eddy Peters of CTG.

Most of us still remember June 2007, when the long-awaited ITIL v3 was released. This version would present an integrated approach to service management by covering all aspects of the service life cycle—from cradle to grave and everything in between. The journey was documented in five books called the "core volumes".

On launch day, the itSMF presented the ITIL v3 “roadshow," a document, which to this day provides quality information. The roadshow includes a complete overview of ITIL v3 and answers to questions like Why the need for change? and What is the purpose of ITIL v3? The future looked promising!

To better understand the capabilities of v3, we devoured the core volumes and then carefully evaluated them against the purpose and changes identified in the roadshow presentation. This exercise resulted in the following dashboard, which shows how well the core volumes deliver on itSMF’s promises:

Fig. 1 - Study summary covering all volumes

Early on, we saw that v3 didn’t quite meet expectations. The lack of more practical “how to” guidance was a bit of a surprise. Luckily, itSMF foresaw complementary publications, which would provide more guidance and understanding. But since the complementary material is still in development, we’ve been digging even deeper into the hidden opportunities in the core volumes’ 1,344 pages. Although there have been many informative sessions about v3, the potential is still not fully clear.

So, if you're asking yourself "is v3 your next step in IT service management?" You’ll be relieved to hear that ITIL v2 is still alive and kicking. In fact, v2 is here to stay; alongside v3. Why? Because it’s concise and focused on day-to-day management of existing IT services. Compared to v3, it is a useful "pocket guide" consisting of just two books and 686 pages. So, you can continue to use your existing v2 processes. However, v3 introduces some interesting ideas to further mature your daily activities. Some gems which are worth looking into:

• Request fulfillment: the explanation that was missing in v2 Service Request

• Event management (completely new): guidance for integrating warnings from monitoring tools into support activities.

Among others, these processes round out ITIL’s guidance for optimizing your daily operations. What else is in v3?

Process-Driven Services

ITIL v3 covers much more ground, from development to testing to facilities to operations. New processes like Service Catalog Management can increase awareness of what services are delivered. Service Asset and Configuration Management provide an approach to dealing with service management information. These actions will help build an improved, more mature, process-driven IT organization. This is good, but it could be better.

The full potential of v3 cannot be realized by focusing solely on process implementations or improvements—that’s just ITIL v2.5. The emphasis on processes leads to a new phenomenon: process silos. These are similar to the functional silos we all know so well, which each compete for a share of the budget. Implemented processes provide great benefits to the IT organization (streamlined activities, improved capabilities of specific IT groups, optimal resource usage, to name a few). But these improvements don’t necessarily roll up to the rest of the business. Why not? Because they’re mostly still focused inward; on IT.

Service-Driven Processes

ITIL v3 provides the next step in service management: think service, think life cycle. Service management in the IT organization is no longer driven by processes, but by the elements ITIL was created for in the first place—services.

As the creation of a service moves from business analyst to development to testing to operation, v3 provides an opportunity to align different departments within the IT organization. At that point, service silos are created, competing for a part of the budget. As an interesting side effect, services are outward focused, to the business. If the business derives value, the provided service is funded; if not, it gets retired. That’s what integration is all about.

Even with a few gray areas, ITIL should definitely have a place in the IT organization’s strategy to take the service delivery maturity forward. When optimizing processes, both v2 and v3 add value. When attempting to work out a service-oriented life cycle approach, v3 is there for you. When it comes to answering the question, “Is ITIL version 3 my next step in IT service management?”, it is not so much about If, but how you will do it.

Going for process-driven services (ITIL version 2 & 2.5) or service-driven processes (v3), it all comes down to what your organization wants to achieve, what its maturity level is in delivering service and what its capabilities are to cope with change. The choice is yours.

Eddy Peters is a senior ITSM consultant with CTG, an international IT company with headquarters in Buffalo, N.Y. Mr. Peters has been active in IT for almost 20 years, acquiring experience in both support and delivery capabilities. He had the opportunity to dig into the ITIL v3 framework early on as a beta reviewer, and to understand its potential. With the official release of the core volumes, he became the driving force within CTG to assimilate the knowledge and put it into a practical perspective.

What you can learn from the ITSM process

In order to add value to your company, you have to be as close to the transaction as possible. By having the larger percentage of IT services focused on support processes, you are one layer removed from the transaction and the IT department is doomed to be a cost center forever.

——————————————————————————————————————-

Every time I go down the path of reviewing an existing IT department against the ITSM (Information Technology Service Management) process, it still amazes me how wrong assumptions can be. The purpose of ITSM is to align your IT department and the services it provides to the business. The idea is that you can talk to the business folks and package the IT offerings that IT provides in a way that an IT outsourcer would.

I’ll try to explain that last statement a little more clearly. Let us assume that all the theories (sans Bernie Madoff’s) about the market are true. The whole supply versus demand economic model supports that if there is a need that can be performed more expertly and/or more inexpensively by someone else, then a market exists. You have one party willing to pay for these services and you have a company willing to provide these services. Theoretically, the company providing services exists because it has found a way to add value to a customer that the customer is willing to pay for.

So all of these IT outsourcers (OK, many of these IT outsourcers) have a slick sales presentation and a business model designed to provide a customer better service or more inexpensive services than the company’s existing IT department.

The idea of ITSM is to group your IT services into value-adding products that business managers already understand. You have successfully articulated your department’s value proposition and you as the CIO can objectively compare your services to those of outsource service providers. This is a great tool to make sure that the services you are providing are still relevant and cost effective. You compete on cost, quality, and ability to provide a service. If you can’t compete, then you can proactively seek out an outsource partner to improve your overall IT service portfolio.

So with explanation decently defined, we began the process of ITSM alignment. (By the way, here’s a good book on this alignment process.) You know how all the philosophers say that it’s not the end goal that is the most rewarding, but the journey itself? Well, that’s the case here. When you actually sit down and walk through the ITSM alignment process, much is revealed.

The first step is to look at the business. The core processes of the business can usually be defined or have already been articulated by executive management. Basically, what does your company do to get paid? Then there are other levels of processes. There are supporting processes such as Finance and Human Resources. There are also “Innovation” processes such as Marketing and Sales.

The next step is to identify the IT services that you provide the company. These services are not systems. These are actually the body of work supplied to the company. A financial application may include custom code from programmers, a SAN, a database management system, a set amount of disk space, some servers, software licensing, network resources, help desk support, etc. All of these represent the service of “Providing financial application services.”

After you list the services, you go down the path of mapping IT systems to the IT services. This gives you the necessary granularity to determine the costs of providing this service. How you determine the actual costs can be somewhat more art than science. You can be general by figuring out how many U the financial application takes up in a server rack and use the percentage of data center costs by that or you can get really granular and look at power consumption, CPU utilization, network bandwidth, and disk space. The important part is getting in the ball park.

What I’ve found twice now in performing this exercise with two different companies is that when you map the IT services to the business processes, there is a disconnect as to where the IT services are focused. A huge percentage of time and resources from IT are spent, not in direct support of the core business processes, but in support of the Support or Innovation processes.

A wise friend once told me that in order to add value to your company, you have to be as close to the transaction as possible. By having the larger percentage of IT services focused on support processes, you are one layer removed from the transaction and the IT department is doomed to be a cost center forever.

Instead, look for outsource partners that can support the support processes while you and your team focus on supporting the transaction and how the business makes its money. This way you insure IT’s role in adding value to the organization.

A successful IT executive with 15 years of technology leadership, team building and value creation, Jay Rollins has served as VP of IT/CIO of several mid-sized companies and technology start ups. He has varied industry experience including gaming, media and entertainment, healthcare and ecommerce. Jay received an MBA from Bentley College in Waltham, MA and founded PicoMatrix in 2008.

The Four Big Questions ITIL Doesn’t Answer

January 30, 2009 By Rob England

In many ways ITIL v3 is more complete than ITIL v2, but there are still a lot of basic questions that you need to answer for yourself, writes ITSM Watch columnist Rob England.

There are still many people who are under the illusion that ITIL provides a prescription or plan for implementing IT service management (ITSM). It doesn’t. In fact, the more important the decision you need to address, the less likely there is guidance for it.

When we want to know how to, say, measure a service desk, we can find quite exact guidance from several sources including ITIL. But the depth and usefulness of advice is inversely proportional to the importance of the question. Consider the most important decisions you need to take as you embark on an ITIL initiative, the Big Questions. In this article, we will look at the most important four.

The first and biggest decision of all is whether you should even do ITIL. What are the gating criteria specific to ITIL? What special factors should we look out for? Surely, ITIL defines them? No.

Or look at the next most important Big Question: how far should we go?

To answer this, the standard consulting approach used in ITIL is to determine the current "as-is" state through assessment, then decide the "to-be" state, and then work on the gap. ITIL v3 still fails to provide an as-is assessment model, though COBIT does. So too do many consulting firms. So, we can find the as-is readily enough, especially if we pay for it. But what about the other half? How do we pick the target "to-be" state?

Very often the as-is and to-be are defined as some composite capability maturity model (CMM) level from 1 to 5 (Actually, 0 to 5. I've met zeroes.). A consultant will give you the as-is to two decimal places, but how do we determine the to-be? The standard model is to extract a number from a suitable orifice. If you're a basket case you'll go for Level 2. If you are mainstream you'll shoot for a 3. If you want to swagger you'll aim for 4. And if you want to use the result in marketing your company's services you'll find a consulting firm that will certify you as a 5.

This is not exactly scientific or rigorous, and there is no process other than a brief gaze at the navel. Why do we have whole books of guidance from multiple sources on lesser issues but when it comes to setting the broad scope, the ambition (and of course the cost) of the initiative, we allow someone to pick a number? On what basis? With what advice and guidance? Reached through what reasoning and methodology? None. Not in ITIL v3 anyway. Nor in COBIT.

The Journey Begins

So, we pull some numbers out of … umm …. the air, and we embark on the ITIL journey. We look at ITIL v3 and it is huge. Even ITIL v2 towers above us as we look at all 10 or 11 or 13 processes. Surely, we won’t try to do it all at once?

Advice exists that says pick the processes off one or two at a time but this is patently rubbish. Processes are intertwined and interdependent. We need to go into a number of processes at once, in a phased manner. Many times there is a crying need for a bit of all of them. Now if ITIL v2 was a line of processes, v3 is a plane. It has the extra dimension of the lifecycle of the services. And we certainly are not going to attempt that entire dimension at once. Nor are we going to do each of the five ITIL v3 books (which map that dimension) one by one. They are just as intertwined. So, we need to implement pieces from all five, at the same time, in a phased manner.

Which brings us to Big Question Three: how to determine what goes in each phase? How to measure whether a phase is done? How to get from one phase to the next? How to project manage the implementation of ITIL? Surely, ITIL gives some guidance on that? Well it does, a bit; accidentally. It describes how to implement services, so there is some guidance there that can be applied to implementing anything. But directly about how to implement the ITIL systems to run the lifecycle to implement those services, it provides nothing. Nada. Bupkis.

The analogy of a house blueprint is often used to describe ITIL. But don’t make the assumption that it is for your house. It is the blueprint for a generic McMansion; with gothic columns and three floors and a quadruple garage and stables. It has an automated building management system and marble stairs. Even if you want a house that fancy, you are bound to want the rooms arranged differently. Most of us will want something a little simpler.

To use the blueprint you will need to modify it considerably to your preferences and site and budget. There are no instructions for this, so you had better get the site professionally surveyed and the plans re-drafted. Then you will need to estimate it and a builder to build it—because there are no instructions for those activities either. Even if a house came as a kit pile of timber and stone and a fat book of directions, most people would not be so foolhardy as to attempt assembling themselves. Asking your staff to assemble the house in their “spare time” is especially not a good idea.

Once you spend all the money to build the house, you will need to demonstrate to local authorities that it was done properly. And so we arrive at Big Question Four: does it meet the standard? How do we asses the completeness (not to mention quality) of an ITIL implementation? What does ITIL tell us? Guess! No checklists. No minimum criteria. No standards.

There is something closer to what we want: ISO/IEC 20000. But it is only close. The authorities will say you have assessed your house against the standard for a ski lodge or small shop or something not quite exactly the same. It might do, it might not. Likewise with using COBIT to assess ITIL: it covers all of ITIL (pretty much), and lots more. But ISO/IEC 20000 and COBIT only look at ITIL from the outside, as a black box. They only assess the exterior of the house. Explaining all these moot points to the Board will not go down well. They want to know if ITIL was done properly, and they want to know how well. And you can’t tell them other than offering some expensive consultant’s subjective opinion.

If you want to know the best way to run a Change Advisory Board, ITIL will tell you. If you want to know best practice in analyzing problems, ITIL will tell you. But there are still four Big Questions where you are on your own:

• Should you do ITIL?
• To what level should you do it?
• How do you do it?
• How do you show you did it?

Rob England is an IT industry commentator and consultant, and nascent internet entrepreneur, best known for his blog The IT Skeptic.

Research Indicates Continued ITSM Growth in 2009

January 7, 2009
By ITSM Watch Staff

CIOs will advance ITSM programs to better align IT with business drivers.

Despite the unsteady economy, 87% of IT professionals are planning strategic, enterprise-level ITSM programs with the support of senior management. This is one of the key findings of a new Enterprise Management Associates (EMA) report: 2009 Trends and Best Practices Advice for ITSM Technologies and Processes.

"The coming year will certainly be a critical, pivotal year for IT executives,” said Chris Matney, EMA consulting director and study leader, in a press release. "Fiscal pragmatism will be weighed against the increasing challenges of IT, and IT leaders must carefully balance both. Successful CIOs will continue to advance ITSM maturity while closely watching business drivers and the corporate balance sheet.”

According to the survey, mid-size companies showed the highest levels of ITSM adoption. Smaller companies typically rely on traditional service/help desk implementations, while the largest enterprises continue to work through the challenges of complexity and scalability. Most companies are in a transition phase with their ITSM maturity, between an "active” and a "proactive” approach.

EMA believes that the most successful companies will push through the economic recession with IT advancements and investment, while unsuccessful organizations will adopt a more passive "business as usual” approach.

Additional key findings from the survey include:

- IT budgets are not in a total free-fall, but a growing number of IT organizations are cutting budgets by 10% to 25%.

- Change management was the most important ITSM initiative for companies of all sizes, followed by the other ITIL service support disciplines.

- Only three percent of respondents reported that all ITSM initiatives have been completed, and 80% said some have been finished.

- Most (74%) of respondents place primary responsibility for strategic ITSM planning on C-level executives, IT vice presidents and IT directors.

- Most (67%) of respondents are not planning to replace their ITSM tools. For those that are, functionality limitations are the primary drivers for mid-sized companies and lack of scalability is the motivation for enterprise organizations.

- ITIL is the biggest area of investment for advancing the adoption of ITSM best practices, with 62% of companies expecting to undertake training in 2009.

EMA believes short-term projects will gain favor in 2009 due to longer term budget uncertainties. Most ROI break-even expectations for ITSM projects are between six and 18 months. Some of the best practices recommended by survey respondents included creating an incremental ITSM plan and securing executive and business support early in the process.

Sign up here for the free Webinar on January 8 titled, "Make the Most of ITSM in 2009: Best-Practice Advice from Your Peers”

Methodology

For this report, EMA surveyed 143 IT professionals to uncover success factors and pitfalls of ITSM initiatives and recommended best practices based on real-world deployments.