Change Management - What do you like about yours?

I've recently complained about the change management process at my current workplace, suggesting that it more of an obfuscation process and at best a change notification process (for management almost exclusively) and does not manage risk or change within our business, at least from infrastructure perspective. These comments have earned me a one-on-one with our change manager to discuss the process and how it can be improved.

I've got quite a few examples of why I think it's bad and how we could improve, but I'd like to hear some opinions from others about what they like about their change process.

I'm looking for things similar to;

• Automated communication to subscribers of effected CI's upon change implementation and change completion.
• Peer review, improving overall standards and improving accountability (peers are responsible for changes, not change "authors")

So, please let me know what you like about your change management process or what you've liked previously.

 

i like that certain people where i work tell me that i need to create CR's but then ignore them when i submit them.

i also like that those same people constantly do changes sans CR.

i especially like when those same people ask me to perform a certain task and when it causes a bit of impact on some users they ask me if i submitted a CR for the work and i have to remind them that they should have done the CR before assigning me the work.

 

We digitised it last year. No more printing change approval tickets on coloured paper for manual sign off

 

Wow, I don't know how big your organisation is, but I imagine that was a huge amount of paper!

 

It's a .vic.gov.au org.

There still lots of paper processes but we're getting there.

 

We use a digital process here now.

We have SCSM 2012 R2 along with Cireson Portal v7 as a front end.

Really really easy to create the change requests, all parties that are approving/reviewing get emailed the link directly to the CR to review, and also to vote.

The webpage is REALLY nice too, and fast and snappy compared to some of the other incident/change management software we've used in the past.

As mentioned it does incident management too, along with service requesting which essentially is fully automated jobs that the users can select and get the approval all digitally.

I quite like the CR process we have here, and since i've spent quite a few months customizing and setting this thing up... i'm particularly biased i guess.

The good thing for us is we are already paying for it, so cost wise..... free except for cireson portal, which was cheap.

 

We use Service Now to log CRs, really awesome compared to Remedy

Its Totally about managing risk

Peer Reviews, some times I miss a a step

Change Boards are once a week and everyone in IT knows it

 

I like that we don't have any. Not because I dislike change management, but because I like working with smart people who can be trusted to do smart things.

 

Even in an organisation full of geniuses, Change management still has a place.

What I like about it, when done well

• Makes people think about what they are doing, and the impact it can have on other systems
• Lets IT Communicate with the Wider business when and why changes are happening
• Provides historical reference

What I don't like about it when done poorly.

• People with no real stake in the change feel the need to have input, to justify the amount of time wasted in CAB meetings.
• https://en.wikipedia.org/wiki/Law_of_triviality
• Change Process takes more time than the actual change
• Repeat changes that are very similar, still need to go through the same process as one-off changes that are completely different.

The Bike-Shed effect is probably my biggest bugbear is probably with Change Approval Boards that want or need complicated things explained simply, but when explained simply, many of the nuances of the 'thing' that are most relevant to the change are lost.

Change Management done well is good, in that it forces people to thing about things that might have been forgotten, but when you need to explain the minutiae to every man and his dog, so they feel justified in their position... Change Management starts to make me angry.

 

This is currently a pretty accurate representation of what I'm dealing with at the moment. The change process is incredibly convoluted. If I want to make a change to 1 Group Policy, to change something trivial from enabled to disabled it takes me approximately 30 minutes to get it into the system, about the same amount of time again following up with the relevant parties trying to get it approved and then a mandatory attendance to a 1hr change meeting which will either ask for more detail than anyone could possibly need, or no request for detail at all.

All in all, it would take approximately 2-2.5 hours of time managing the change process and the total time to implement the change would be less than 10 minutes. This is including the time it takes to login, document the results and submit the change for closure (you can't close your own changes, or move them from the implementation phase). This has the added bonus of ensuring that you never know when or if a change has been implemented, or when it actually was implemented, (there is no communication required outside of the change meeting).

 

Can we talk about the point of change management?

Which to me is -

What is down or upstream of what i'm changing that may be impacted?
Does my change impact another change in progress, is there some idea of conflict avoidance?
Is there anything i've missed, not considered, not considered fully?

To which.

I have NEVER seen any organisation that has a link of dependency of systems or devices, ie. if i'm playing with a regional site router, will The System (this doesn't exist afaik) flag anyone involved in the WAN link, any onsite equipment that reports back to base - reporting, alerts, some SQL system, anything impacted by a network isolation of that site. Or at least any system such as monitoring, alerting or IPS that has this dependency relationship has absolutely no relationship with their change process.

I have NEVER seen any organisation which has some sort of Change Calendar, something I could even consult BEFORE submitting my change to know that, say in the above example, that they're working on the WAN link the same time i'm planning to make changes to the remote WAN router/cpe.

I HAVE seen many many organisations for which non technical management make ME explain the impact, extent, risks and mitigations for my change with ZERO sanity checking by a technical resource, or if there was a technical resource they were not either incentivised to review properly, or lacked the depth or breadth of technical knowledge to review with any merit. So its essentially me telling management "Seems good to me!" which is worth 4/5's of fuck all in terms of change control.

Which is all a long winded way of saying i've never seen any change management process that did anything except dilute responsibility, allow people to pat themselves on the back for nothing or in any way avoid, ameliorate or understand risks associated with technical changes.

 

Read Kotter's "Leading Change"

https://www.kotterinternational.com/8-steps-process-for-leading-change/

The key for me with Change Mgt is, logic and "smart" people do not necessarily work, "smart" people will more than likely lead to change failure. You need people that can deal with people and diagnose the key drivers and factors that contribute to change adversity in an organisation. When you can understand what human drivers are impacting upon your change efforts, and how you can manage them, you'll find that change can be delivered more sustainably and in ever increasing levels of cadence.

 

I'm not sure how you've refuted or endorsed any of my points.
Nor how any of those 8 points have any grounding in reality or productive outcomes.

Even the initial premise of "Create a sense of urgency" is in no way axiomatic or necessary.

But then maybe you're addressing the thread as a whole and not me..

 

That's about changing organisational structure/culture in response to external stimuli. I think most of the posters ITT are talking about how to manage technical IT changes in the ITIL/PMBOK sense of the phrase.

 

Those steps apply to any level of change, not just org structures.

 

Yes, my intention was to talk about how to implement "technical" change within industry rather than orchestrate cultural or structural change within a business. The link was interesting, but appears to be focused at a much higher layer than I was intending to address with this thread.

After my sit down with our change manger here, I was instructed that the intention of our change process is to accomplish the following:

• History of Changes (a log if you will)
• Assist with Planning (by allowing you to be aware of other changes)
• Highlight multiple team involvements (when a change involves multiple teams)
• Identify and highlight risk to "normal" operation
• Scheduling (to prevent too much change happening at once)

I highlighted a number of concerns and sited numerous examples of how a significant proportion of this was un-achievable with the current amount of information in our system.

We do have a change calendar, but as the change automatically enters the implementation phase when approved, despite start time being a part of the change. This is further compounded as people are unable to move their change out of implementation after completion, this means that it is impossible to tell when a change was implemented, if it is implemented, or if it yet to be implemented, even when looking at the change or from the broader change calendar. This makes the feature practically useless.

After this discussion a number of points were raised and they're now going to our leadership group for implementation. I'm wary, but also hopeful that the improvements will be made and the process will become, in someway, valuable.

 

That's what I loathe about management bullshit, it's so vague and nebulous that people who will try to apply it to anything that has even a superficial resemblance to its terminology. We don't need to build a strategic vision, a guiding coalition, and a volunteer army, to run the monthly patching cycle on the fucking ERP system.

 

OK, ignore the frameworks and structures that have been peer reviewed, researched, tried, tested and refined over many years of execution across many industries and organisations. Good luck.

 

that executive management consultant marketing page you linked is a little short on detail about any of those things.

Posting links to motherhood statements like "Form a strategic vision" isn't really going to help people in freeky beeky's situation, when all they can do is point out the flaws in the current process and hope for executive management to acknowledge them.

 

But a good technical regulation, or change management system would cover off on such circumstances, and allow for the appropriate amount of effort to be applied to the monthly management system.

Its the framework, i.e. a risk assessment and judgement of significance; that is used for the overall change management process that would allow the monthly ERP patching to be relatively low key in the scheme of things.

Requiring 6 months of assessment and contingency plans for a monthly ERP patch is more of an example of either a badly developed or a badly implemented change management process.