The following is excerpted from There’s No Such Thing as an IT Project: A Handbook for Intentional Business Change.
To succeed in the digital age, IT projects must be redefined to deliver business change instead of just information technology deliverables. But beneath this lies a more fundamental shift: IT operations should be just as embedded in business operations as IT applications should be embedded in achieving business change.
In many organizations, IT is run as if it were a separate business – a service provider for its internal customers. Unfortunately, doing so creates dysfunction for both the applications and operations sides of the IT house.
Part of this is because the IT-as-a-business metaphor has led to a strange practice: negotiated service level agreements (SLAs) between IT operations and its internal customers.
In real IT outsourcing terms, an SLA is a two-part metric. The first part is the minimum acceptable standard of service. The second enumerates how often the outsourcer has to achieve that level of service.
Defining the first part of the metric is often trivial. The second part, however, is more interesting. For example, an SLA might define the maximum acceptable standard for an outage to be one hour or less before restoration of service. The second half of the metric might specify that the outsourcer must achieve this level of service for 99 percent of all outages.
If the outsourcer fails to meet its SLAs, the contract specifies remedies, which are also a matter of negotiation. If internal IT is supposed to act like an independent business, what could be more logical than it negotiating SLAs with its internal customers?
As it turns out, the answer is: Lots of alternatives are more logical.
The innovation challenge
Internal SLAs were never a good idea for a number of reasons. First, they reinforce the wrong IT/business relationship model – that of IT-as-a-business selling to internal customers.
Second is a consequence of the difference: If IT fails to achieve a negotiated SLA, what will its “customers” do – sue? SLAs without non-performance penalties are futile. SLAs with non-performance penalties encourage inter-organizational distrust.
Third is the fact that you get what you measure. In most cases this means IT measures service levels but lacks any metric for innovation.
Well-run IT operations constantly balance between reliability and innovation. But innovation entails risk. Because SLAs look backwards, they only report the negative consequences of innovation, not its benefits.
Take the initial conversion to solid state hard drives. Their short-term reliability and long-term durability was, for early adopters, unproven. Yet they paid off handsomely for organizations that tried them, giving them a performance advantage in analytics and big data.
Staying on the leading edge requires some risk-taking and forward-thinking that SLAs by nature discourage.
The case against SLAs
IT typically takes on two types of responsibility: technical services and support services.
SLAs for technical services relate to matters such as system availability and performance. The problem? Once upon a time, high-availability architectures were a choice. Now they aren’t.
Should IT continue to track service levels for technical services? Yes, if it isn’t doing very well, but only as a tool to get it to where continued tracking would be a waste of time.
Because while a given piece of equipment might fail, that’s no longer a reason for systems to be out of commission. That’s the nature of high-availability architectures. If a system is ever unavailable, that should be a sufficiently rare event that keeping statistical track is a waste of time.
What won’t be a waste of time is a root cause analysis, because every outage means your high-availability architecture has a design flaw that needs fixing. What also isn’t a waste of time is analyzing reported incidents to detect and address emerging problems early, before they become detectable to the business at large.
Support services, on the other hand, are what IT staff do to assist those who work in business operations. Support services SLAs relate to questions such as how long someone should expect to wait before the help desk responds to their request and how long they should expect to wait until the problem is resolved.
On any given day, for any given call, the help desk either responds more quickly or less quickly than the service level specifies. It responds more quickly when help desk staff capacity exceeds the call volume. It responds less quickly when the call volume exceeds the help desk staff’s capacity.
As such, the SLA has nothing to do with performance. It’s just a stick that’s useful for beating up the help desk manager and not much else.
The only time it truly matters is budget season, when the help desk’s service level performance can be used to justify hiring more staff.
This is, to be fair, no small matter. But it justifies the practice of tracking service performance, not negotiating SLAs.
The only IT operations metric that matters
For most people in management, success increases their visibility, which can lead to promotion, accolades, and better pay. The only time IT operations is visible is when something goes wrong.
All good metrics are numerical representations of qualitative goals. So, the IT operations metric that best reflects its goals is a measure of its invisibility. This “invisibility index” should be a composite metric that encompasses application availability and performance, the number of calls to the help desk – fewer calls means more invisibility – and some measure that reflects how often IT operations performance is a bottleneck in other areas’ business processes and practices.
Typical IT organizations are divided into applications and operations, apps and ops, groups that traditionally distrust each other for two main reasons. First, apps succeeds by making application changes, but each application change creates a risk of increased visibility for ops. Second, apps needs ops to create and maintain dev and test environments. For apps, this means ops is a bottleneck. For ops, this means additional and often unscheduled work.
Enter DevOps. Unlike most agile variants, with DevOps, development teams include one or more IT operations staff to handle IT operations responsibilities collaboratively on the project’s schedule, instead of through an operations request queue.
All of this is to say that when there is friction or distrust between two groups that must work together, creating a collaborative blend of the personnel and processes under each group’s provenance is a worthwhile solution.
Digital transformation and the advent of BusOps
For most organizations these days, digital transformation is the drumbeat of management. But has there ever been a management fad more confusing and ambiguous than digital transformation?
Behind all the ambiguity are specific digital technologies that create new capabilities. Businesses can take advantage of them to create competitive advantage. Or, they can ignore them, letting competitors gain the advantage instead.
Behind the specifics is the central digital reality: Information technology is no longer optional. It’s deeply embedded in every business process and practice your company relies on to do business on a day-to-day basis. As a consequence, conceptually, IT operations is just one collection of moving parts among many in overall business operations, making it just as much the province of the COO as the CIO.
Before you get ahead of us, as a practical matter, wherever it reports, IT operations should remain intact. Its effectiveness (and consequent invisibility) depends on the ongoing collaboration of a number of technically proficient specialists – practitioners of mature and well-developed disciplines.
Managing the processes and practices they’re responsible for depends, in turn, on managers who understand their inner workings. Leading them depends on managers who can empathize with these practitioners as they go about handling their responsibilities.
It’s also worth recognizing that reorganizations rarely fix anything. Mostly they remove barriers by putting groups that didn’t work well together before under common management, which also means that most reorganizations create barriers between groups that used to have common management but don’t anymore.
Moving IT operations in the org chart so it reports to the COO is neither more nor less logical than leaving it where it is. As for restructuring IT operations, breaking it up and parceling out its responsibilities within the business just won’t work. There remains value in technical people working together on common problems.
What does need to change? DevOps points the way. The culture of DevOps collaboration has to extend to the relationship between IT operations and the rest of business operations just as it does between business managers who want to run things better and IT applications.
So unchain your help desk staff. With no SLAs to shackle them to their chairs, you can encourage them to get up and visit someone with an issue, learn about what their challenges are, and offer insights into how else they can take advantage of the technologies at their disposal.
Meanwhile, on the ops side of the IT house, agile needs fixing, also because there’s no such thing as an IT project: Agile as currently practiced still focuses on delivering a product and not on collaborating to deliver intentional business change. As you’re fixing agile, fix it more by adding the DevOps dimension of including system and security administrators on business change project teams. Your projects will have better outcomes, and the additional knowledge of what matters in business areas will make IT operations more effective in its day-to-day decision-making.
So let’s introduce a new term to make it official. Just as DevOps is the blending and collaboration of IT apps and IT ops, let’s start talking about BusOps as the blending and collaboration of IT operations and business operations.
The battle, according to Sun Tzu, is always for the hearts and minds. That often starts with vocabulary. By adding it, you just might be surprised — in a good way — at what comes of it.