More on core versus context

Earlier this week I ran an exercise to walk an executive team through a core versus context ranking. The exercised was designed to generate animated discussion towards a clearly articulated multisourcing strategy.

The exercise was moderately successful, but a few things popped out:

For starters I'll remind the reader (and myself) of the 4 quadrants I used for this exercise. These are as described in Geoffrey Moore's Darwin book.

The exercise I suggested was to create a catalog and inventory of services and then map them into these quadrants. I prepared a few examples and asked for dialog around what quadrant was most appropriate for each example service.

Service Descriptions are difficult to write

Not surprisingly, the first point of debate was around the definition of a service. I had carelessly described an example service as "Active Directory Administration." That caused a lot of confusion, because depending on personal perspective the service was interpreted differently. If you read that service statement as "user provisioning, access and control" it's mission-critical. If you read it as "system administration of the AD servers" it is arguably non-mission-critical. The important lesson here is that service descriptions need to be tightly written, and need to focus on the business value derived from a service, not the tasks required to deliver a service.

An obviously bad service description might be:
  • Active Directory administration
A better service description might be:
  • The organization provides a service (currently but not necessarily run through Microsoft Active Directory) to manage user credentials and single-sign-on logins for the global IT infrastructure. In provision of this service, new users must be added within 1 business day, password resets must occur in real time during normal business hours, and user accounts must be terminated with a one-hour SLA, 24X7. This service includes and subsumes all necessary procurement, topology design, software installation and maintenance, system installation and maintenance, and day to day operation necessary to provide this service to the business.
With that service description, there would be less debate about what was included in the notion of the service, though even with "24X7 " statements in the service description you might bump into the second lesson of this exercise:

"Mission Critical" is not intuitive or self-evident

As I led the discussion about where various IT and development services fell into these quadrants, the core / non-core part if the model seemed to be self-evident to everyone involved. Moore's description - which I paraphrased as "providing sustainable competitive advantage" - is clearly a good, easily internalized yardstick.

However there was much debate around what is and what isn't "mission-critical." Most of what I've read defines mission-critical with synonyms that mean "mission-critical." It's better to define it in terms of impacts to the business, and the pain threshold a business is willing to endure.

An application or service is mission-critical if its failure, cessation, or temporary absence results in unbearable negative impacts, such as:

* Financial penalties or significant loss of revenue
* Lapse of regulatory compliance.
* Injury or loss of life
* Severe degradation of operational efficiency
* Severe adverse public opinion or publicity

The frustrating thing for anyone attempting to use this methodology to inform their sourcing strategy is that it's an "onion peeling exercise." These business impacts listed above are only examples. These items align to the corporate identity and strategy, and as such, what is mission-critical for one company will not be so for another.

So the lesson is to first develop a rough guideline of the pain threshold you're willing to tolerate, and use that guideline to inform your M-C / N-M-C analysis. Your mileage may vary on what is / isn't mission critical, but I'd use the bullets above, and define "temporary absence" as one business week. That will help make it easier to slot items into mission-critical or non-mission-critical.

Missing some important data

The last lesson from this strategy-building exercise is that the quadrant analysis may help you decide what reasonable outsourcing or multisourcing targets you have in your portfolio, but it doesn't necessarily help you prioritize.

It would be tempting to say that you'd go counter-clockwise from quadrant 4, first attacking N-M-C context, then N-M-C core, outsourcing and freeing resources accordingly.

However, it might be more appropriate to look at areas where you can get good bang for the buck, as well as areas where you don't have core competencies or skills to match your aspirations. Hence, I think a couple of modifications are necessary to make this model work well.

First, I'd suggest "surface area" modification to the service inventory. This data may be hard for organizations to track down, but when you inventory your services, also note the estimated dollar amount (fully burdened) that providing the service costs your organization. Then, represent the service as a "dot" where the size of the dot is proportional to the amount spent on the service. Spend $25M on managed network services, you have a big circle. Spend $50,000 a year on managed network services, and it gets a small circle.

Then, you can quickly visualize the "low hanging fruit" in your service portfolio. It may not be prudent to begin an effort to outsource non-mission-critical context if you can only save a very small amount of money or free up a very small amount of time through the effort.

Lastly, this model doesn't represent an organization's core competencies, just their core services. If you aren't very good at providing Enterprise Messaging, then maybe you should consider augmenting your skills through outsourcing as a high priority. A simple modification, encoding the service with your organization's capabilities, will produce another visual representation that will allow you to quickly scan for high priority areas. You can do this by a "gut feel" ranking of core competency, as good (green), moderate (yellow) or bad (red). Obviously, large dollar, low competency areas should be addressed with priority, regardless of what quadrant they fall into.

This model would produce a visual representation like this:

In this model, it's probably more important to have an approach to solving the lack of skills and competency in Service 1 than it is to free up the resources delivering Service 4.

So in this case your outsourcing strategy needs a statement of how you would augment skill in new service development, either through outsourcing to a qualified firm or outsourcing through M&A activity with some attractive start up in the space.

At any rate, the model generated excellent debate. This can be used to build consensus, and also to inform a strategy. With the modifications I suggest above it can help prioritize what areas of your organization you view as viable targets for outsourcing, staff / skill augmentation, etc.

No comments: