The Balanced Improvement Matrix

Two weeks ago I presented to a customer how their IT improvement program can be improved by adopting principles from ITIL. I used this slide to illustrate another way to think about the issue.

Benefit-Change-MatrixClick to expand

Recipient of Benefits

The Y-axis who receives most of the immediate benefit of the activity. “Inside” refers to IT, either a component of IT or the entire department.

Outside refers to the outside stakeholders for IT services. Generally they fall into one of these groups:

  • Users: those who directly use the services. Generally the users also request the service.
  • Internal customers: those who request or authorize services on behalf of the users. Generally customers are the users, but sometimes they are distinct.
  • External customers: The ultimate customer who exchanges value with the organization.

Focus of Change

The focus or perspective of change describes where most of the change or improvement takes place. We are also describing this as within IT or out of IT.

The change or improvement may or may not be limited to the primary location. There are often spillover benefits for related stakeholders that are less immediate.

Examining the Quadrants

Inside-In

This quadrant describes change or improvement activities that are limited exclusively to IT. Some examples may include:

  • Code refactoring
  • Recabling
  • Process improvement
  • Service Asset and Configuration Management
  • Training

Inside-In activities may be thought of as “charging the batteries”.  External stakeholders will not see immediate benefits, but the benefits will accrue over time as the IT organization becomes more agile, flexible, efficient and effective.

Inside-Out

Inside-Out activities are those that modify the behavior of external stakeholders in order to maximize the capabilities of IT. Some examples may include Demand Management and Financial Management of IT Services, specifically charging for IT services in a way that encourages their efficient use.

Service Catalog Management and Service Portfolio Management also create activities in this quadrant, specifically those that describe prerequisites or costs to external stakeholders.

Outside-In

Outside-In activities are those that benefit external stakeholders by modifying the services or processes of IT. Service Level Management sits firmly in this area. The Service Improvement initiatives within CSI certainly fit here too. Alignment of IT with organizational strategy also reside predominantly in this quadrant.

Outside-Out

Does IT ever perform Outside-Out activities? With a few exceptions, yes, all IT organizations do.

Outside-Out efforts or improvement activities take place whenever IT acts as a consultant to the organization by bringing its unique capabilities and resources to business problems.

Some examples may include:

  • Strategic planning
  • Creating new lines of business
  • Due diligence of partnerships or acquisitions
  • Enterprise Risk Management and Business Continuity Planning

From an ITIL process perspective,  Outside-Out quadrant is best illustrated by Business Relationship Management (SS) and Supplier Management (SD), and some activities of Change Management (ST) and Knowledge Management (ST).

Optimizing the matrix

In no case did we ever claim that any one quadrant is better than another. IT departments of the last century received criticism for focusing too much on inward benefits and losing focus on the broader context in which IT operates. That situation was expensive, frustrating to users, and ultimately untenable.

IT organizations in this century must and do perform activities in all four quadrants. Neglecting any quadrant can lead to the following outcomes.

Benefit-Change-Neglect-MatrixClick to expand

Using frameworks such as ITIL, COBIT 5, or ISO/IEC 20000 to guide improvement initiatives can help IT organizations balance their efforts in all quadrants.

Improvement in COBIT 5

In a previous post I discussed starting your service or process improvements efforts with Continual Service Improvement (or just Improvement).

I prefer COBIT5, and the issue is ITIL. The good news is the Continual Service Improvement is the shortest of the five core books of ITIL 2011. CSI defines a 7 Step Improvement Process:

  1. Identify the strategy for improvement
  2. Define what you will measure
  3. Gather the data
  4. Process the data
  5. Analyze the information and data
  6. Present and use the information
  7. Implement improvement

This method, as the name suggests, is heavily focused on service and process improvement. It is infeasible in situations where there is no discernible process, a complete absence of metrics, and a lack of activity that could be captured for measurement and analysis. It is infeasible in most services and processes described in most organizations, due to this lack of maturity.

I find the COBIT5 method is more flexible. It also provides 7 steps, but it also views them from multiple standpoints, such as program management, change enablement, and the continuous improvement life cycle.

For example, the program management view consists of:

  1. Initiate program
  2. Define problems and opportunities
  3. Define road map
  4. Plan program
  5. Execute plan
  6. Realize benefits
  7. Review effectiveness

COBIT5 provides a framework that is more flexible and yet more concise, but still provides detailed guidance on implementation and improvement efforts in terms of a) roles and responsibilities, b) tasks, c) inputs and d) outputs among others.

Therefore I find the COBIT5 framework, particularly the COBIT5 Implementation guide, superior to the Continual Service Improvement book of ITIL 2011.

In addition COBIT5 provides a goals cascade that provides detailed guidance and mapping between organizational and IT-related goals and processes throughout the framework that may influence those goals. The goals cascade is useful guidance for improvement efforts, but alas it is the subject of another discussion.

Starting With Improvement

At last week’s Service Management Fusion 12 conference, I attended a brief presentation on Event Management that left a lot of time for questions and answers. One of the questioners had an ordinary concern for organizations starting down the road of “implementing ITIL”: where should we start?1

In this case the speaker demurred using ordinary consultant speak: it depends on your organization and objectives. Event Management supports Incident Management, and that is where many organizations start their journey. I raised my hand and offered a brief alternative: start with Continual Service Improvement (CSI). I didn’t want to upstage the speaker, so I left my comment brief and exited for another speaker whom I also wanted to see.

The 5 books of ITIL imply a natural flow: Service Strategy leads naturally to Service Design. Services are then ready for testing and deployment as part of Service Transition, which will then require support as defined by Service Operations. Once in production, services can be improved with Continual Service Improvement.

This is a natural life cycle for individual services and processes, but ITIL never says services or processes should be improved (or defined) in this order. In fact, ITIL does not offer much guidance on this at all. Because of this, and because organizations are all unique, each organization needs to define its own road map. CSI is one tool for doing this.

I encourage organizations to assemble a board to oversee the development and improvement of service and processes. The board may consist of stakeholders from IT and other functional units that depend heavily on IT’s services, as well as executive management who oversee them. The composition will vary by organization, and would meet quarterly or monthly.

The board’s agenda will include several items, including upcoming projects (new services), reviews or assessments of service and process maturity (if any), reviews of user satisfaction surveys or interviews, and review of existing implementation and improvement efforts. Most importantly, existing performance metrics should be summarized and reviewed. Care should be taken to avoid making this a project review meeting. Instead the focus is on the assessment and maturity improvement of overall IT services and processes in order to guide future development initiatives.

The board serves several purposes:

  • Ensures the prioritization of implementation and improvement efforts receives feedback from a variety of stakeholders.
  • Ensures there is a method or process for implementing and improving services and processes.
  • Provides a forum for reviewing service and process maturity.
  • Provides a mechanism for reviewing service and process performance metrics with various stakeholders.

This concept of a governance board presented here may not apply to all organizations. I have applied it only to one organization. For IT organizations who are challenged with immature service definitions (lack of a Service Catalog), poor operational dialog with other business units, or poorly understood maturity of services and processes, the board is one mechanism for prioritizing and overseeing the improvement efforts.

I emphasize both concepts of implementation and improvement. The practices presented in ITIL v3/2011 are more complete and mature than most IT organizations. In fact I have encountered few organizations with maturity in more than a small fraction, and even fewer with usable performance metrics. Most of the time we start with implementation, because they have too little to engage in improvement, but the improvement board should still oversee and prioritize the implementations.

1 ITIL as a framework cannot be “implemented”. However, we can engage in improvement efforts using the framework as guidance.