Rising to a New Level

Service-level agreements haven't fared well with IT consolidation. In Missouri, the situation is different.

by News Staff / August 7, 2007

By William Bott, deputy for operations to Missouri's CIO.

If the cleaning crew had not entered the conference room, I am not sure any of us would have known how late it actually was.

The meeting had started at lunch with a casual discussion about how, as a soon-to-be-consolidated IT division, the CIO of Missouri could offer 14 executive branch departments any level of confidence that the service they were accustomed to would not suffer under the impending changes. Nine hours later, we had flip chart pages and Post-It notes littering the room, but no clear direction.

Four weeks earlier, Gov. Matt Blunt had tasked our state CIO with combining 1,200 staff members from 14 departments as part of his technology efficiency initiative. The governor's assignment to us was to maximize investments, reduce duplicative efforts and keep the departments happy. With a short timeline and a need for success, our new CIO's executive team began researching the national consolidation trend. With no two efforts alike, there was nothing out there that fit our situation. So without a playbook to steal, we began to write our own.

Consolidation is the next logical step in moving technology services to more of a utility role than a business function. Technology is the modern means to a business outcome, not an outcome in itself. A state's department of education should not have an efficient, reliable and available server environment as one of its outcomes. Instead, it needs an efficient, reliable and available server environment to provide the business outcome of educating children.

In the same way, CEOs of major manufacturing sectors don't spend time looking at how the electric company gets power to the building, they just want to know how they're going to get the power they need to run the factory and how much it costs.

CIOs provide the utility for organizations to accomplish their business functions. At some point, we need to be considered as reliable and trustworthy as the electrical companies, and I would argue we can accelerate how we get there through simple, measurement-based service-level agreements (SLAs).

Historically the standard SLA used in our state has been the best tool for defining expectations. They have also been the most frequently used weapons for beating the tar out of one another. Made up of a series of Boolean statements, they tend to be too detailed, difficult to decipher and the bane of most customer relationships.

In addition to the "wrapped up in minutia" mindset of these documents, they are usually managed by operational staff or low-level managers instead of business leaders. These positions, typically more ingrained in operations than outcomes, used the rigid structure of these agreements to make life difficult for process changes, even when those changes benefited everyone involved. Quite simply SLAs can be the documents that bog down the wheels of public service.

But as trouble-plagued as they were, SLAs were the leading candidate for how we would manage our IT consolidation initiative. After studying what most other states had in place, we were in familiar but unfriendly territory.

Any attempt at an all-inclusive IT SLA would be more of the same. Surely no smaller than a large city phone book, it would leave quite a bruise if it hit someone and no doubt fail to capture every aspect of IT. Moreover, enterprise service delivery, whether in application availability, help desk support or infrastructure reliability, was difficult to define in terms of what the customer should expect. Across the departments, it had never been measured before. Most IT shops could tell you how long their network was down last month if you asked, but very few were routinely reporting metrics on availability to senior management. Frankly senior management didn't care when it was in their control, but they sure cared now.

In the time leading up to any consolidation, there is a cultural phenomenon of demanding more accountability than previous expectations. Every business leader fears that with a loss of authority over IT staff will come a decrease in technology services. The confidence in the utility is gone, and the need for some formal means of accountability becomes paramount. We knew we needed something, but the prehistoric SLAs had to go.


Down-to-Earth Question
"What if we simply asked the departments to define what outcomes they are most concerned about and then measured performance in those areas?"

What started as a practical question quickly became the foundation of how we managed our consolidation. Working with our customers, we defined their outcomes and expectations using a measurement-based communication tool that focused on outcome, not process. We built a new kind of SLA that measured delivery against a preconsolidation baseline.

What we developed in four simple, repeatable steps has become a playbook that can benefit other teams regardless of where they are in a consolidation effort.


Step One: Find out what your customer thinks is important
More than most other business functions, IT can use the "fog of war" approach to keep others in the dark about everything from infrastructure to budget. It's very easy for us to turn a conversation away from application problems by rattling off the latest service-oriented architecture studies. Before you know it, the conversation is so convoluted that your customer simply moves to the next topic.

In an environment where the IT staff no longer report directly to the department, this "confuse and confound" philosophy just drives a deeper wedge between you and the customer. A command understanding of their technology needs, fears and desires - based on their business practices - is crucial to the customer relationship.

We conducted a series of customer focus groups designed to help each department define their top 10 to 20 technology-based outcomes.


Step Two: Focus on the outcome, not the process
The results of the focus groups ranged from very high-level broad outcomes, such as availability and efficiencies, to very specific details of how processes such as e-mail accounts were maintained.

t was infinitely more important to measure the outcomes than to measure how we accomplished them, and it was essential our customers start looking at IT from that perspective. For example, we needed our customers to care that e-mail was available to them 24 hours a day and stop thinking in terms of how many e-mail servers were housed in their area and/or how many staff were available to support them.


Step Three: Find measures that reflect the outcome
All the relationship-building, constant communicating, and surveying are meaningless unless you can demonstrate and articulate how well you're doing. So we put a measure to the key outcomes that each customer had defined through the focus group process.

For each outcome, we filled in the statement, "The number or percent of ______ will tell us where we stand on this outcome." For example, if the outcome is e-mail availability, then the percent of time that e-mail is up and running is the measure. Not all of them were that easy, but when you break down the core of what our customers care about, most were easier to measure than we originally thought.

Every customer now had a measurement-based SLA with between 12 and 30 metrics uniquely developed by them. We spent six months establishing baselines for service delivery prior to consolidation.

Then we tasked our managers with finding gaps between where service was and where it needed to be, and worked to show noticeable improvements to the baseline. We also demonstrated that the quickest way to get a budget item for your department was to tie it directly to an improvement in an outcome measure.


Step Four: Clearly communicate
It's not enough to know your measures. It's equally important for the first few years that your stakeholders know them, understand them, and can communicate them to others. We felt that in order to get past the daily operations detail, we needed to communicate with leaders in the organization, not managers.

Organizing senior-level leaders to meet quarterly to review performance and set targets fostered partnerships and built credibility as each quarter they saw consistently high availability and reliability measures. (Of course, that's assuming you are performing well in these areas. If not, stop reading now, put down the magazine and fix your systems.)

Slowly over this first year, the scrutiny over each measure has given way to trust and eventually empathy. When you sense that your customer no longer cares about communicating network metrics, go out and celebrate. You have now established a level of trust enjoyed by your local utility providers. You might argue over costs and issue response times, but the fact that you no longer discuss how often the power is on is a huge victory.


Accountability, the Two-Way Street
The measurement-based SLA has been a phenomenal tool for us this first year. From the departments we serve, we hear an appreciation for our willingness to expose the organization in a real and tangible way. They feel empowered and emboldened to address issues when they arise. They can, and have, pointed directly to a measure and asked, "How often will this happen?" or, "What are you going to do about this next month?"

It's a document that holds us accountable in a way our managers have never been before.

At the end of the day, when the measures show improvements to availability, reliability and efficiencies, it's hard to argue that consolidation hasn't been fruitful for their department. When there is a question about a problem area, the baseline data clearly demonstrates if the problem was created or inherited. It simply holds everyone accountable to what was occurring when the IT resources were on their watch.

With all the accountability, these documents may seem to be another weapon for the weekday warrior. However, managing by numbers is the best way to neutralize any hostility and springboard into discussions about demonstrating value when IT costs continue to skyrocket, bridging the gap between technology and business, and convincing 14 Cabinet members to support a multimillion dollar investment in the next-generation network for the state. Ironically the easy part of consolidation is the actual delivery of services. The difficult task is how to clearly and effectively measure and communicate that delivery in a meaningful way that bolsters confidence and upholds accountability.

One day we hope to be like the electric company: a trusted partner powering the factories of our state government. Our goal is to move from the 30 measures in some departments to the absolute key measures of application availability and product delivery. The playbook for that is still being written, but during this first year, when communication and relationship-building was so key to success, these plays worked well for us, and moved us with purpose toward our vision of being the absolute best value in technology services and solutions.


William Bott currently serves as the deputy for operations to Missouri's chief information officer. In this role, he spearheads the division's strategic planning, performance measurement, project management, customer relations and enterprise architecture initiatives.

Prior to his role overseeing the operational side of Missouri's IT consolidation, Bott worked for the previous three administrations as a process improvement consultant and change agent, and with the Department of Defense where he earned the United States Air Force Civilian of the Year Award in 1996 for his efforts to improve systems and reduce operating expenses.