Managed Services in The Modern Economy – Part 3

In Part I of this series, we reviewed the main types of Managed Service Provider (MSP) contracts, common expectations of MSP’s in today’s economy, and the importance of defining clear expectations as the backbone of a healthy MSP vendor-customer relationship.  In Part II, we reviewed typical challenges and the benefits MSP’s can provide to address these challenges, focusing on Monitoring and Operations engagement types.

In Part III of this series, we will focus here on Optimization and Transformation engagement types, one of which extends beyond traditional operational engagements and requires an MSP to possess a broad range of skillsets to deliver business outcomes.

Managed Services for Optimization

To benefit IT and the business, in addition to taking responsibility for ongoing monitoring and operations, an MSP can also take responsibility for ongoing environment optimization.  In this engagement type, in the natural course of supporting and managing the in-scope environment, on an ongoing basis an MSP will also identify and address any risk areas within the managed environment; i.e. areas that need to be optimized.

I will start with an analogy, wherein I’ll draw upon one of my prior hobbies as a licensed amateur motorcycle road racer:  I raced a Suzuki GSX-R 600 and thereafter an SV-650, and whenever I took my bike into the shop after a race weekend, I was fortunate to have a great mechanic who would always get the engine and the bike back in good working order, running the way it was supposed to run – that is operations.  In the course of routine maintenance, he would often notice things that could improve the bike’s performance potential via better components and/or enhanced tuning (but he would not do those things without first informing me of the benefits, and of the cost and time required) – that is optimization.

Bringing it back around to our topic here, recall that in Part I, we provided an example of a customer who deployed many VMs on their hypervisor hardware cluster and those VMs were allocated a generous amount of cores, RAM, and disk space, but over time it became evident the allocated resources significantly exceeded what was actually needed.  In this example, nothing was “broken” per se, yet the environment was not in an optimal state, and an optimization effort was required to address.

To address this example, an MSP would identify and document this problem, bring it to the customer’s attention, propose a solution, review the benefits of implementing the solution, and review the time and effort required to do so.  Armed with this information, the customer would weigh the benefits vs. the time and effort, and make an informed decision.  This overall workflow is encapsulated in a standard problem management process, which a good MSP will have helped to establish as part of their engagement.  This is one of the core ITIL processes Ferroque Managed Services reviews and establishes during onboarding.

In practice, the MSP would follow the established problem management process to document problem details in a problem ticket, highlight in a monthly or quarterly report, and review in a problem management meeting.  Upon receiving the customer’s approval, the MSP would then mobilize a team to conduct an operational project to address the problem.  Note that this is a subtle point that often distinguishes the quality and experience of a fair vs. a good MSP:  beyond having solid technical resources who can resolve incidents, perform changes, etc. a good MSP will also have in-house resources who can apply the practical application of the problem management process plus have the knowledge and experience to properly initiate, plan, execute, monitor/control, and close such a project.

Sometimes areas in need of optimization are obvious and easily identified, and sometimes they are not.  This is another subtle indicator that can highlight the experience of a fair vs. a good MSP:  in the natural course of supporting and managing the in-scope environment, a good MSP will maintain a log of potential problem areas (could be in the form of a risk register or a technical debt register) and periodically review the log file to determine areas that are the most significant (e.g. similar to risk analysis, such as weighing probability and impact).  Additional sources of identification include incident ticket analysis; e.g. on a quarterly basis, analyzing incident area (category), severity, and volume to identify the areas that have the highest volume and/or severity of incidents, and thus may need to be investigated and optimized.

One item of note here:  although optimization may leverage the problem management process to address areas in need of optimization, ITIL defines a problem as an incident with unknown cause; in these examples, there may not be any incidents because nothing is “broken” per se, so the term “problem” is being used as a generic term here (i.e. not a “problem” in the ITIL sense).

As we can see, to benefit IT and the business, an MSP can take responsibility for ongoing optimization of the managed environment.  Keeping the environment in an optimized state makes it more readily able to power new business initiatives; for example, a more extensible environment that can more readily incorporate new technologies to provide a strategic advantage, and an environment that is more resilient (due to less technical debt) with higher levels of availability and consistency.

Managed Services for Transformation

To benefit IT and the business, an MSP can also go a step further to engage with customers in a transformative fashion, which is a method of engagement that extends beyond operations and into the realms of business and architecture/engineering.  A transformation engagement is measured in business outcomes as well as in traditional operational outcomes.  Considering that operations and architecture/engineering are two sides of the same coin, engaging in a transformative fashion provides a more organic workflow that often has a bit of a “sum is greater than the whole” effect.

This occurs because, during the natural course of supporting and managing an environment, the operations team naturally develops an intimate understanding of the environment’s configuration and of its strengths and risk areas.  Thus, such a team is well-positioned to provide guidance to plan and design new solutions and to identify and implement the technologies that most effectively enable those solutions and are a good fit for the existing technology landscape.  In this fashion, an MSP bypasses the typical learning curve (both technical, as well as organizational structure and culture) that must be overcome when engaging with a third-party consulting team, yet still retains the benefits of having an “outside” team who can bring to bear a wide breadth of industry visibility and experience for their customers.

To do so, an MSP will meet with business group leaders in semi-annual or annual intervals.  Typically, an annual meeting will occur to review the business group’s major objectives and milestone goals for the ensuing 12-18 months and to jointly develop a roadmap for achieving milestone goals and the timeframe for doing so (the timing of these meetings often follows the company’s annual planning wherein strategic corporate objectives are outlined).  An MSP may also meet with business group leaders on a semi-annual basis to review progress against the roadmap, understand if there any course corrections in the business group’s objectives, and refresh the roadmap accordingly.

A critical task for the MSP is to review each business group roadmap to spot commonalities (such as shared/common needs), distinctions (such as unique needs), and potential risk areas, and coordinate a central roadmap that charts a path forward for the IT environment that supports the needs of all business groups.  Such a roadmap will then be reviewed with business group leaders so the business and IT have a common frame of reference (expectations) for how the company’s technology investments will be used to enable business group goals, and by extension strategic corporate objectives.

Once a central roadmap has been defined and agreed upon, various projects will be initiated and executed to design, build, validate, and deploy the solutions contained in the roadmap.  Typically, an MSP will conduct these projects via their in-house consulting practice, so that their in-house MS practice can continue providing daily operational support and management without disruption.  And since both practices are part of the same MSP vendor, a built-in collaborative ease exists across these in-house practices, which provides tangible benefits to the customer (such as enhanced efficiencies and economies of scale).

Note that the preceding paragraphs outline a practical process for how an MSP translates strategic corporate objectives into specific outcomes, and provide a method for managing the ongoing alignment of individual initiatives with steadfast corporate objectives:  it is normal and reasonable to expect the need for unplanned efforts to arise, and a central roadmap provides the guardrails that enable such efforts to be addressed (e.g. via projects) while still continuing to move the business in the intended overall direction.  This process follows a natural flow that serves as a template for incorporating various business objectives and strategic initiatives, as depicted in the following diagram.

As previously mentioned, business outcomes are part of the success measures for a transformation engagement, thus as we can see an MSP becomes involved early in this process to help business group leaders craft a gameplan for translating top-level corporate objectives into tangible outcomes.  In this process, an MSP acts in a consultative capacity primarily in the following areas:

• Working with business group leaders to define business group roadmaps.
• Analyzing requirements and timeframes contained in business group roadmaps to draft a central roadmap containing proposed solutions, milestone goals, and timeframes.
• At the project level, helping to define work packages, tasks, and task sequences.

As we can see, a broad range of skill sets are required for an MSP to engage at the transformative level, including all the skills required to deliver traditional operational services (e.g. technical expertise, knowledge of core ITIL processes and how to apply in practice, SLA/SLT management, etc.), as well as business savvy, technology consulting, and project management skills, and the ability to orchestrate these skillsets to deliver in a seamless fashion.  For this reason, not every MSP is able to engage at the transformative level.  Ferroque Managed Services has in-house resources who have years of enterprise experience and accredited certifications in multi-cloud, Microsoft, Citrix, and VMware technologies, ITIL and Lean Six Sigma processes, and PMP and Scrum project management.

Since a transformation engagement incorporates multiple engagement types, it is important for the MSP contract to clearly define the various efforts that constitute operational, optimization, and transformative responsibilities, particularly as depending upon contractual details, there may be a ceiling associated with the annual volume of permissible optimization and/or transformative effort.

To be continued…

This post outlines the benefits an MSP can provide to address the challenges outlined in our previous post, focusing on optimization and transformation engagements.  In our final post in the series, we will conclude this discussion by reviewing the indicators customers can use to understand if they are getting the most value from an MSP engagement, and how MSP’s can interpret unspoken signals to understand if they are doing a good job.