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.