Roadblocks in implementing operations frameworks: Gaining consensus

Both the Information Technology Infrastructure Library (ITIL) and the Microsoft Operations Framework are great blueprints for IT success. Their implementations could be complicated by unforeseen problems, though. Here's how to resolve them.

Marc Talluto is a consultant with Acquity Group consulting. This is his first article for TechRepublic.

An operations framework provides a method for maintaining your IT organization, systems, and processes. It can help reduce costs, inefficiencies, and downtime but can be perceived poorly by those who are unfamiliar with frameworks.

To gain consensus for implementation, you have to explain operations frameworks in a common language, raise awareness of current problems, and leverage the work that has already been done.

My current client is a global financial services company with more than 10,000 internal users and over 1,000 IT employees around the world. Although I’ve spent years implementing frameworks—such as ITIL, Microsoft Operations Framework (MOF), or those developed by Big 5 consulting firms—for large organizations that wanted them, I wasn’t prepared for a client that had to convince all departments that it needed one.

Buy-in from senior management and communicating effectively to middle management were the initial objectives before we could implement frameworks projects. Along the way, we hit several roadblocks that we succeeded in managing or overcoming, including:
  • Explaining the framework.
  • Closing the perception gap.
  • Assessing the effort.

Here’s a closer look at our efforts.

Explaining the framework
A simple question that peers may ask is, “What is an operations framework?” Although well documented in generic terms, an operations framework lacks the specific appeal that will communicate how it will work at your company. At this phase, you’ll need to address specific business problems the company faces.

Begin by explaining a common but detailed business process that your company executes, such as a new product release. Next, show how IT enables this through technology services, such as marketing through Web presence.

The next step is to show how these services rely on standard operating procedures—such as Web presence through content management—to be reliable and current. Even for technology staff, this exercise will help communicate the continuous delivery of service from IT to the business.

For example, my client is in the financial services industry. Its products involving IT are typically new applications to help customers access financial data. As illustrated in Figure A, we presented this concept by mapping business functions to IT services and then to operations.
Figure A
From Business to IT Operations
Business Process IT Services IT Operations
Product Marketing Web Presence
CRM Campaigns

Content Management

Application Release Application Development Project Management
Release Management
Change Management
Configuration Management

Customer Support Call Center Incident Management
Problem Management
Systems Management

Note: You can add a column that shows specific applications, processes, or phrases that people will associate with your company (for example, using Siebel Systems for CRM campaigns).

The intent is to show that you have IT services relying on common operational tasks. In addition, a majority of these tasks would be the same if you defined a different business process. You might have, for example, a different server in a different data center performing a different function, but it was changed in a controlled fashion, the new configuration was logged, system monitors were updated, and the help desk was informed.

At this point, people may ask, “Do we really need a comprehensive framework for doing what we already do?”

Closing the perception gap
Consensus for working with an operations framework means people acknowledge that things are not working smoothly and can be more effective. This is a hurdle that you may have to overcome, since a perception gap often exists between how the IT department operates and what is reported to executives.

Asking the following questions gets managers thinking less in terms of “Can we get it done today?” and more in terms of “What does it take to get it done?”
  • How many production outages do we have and for how long?
  • How often do we find the same production problem unresolved?
  • Do we know how much staff time is used to support production?
  • What are the current projects we are working on to improve effectiveness?

With my client, I’m focusing mainly on production and support areas, because these typically are a good starting point to see how effective your IT organization is. Production support is the recipient of knowledge passed on by developers and technicians; they know what is working and what has failed, and they have a good sense of what it takes to get other IT staff working together.

We actually took this a step further and created a real-time tool that communicated outage information on business-critical production systems. It would send e-mails in real time to managers, letting everyone know what the status of an outage was, which customers were affected, and who was working on the solution. It worked in tandem with the incident management tool but was meant to address management requirements for quick and easy information.

Within a few months, we realized that we needed to expand the audience and added all technical staff to the communication. The entire IT organization began to see just how many production outages were occurring and reoccurring on a weekly basis. Awareness changed very quickly, and management realized that IT operations were suffering. A series of initiatives aimed at improving production system stability is now underway.

Assessing the effort
A common misperception of operations improvement is that it is an additional project that requires many resources. There can also be resistance to analyzing operations effectiveness because people feel you are questioning the work they are already performing or their ability to manage.

We had to show that working with a framework was more a coordination of current work than a redesign of all work. We were able to mitigate concern by showing how existing projects fit into an operations framework. We could then leverage mutual experience and effort to realize these goals faster.

To assess the effort, we made another table, shown in Figure B, to map current initiatives to operations functions. For each operations area, we defined goals and objectives, based in part on standards practices, shared experiences, and company needs. We then went to different teams and documented what projects were planned, or were in process, for addressing each area.
Figure B
Operations Project Mapping
Ops Area Goals/Objectives Current Projects
Incident Mgmt • Tiered support across IT organization
• Single incident tracking tool used by all tiers
• Committed single-point-of-contact per team
• Defined ownership per IT component
• Standard procedures (e.g. escalation, communication, prioritization)
• Reporting for trend analysis, performance, and service level agreements

• Siebel Deployment
• Standard Process Creation
• Staff Rotation Schedule

When we performed this exercise for the client, we discovered redundant work efforts, excessive application costs, and operations gaps, including:
  • The use of nearly 30 different applications for systems management.
  • Five distinct tools for incident management.
  • A lack of projects to control production changes.

Obviously, further analysis of the operations environment is required prior to any implementation, but this kind of effort should help communicate the need for it.

The issues raised here are certainly not unique for large organizations; these fundamentals can be applied in a company of any size. Once you apply them, people will begin to realize that they all share common problems, and others within the company may have solutions for them.

Editor's Picks