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.
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.
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.