When IBM purchased Silverpop (a marketing automation company), they combined Silverpop with other acquisitions (Unica, Coremetrics, Xtify, and Tealeaf) to create "IBM Watson Marketing". My role during this amalgamation and transition, was to unify the services delivery model for the new organization. Once the formation of the new entity was complete and chartered with a new mission, I assumed the role of "World Wide Services Go To Market and Offering Management Leader". GTM and OM, respectively.
I had been informally responsible for some of the GTM and OM work streams in previous roles, but this was the first time I owned all of it. Upon doing some research and talking to industry experts, I quickly realized that there was a lot of new and necessary process needed to make GTM and OM for services a successful practice. I also realized that these new processes were very foreign to my counterparts in solution sales and services delivery. It took a lot of training and convincing for people to adopt GTM and OM for services as the new paradigm of "best practice". Here's how I broke it down for them:
A Long Title Explained
Why was my title the leader of "Go To Market and Offering Management"? What's the difference? To explain the difference in GTM and OM, I like to think of it like this:
OM (Offering Management): From conceptualization and research to development.
GTM (Go to market): From development to launch planning to sales and marketing.
So for this context, OM is basically everything other than the sales & marketing when considering a product/service being created and managed. Granted, this isn't to be confused with how organizations holistically view OM and GTM, but it's a good reference point for how we consider it when prescribing certain activities and discussing the importance of each.
A House in Disrepair, Looking For a Fix
In just about every service organization I've spoken with, the management team has a pretty firm handle on how they measure service delivery performance. Be it utilization, on time / on budget, NPS, gross margin, etc., once services are in process, there is plenty of measurement and scrutiny. What inevitably happens though, (and a complaint I hear time and time again), is that these core delivery performance metrics are difficult to maximize and goals are infrequently reached:
Utilization is low or varies wildly week over week, resource by resource
Projects always run late or take too long to start
Clients are less than satisfied and don't renew perpetual services
More hours are burned vs. estimated resulting in poor margins
There are either way too many or too few resources at any given time
When I ask enough questions about the "why" behind each of these, I get taken down a path from "it's the customers fault", to "we don't have the right tools", to "managers aren't holding folks accountable", to "sales over/under sold", to "we don't really know." Then when I dig into the planning process that went into the service definitions or scope derivation and estimation, we start to uncover the real issues. 99% of the time, there was very little planning and analysis that went into the service offerings.
A Strong Foundation Weathers Any Storm
Probably the single most valuable effect of OM for services, is that it creates an auditable, referenceable, iterative platform to continuously improve your practice from. Think about it like this. If you take the time to thoroughly scope a service that you want to offer, breaking it down incrementally into each underlying task to be completed, and you analyze the LOE "level of effort" for each task (resource, time, duration, dependencies), you'll be able to come up with a plan that can be assessed and refined continuously. That enables you to create a foundation upon which all measurement and refinement is based. And no matter how inconsistent your delivery performance or resource management becomes, you have a reference point to alter and improve which will ultimately create gains as you move forward. So if the current method of creating a service offering looks something like this:
Most tenured or "best" resource creates the basis for a new service offering
That same person takes an educated guess at how many hours are needed to complete the service and over what duration
That same person or manager comes up with a price
It gets rolled out to sales
Things don't work out as planned and you point fingers or start over or both
Try a new process like this:
New service offers come from a consortium including sales, CS, product marketing, and the collective input of service practitioners
The service is scoped by each resource group that would need to complete certain tasks and a consensus LOE estimate is created
The offer gets rolled out to sales (hopefully by a service GTM lead, but more on that in another blog)
Things work or don't work and it's easy to go back to the initial offer creation and see what's misaligned, adjust, and update the offer.
The First Steps
Obviously there is a lot to unpack in this concept of services OM. To some extent, this is still a new concept and there aren't many tools or technologies on the market that help service leaders with this part of their business. At Ridare, we are filling that gap, but our technology is born out of proper process. We make the whole process easier and with greater control and scalability. But the process and methodology is the most important part. After all, I managed my services business at IBM without the benefit of Ridare and you can too.
So the first step that any organization should take when exploring OM is to catalog all of the current service offerings and determine which offerings they want to continue with in market. Once those are identified, performing an LOE assessment on each offer. Compare them to the delivery performance and it will show you where some of your assumptions are missing the mark. You can then update your offerings (price, scope, terms, etc.) and relaunch them. It should also help you create a new motion when developing future services.
Comments