Home �   ITIL�  Index

Why MSPs Struggle with ITIL

Mar 5, 2007

Mike Drapeau,Steve Loftness

  • MSPs typically provide their services for just a handful of outsourced services (e.g., remote e-mail management), not the entire IT department. Since MSPs usually have more mature ITIL capabilities than their customers, they often face a challenge of integrating their more robust processes and workflows into a less well-defined and managed ITSM environment. The potential for conflict is great.

  • Lastly, since MSP services are delivered in tandem with the customers own ITSM services, the result can be skewed metrics that reward the wrong behavior.

    Pink Elephant cites one example where Incident Management overall efficiency is sacrificed because an MSP is limited to help desk tasking and is precluded from contributing to activities like incident reduction and mitigation. The result is they are not rewarded for behavior that helps the complete process, only their slice.

    Why MSPs are Different

    In order to better appreciate the magnitude of the challenge that MSPs face when adopting ITIL disciplines, let’s first explore how their IT operations differ from those of internal IT departments with regard to ITSM:

    SLAs for MSPs are risk-based documents. The customer of an MSP is a client purchasing services on a contractual basis. The SLA/contract an MSP must follow can involve penalty dollars and other legal implications. This is real risk as opposed to the "funny money" of internal chargebacks; one of ITIL’s recommended accounting constructs.

    SLAs are more important to the MSP than to the client. For an MSP, the client equals business survival. Any document that governs that relationship will trump similar internal OLAs (operating level agreement) or even UCs (underpinning contract) with key suppliers. This imbalance often drives dysfunctional behavior on behalf of MSP staff dedicated to serving the client. IT Mangers in for an MSP need to keep up with the promise-generating machines in its marketing and sales department.

    The IT Service Catalog for an MSP is a real-world Chinese menu. It is not some abstract of existing IT infrastructure. Clients pay for actual services and care little about the underlying technology. This is a wake-up call for most managers of internal IT departments. A further complication is the delicacy of costing information — MSPs have two audiences, internal staff who must see actual cost information and external paying customers who had better not.

    MSPs may or may not deal with their client’s own end-users. Unlike internal IT shops that have a service desk for company employees, MSPs may not have to handle inbound calls. If they do, it is usually an additional contractual arrangement.

    MSPs do have a client-facing service desk deal with their IT counterparts. This arrangement requires a greater degree of technical knowledge, more coordination, possible business risk, additional and more elaborate forms of communication, and even different entry points into IT than anticipated in a "vanilla" ITIL Service Desk guidance.

    On one hand this is a plus, as fellow IT professionals will usually not waste staff time with computer reboot requests. The dark side though, is an MSP’s service desk staff must be significantly more technical savvy than what is typical for the industry. Such staffing considerations merit re-designating the role from service desk analyst to something more exalted, such as a “technical account manager."

    There is usually not a common goal to align the MSP’s IT shop with its clients. In fact, the MSP’s client will likely have different purpose, values, mission, and vision. This means, in some sense, MSP IT departments have to align with their own marketing departments, the closest thing they have to a customer for their IT Services.

    MSPs have two levels of configuration items (CIs) to handle. The CMDB will need to be, literally, "two-faced" as the CIs used by internal customers are separated from those used to provide services to paying clients. In addition, in some cases, MSPs may have to record some of the client’s infrastructure components in its own CMDB in order ensure Change Management integration.

    Caveat Venditor

    The sum total of these differences with regard to ITIL best-practice is simply this – caveat venditor (i.e., ITIL implementation staff beware). Any ITIL implementation at an MSP takes on an almost schizophrenic character; carefully segregating and separating IT services devoted to internal customers under "internal" SLAs from those delivered to external customers under "external" SLAs.

    The picture gets further muddied when and if the MSP is sharing infrastructure and IT services between these internal and external communities. There are precious few organizations that can maintain clearly distinct service delivery capabilities under these conditions.

    As ITIL puts it, organizations should “adapt and adopt” its best practices. With MSPs it is no different, possibly with the exception there will be more adaptation than adoption.

    The ITIL framework can be used by MSPs but not without some extra design and a reluctant recognition that most templates, workflows, policy documents, and other ITSM collateral produced by industry thought-leaders is not going to be applicable. Either that, or wait for version 3.

    Mike Drapeau is the president of an ITIL consultancy, the Drapeau Group in Atlanta, GA.

    Steve Loftness, a senior process architect with the Drapeau Group, also contributed to this article.