There are many ways in which you can develop your Service Management process. The best place to begin is to look at current state and perform a gap analysis of where you want to be. This will provide a roadmap for your Service Management journey.
Think in terms of your IT teams.
If you were to poll a room of IT Operations people whether they think that their Service Management processes were mature, effective and providing value you might find two basic types of replies:
- From people who had been with the same organization for a number of years – they might suggest something along the lines of “things work pretty good, a few years back they were pretty messy.”
- From people who had only been with the organization for a shorter time frame– “compared to my last job they seem to be about the same.” They might also indicate that the ITSM tools that they have been exposed to have improved or worsened.
The big challenge is that they did not mention the level of value.
Value you say? It is entirely possible that IT Operations are not even aware what would equate to business value. The prime reason for this is that we do not rate IT success in terms of “how we deliver on business outcomes”. The way that Operations are evaluating service management is from an internal IT vantage point. In short, the processes seem to be working as good as we think they should be working.
If you were to ask a room full of Development people you might find there replies might be similar, even if slightly different:
- Ask a room of predominantly agile developers and they might tell you that the processes don’t allow for the quick deployment of releases that they say would add value to the business
- If you asked some fans of waterfall deployment they might suggest a similar sediment as their agile kin although their complaint is that while the processes can handle the timeframe of work there may be higher levels of bureaucracy to cover off the larger releases due to higher associated risks.
While there was mention of value it really only spoke in terms of what we can fix today. It doesn’t really speak to any long term value, for example if there are any issues with either agile or waterfall deployment styles.
For both Operations and Development we need to look at our core Service Management competencies and where that fits against deliverables.
An easy way to identify gaps is through the current reporting. What does our reporting tell us (or not tell us) about our ability to deliver service. Some obvious items that tend to surface might be:
- No failed changes last month. How many did we do? However we still see incidents.
- Low number of critical incidents versus a high number of emergency changes.
- Steadily increasing number of incidents or requests with no known driver behind them.
I chose these particular examples simply because most organizations have implemented these processes. In the upcoming parts we will take a closer look at some of these and some remedies for them.
See Part 2 Increased Number of Incidents With No Driver