I spoke recently with a service delivery manager who was frustrated with his inability to make lasting improvements to his current service management processes, and it was impacting his ability to improve service delivery. I asked him where he thought the plateau might be originating, but he was unsure, saying that his change management process was really good. Good being a pretty subjective term, I asked him what good looked like.
He said that their Change success rate was through the roof—almost at 100%—but for some reason incidents were still coming up. Immediately an alarm went off in my head. He continued to say that even with the success of change management, the other processes couldn’t seem to make the same level of improvements.
It sounded as though the service management processes were attempting to operate in a silo even though that was not the intention. I asked him how he was planning to address the fact that incidents were on the increase despite a nearly spotless change implementation record. The lines in his forehead suggested that he was hoping I could help with that. I decided it would be best to share an example.
Assume for a moment that a challenge faced by your business (remember, it’s about them and achieving their outcomes) is that small issues seem to arise with regularity after IT implements changes. Sometimes these appear right away, while others seem to take a while to bubble to the surface. While some people might have the gut feeling that this issue was the result of the change put in last week, no direct relationship was established, and the Service Desk who receives the initial escalation may not be in a position to put the two together.
This is where having a collaborative approach to service management is beneficial
Breaking down Silos
If, as my colleague suggested, Change is the driver in all things service management, then the IT organization may look to the Change owners to connect the dots after changes are implemented. However, gathering the process owners (or those responsible) for each of the processes on a regular basis to discuss what is working well and what is not will lend itself to a practice of breaking down internal silos. In a discussion, the following dialog may occur:
- Change owners are quick to point out that these identified issues were small enough not to have been caught in testing or validation, and that in future deployments of this type this testing will be included.
- The Service Desk Manager indicates that the defect wasn’t identified right away, and when it was, it may not have been recognized as a result of the change completed due to misaligned timelines. Initially they created low priority incidents, which they forwarded to support teams.
- In receiving this multitude of incidents, the Incident and Problem Managers should have communicated to all parties to tie all things together. Unfortunately they kept the information close and worked solely with support resources to correct the issues.
Remember, the issue has already happened. We need to learn from this experience and endeavor to not have this happen again if possible. We should ask questions like:
- What could we do better next time?
- What have we learned?
- Configuration Management
- Knowledge Management
- Event Management
At the end of the day, IT has a goal to provide services. There should be no internal finger pointing with an “us vs. them” mentality. You need to collaborate with all the teams to ensure lasting success. You also need to ensure that all this is documented and shared with not only service management but in IT as well, to grow on what has been begun.
If you like these articles please take a few minutes to share on social media or comment