Changes shouldn’t lead to crisis, and therefore we have Change Management. It is a powerful tool for avoiding new and unexpected issues. It will also provide audit trails and situational ownership during an event.
Frequently during the life of a VMware Support Request, we have to make a change in order to resolve a problem. Issues sometimes seem to crop up for no reason, when it seems like no change was made. So, we can continue to not make any changes and see if that fixes the issue, or we can try to remediate the problem through managed changes.
And, as may be the case during a production down outage, we go with an Emergency Change where we sometimes just cross our fingers that we didn’t miss anything.
If you’re worried about this, take the time to weigh the empirical evidence versus the gut feelings.
The Lewin’s Change Model
Here is a good start:
This might seem basic, but this is a solid foundation for any change management system:
- We are not making changes. (If something breaks, it was an outside factor that caused it.)
- Then, we make our planned change. (If something breaks, we need to look at collecting data and undoing the change.)
- Last, we stop making changes again. (Things go back to this nice, stable state.)
You can read more here and here.
Kotter’s Theory
Here is a more elaborate model:
Some of my favorites:
Step 3: IT is making the change to improve the life of the business. Even if it’s, “This software has reached end of live (EOL) and we need to upgrade,” that’s a dialogue to have with the stakeholders in understanding why new software gets released.
Step 4: User Acceptance Testing (UAT) enrollment. Sometimes we get lucky and have a few people who are using the IT systems we provide, and they are very vocal about what parts don’t work and when they don’t work. These folks 100% should be enrolled in the UAT group. You need reliable feedback when you are testing.
Step 7: Do you ever find yourself getting distracted and working on multiple tasks at once? Stop. Respect yourself and the people who depend on you, and focus on the priority.
Learn more here.
Which change model is best?
They are all the best. It just depends. You have a Change Management department in your organization (if not, you need to raise that concern with Sr leadership) and there will be times where someone on your team is sighing and saying, “Oh geez, I need to fill out a change ticket. Not fun.”
But remember that unmanaged changes in a complex environment will result in application outages and you will have various managers from the lines of business calling you directly to confirm when you will be returning service to their applications.
The two key steps you need to follow are
- Test the change. You have a test environment which resembles your production environment. Rigorous testing, not just by IT but by real users, needs to be done before you push a change into production.
- Get the proper notifications out there. Your team, the business, who all do you have to notify? That’s what the Change Management group is there to help with.
If step 1 caused you to gasp a little, because you don’t have a test environment and you have feelings about that, that’s probably the first thing you should address.
How do I test?
In this example, I’m working on a Horizon VDI environment. Some factors you should consider:
What is the workflow that is being impacted? (Not knowing what the users are doing means I have no idea what I am doing)
How many people on my team are testing?
How many end users are testing?
How fast am I rolling out changes?
Below is an Excel spreadsheet I created for a customer a few years ago. What should happen is each IT Engineer helping test fills out the reference data (when I tested, what desktop pool I was using, what kind of client I used, etc) so later we can go back and reference what worked and when.
Why should I have multiple IT support engineers helping with this? Because we all do things differently. And we want to find and fix as many concerns as we can before we get it in front of the UAT group.
Here is the file: Test_Workbook_v20221213.xlsx
Last thing
If you missed my previous articles on creating Support Requests with VMware and how to work those requests, you have those links now. We’ll continue this series by next discussing how to plan and perform upgrades and the importance of runbooks.
Comments