I was speaking with a colleague the other day and she was expressing her frustration over some issues she had with their change management process.
“Oh, what’s wrong with it?” I asked
She replied “That the process REALLY sucks.”
Seeing the open door to go through I asked her “What percentage of suckage are we talking about here, like 40 percent?”
Her frustration was replaced with a smirk but went on to say that realistically they are having some issues with application performance, which always seems to go back to changes gone wrong. She totally gets that since a large majority of incidents result from changes. She continued on to mention that the issues seem much worse as of late.
The first thing that I asked her was to take me back to the time when the process seemed to suck less. She said that it was about a year ago, and didn’t seem to get bad as a result of one thing. My next question was for her to explain what factors from that time until now may have contributed to the process breakdown. My suggestion was that she might need to go over her KPI’s and then let me know what she saw. I was specifically interested in:
- The volume of changes
- The number of expedited changes (if any)
- The rate of change success vs. changes which were not successful
I also wanted for her to think about the way in which the IT culture may have changed in that time frame. Has there been any change in the way in which IT is working with the business in the past year as well.
A few days later I checked in on my colleague who looked far more relaxed than the past time I saw her, but I could tell that most of the challenges she was facing started to make sense to her already.
She told me that after she took a step back with an objectionable view of the situation several things were clear.
1. While there was an increase in the volume of changes overall, the applications which saw the most issues had the highest percentage of expedited changes
2. That the rate of success seemed to remain the same despite an increase in reported issues
3. That the business units and IT have been on a less collaborative space since some internal org changes took place.
She continued to outline that one of the new directors in application development was previously at an organization which had a far more agile approach to deployments. This was apparently why there was an increase in smaller expedited changes.
My suggestion was to firstly ensure that the governance of the process was intact. For the most part it sounded as though with the exception of a few applications that the process was doing as it was meant to.
Quite often the trouble is that aside from the business saying that the applications were falling apart there was no linkage (related incidents) to these changes which were causing the issues. Because of this lack of relationship we may have simply overlooked our own issues. This is why not only pulling but analyzing reports is key. The incident and change management teams should be working closer together to identify these issues. Once they have some solid analysis they can take their findings and review them within IT. It may turn out teams may not be “ready” for agile delivery in this manner just yet. Just because some organizations are doing it doesn’t mean all are capable without some guidance and practice.
Lastly making sure that you go back to your fundamentals of service delivery and really talking with your business about what their needs are regularly. Don’t forget business needs change. If they really need more agile delivery then that should be part of our deployment strategy. Otherwise we need to reassure them that we are working to ensure that services are available to allow them to achieve their goals.
This gave my colleague something to think about. She was going to review this with her management team to start to streamline activities.