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.
Labels: Change Management, ITIL, ITSM, Service Management, Service Management Reporting