I work with clients with a variety of change management practices— everything from, “I just email the team when I’m going to change something” to “I need to submit formal changes each Tuesday by 2pm for weekly review for the next approved change window.” And occasionally, “Just Do It.”There’s no single right way to do change management. There are some really basic standards: yes, you should be checking in your code! But different teams communicate, propose, and approve changes in their own way.
When planning changes, successful teams typically cover these questions in one way or another:
- What are you doing?
- Why are you doing it?
- What steps will you be doing?
Sometimes people even include, “How do you undo the change?” I’m a huge fan of that— if there’s no way to undo the change, that’s important to know! It’s also important to know when it’s dead simple to undo the change.
There’s one question which almost nobody asks, however, and it’s one of the most important questions.
What’s the Worst Thing That Could Happen?
With every change you do in production, ask what realistically is the worst case scenario. We’re not talking about space trash striking the datacenter and causing company-wide failure, we’re asking the question, “What specifically would fail if this change went really bad?”
This is a simple question to ask, but you learn a lot from answering it. It’s a much more informative question than asking something like “is this low, medium, or high risk?”
Why this Question Saves Your Business
The “worst case” question gives you insight about how you run your business. It shows you what levels of risk you regularly take. It also shows you how well your team understands the possible impacts of changes.
Asking this question also builds your teams in an interesting way. When I first started tracking the “worst case” scenario for changes, I found that I needed to talk to my colleagues more. I could easily tell that a change might produce incorrect data in a given table or cause a problem in a given area of data processing, but I wasn’t sure exactly what that might mean to the end users. To work out that question I needed to work with others. Sometimes I got information from our developers, sometimes from our level 2 customer support team, and sometimes I worked out the information with business users.
Great Change Management Builds Documentation the Easy Way
Asking “what’s the worst thing that could happen?” was a natural and easy way for my team to document the role of our database servers and points of impact on the business when they went offline. As we collected this information in changes we also documented it in our troubleshooting guides.
My team went from having a vague idea of the level of risk of changes to have a clear, documented list of the roles of all our databases. We worked in an extremely active environment and it was always safe to assume we didn’t have a complete list of impacts: we had to keep communicating. But this added a huge efficiency to planning changes, responding to incidents, and also demonstrating the value of our investment in data management.
Don’t wait for Management to Demand Better Change Management
Sure, improving change management can be a great win for managers. But if you’re reading this and you’re a database administrator, improving change management can be an even bigger win for you.
If your team’s change management can be improved, you have a great opportunity. Start with your own changes: try out a new method of documenting your changes and getting them approved. Use it to iteratively improve your documentation of the system. Show your management what you’ve been doing and the value it provides, and soon you’ll see the process take off. Know what you just did? You just contributed to your business in a huge way.