One of the biggest challenges IT leaders face in a multi-vendor outsourcing environment is getting all the suppliers to speak the same language. Service providers today will typically follow Information Technology Infrastructure Library (ITIL) guidelines around basic IT activities such as incident and change management—and most customers require that their vendors do so — every party has its own interpretations of those guidelines.
[ Related: 7 questions to ask before implementing ITIL ]
Wipro may manage and incident slight differently than HP, which in theory doesn’t sound like a major issue. But for a large global organization managing thousands of incidents a day, even a slight variance in reporting becomes a big deal creating significant complexity for the client and compromising standardization. “The issue is that the standards describe what has to be done… but not how those things are done. The result is that the standards mean slightly different things to different people,” says David England, director with outsourcing consultancy Aslbridge. “So when different providers execute and report those tasks and functions, inconsistencies result. And those inconsistencies create problems.”
[ Related: Should you outsource vendor management? ]
What happens —very quickly — is that instead of collecting consistent and useful operational data that could drive continuous improvement, outsourcing customers are dealing with sloppy data that limits their ability to effectively govern their outsourcing portfolio. “It’s that there’s one big issue,” England says, “but rather it’s a case of death by a thousand cuts.”
An effective solution is for outsourcing customers to come up with a clear definition of the processes they want their vendors to follow and make sure that all providers understand the terminology and requirements precisely in the same way.
Creating a Statement of Work for service providers
That effort should be a priority when creating the Statement of Work (SOW) documentation that defines the tasks for the service providers. More often than not, that SOW will stipulate that “all providers adhere to ITIL definitions.” Instead, says England, outsourcing customers should get much more specific about ITIL definitions in the SOW “and specify, ‘this is what we mean by incident resolution and this is how incidents will be reported.’”
[ Related: Why companies opt to insource for IT innovation ]
Providers are amenable to adhering to client definitions if the requirements are clearly spelled out, says England. “It’s not that one approach is necessarily better than the other, it’s just that they’re different in an apples and oranges way. And effective governance absolutely requires apples to apples and oranges to oranges.”
Without any client direction, for example, Provider A might consider an incident closed when the technician reports the incident resolved. Provider B, meanwhile, may call the incident closed when the user who reported the incident indicates that it’s resolved. That seemingly slight difference had a significant impact on the performance metric of incident resolution time.
Provider A’s definition of resolution time results in a much shorter resolution time than Provider B’s approach, because it doesn’t account for the time it takes the end user to send an email to close the incident. At the same time, Provider A’s approach doesn’t account for situations where the technician closes the incident, but the user is still having a problem. To prevent that issue, the client could specify in the SOW that an incident is reported closed only once the user signs off on it. That results in consistent and clean data that will give the client and provider metrics upon which to base performance improvement efforts.
This will require some extra work form the outsourcing customer at the beginning of the agreement; how much extra work depends on the IT organization’s own ITIL maturity. “Mature organizations will have detailed, well-defined, and proven standards that can be directly incorporated into the requirements,” says England. “For organizations that lack this level of maturity, it can take anywhere from a few weeks to a few months to develop appropriate standards.”
Defining standards is boring but necessary
England recently worked with a global manufacturing firm contracting with a trio of IT and business process outsourcing providers on an end-to-end outcome-based IT transformation. In preparation for the start of the collaborative relationship, the company clearly defined the operational service management standards, processes and tools that would be used by all three suppliers. In addition to the service management details, they also defined the governance standards, processes, tools and joint vendor governance meeting structures that would be used. “For organizations seeking the benefits of true outcome-based solutions, getting these fundamentals right is an essential requirement,” says England.
Defining standards can be an arduous task for the less experienced IT organization. “It’spretty boring stuff,” says England. “[However], boring as it may be, that attention to detail is critical and directly affects the ultimate success of the outsourcing relationship.” Any IT organization can ultimately clarify standards. What’s prevented them from doing so in the past is not necessarily a lack of capabilities, but a lack of awareness. Many customers failed to recognize the importance of a “deep-dive effort to drive standardization” says England. “In other cases they lack the expertise or the internal resources, so it’s something that slips through the cracks.
We do see clients starting to recognize the importance of getting that operational foundation right in order to achieve the value from the relationship that they seek.” The good news, adds England, is that once these processes are defined, they’re relatively easy replicate and apply to new service providers that enter the IT outsourcing mix in the future.