15 Easy Questions for Easy Change Management

If your systems keep breaking when changes are made, answer these questions

Marcin Tustin
Build and Learn
3 min readSep 22, 2019

--

These 15 questions should be very easy for engineers to answer ahead of making a change; and if engineers balk at answering these questions you have a problem (or you’re cool with breakage). Work around those problems, and find out what they are with this questionnaire. This article is about a structured approach to change management in your technology.

You’re probably looking at this article because your systems keep breaking after changes are made. While this isn’t a magic bullet, it is a tool to start thinking about how you ought to work.

Skip downwards if you just want the questions to incorporate into your change management process for software development, operations, or infrastructure.

Why these questions matter

In short, if your engineering team can’t easily answer these questions:

  1. they haven’t thought about the change; or
  2. your deployment and rollback process is too hard; or
  3. your testing or monitoring tooling is too hard; or
  4. Your systems are so entangled that understanding the impact of a change is hard.

The point of this questionnaire is both to help you work around your problems now and identify what those problems are.

In general, if your engineers can’t answer any or most of these questions, then you either have a culture that promotes making changes regardless of the consequences (case 1, not thinking, is rewarded), or your systems are too entangled to really predict what will happen.

DevOps is about agility

Incidentally, it’s OK to have a culture where things keep breaking; if you’re completely happy with how things are going, and everyone on your team is happy, then you do you. These questions are here to help you change how you work if you know you need a change, but don’t know how. In a truly self-organizing team, your engineering function will figure out how to make these questions easy to answer; in most places if engineers are required to answer these questions, management will start to hear about why they aren’t easy to answer, and these are your pointers as to what you might want to fix.

The costs of being careful

Let’s be clear that some changes are harder to make than others — getting a totally nailed down answer to all of these questions either means your environment makes it easy, or it means you spent the time to get all of these answers.

That’s why the questions about potential impact are so important: you probably want to take a risk-based approach to enforcing these questions as part of your change management process. If you know that the potential impact of a change is small, then maybe you don’t need to answer all the questions. Or, if you know how to back out a change and know how to detect a problem maybe that’s all you need, and you don’t need extensive testing.

The 15 Easy Questions for Safe, Structured Change Management

  1. What is this change?
  2. Why are you making this change?
  3. What is the expected outcome of this change?
  4. Who is going to deploy this change?
  5. When are you going to deploy this change?
  6. How have you tested this change? (And what are the results of your tests)
  7. What questions are left unanswered/what risks are left in this change after your testing?
  8. Please describe the procedure to deploy this change (in such detail that another engineer could pick up this task)
  9. Please describe the procedure to roll back this change (in such detail that another engineer could pick up this task)
  10. What bad things could happen as a result of this change (and why couldn’t other bad things happen)?
  11. Who in our organization will be affected by this change? Should anyone sign off on this change?
  12. How will you know if this change has worked or not — how will you monitor this change?
  13. How will you know if this change has worked or not — how will you test this change?
  14. What criteria will cause you to roll back this change? Please describe specific observable criteria.
  15. What criteria will cause you to consider this change successful and no longer in need of active monitoring (such that everyone could go home, have a few drinks, and go to bed)

9. What bad things could happen as a result of this change (and why couldn’t other bad things happen)?

--

--

Marcin Tustin
Build and Learn

Data Engineering and Lean DevOps consultant — email marcin.tustin@gmail.com if you’re thinking about building data systems