Documentation is boring. But then so is eating your vegetables, and apparently now we’re adults, we shouldn’t need our broccoli hidden from us… unless you’re the leader of the free world. Anywhoo, let’s talk about what change management is, and why you should definitely have a change management process in your business.
Change What?
Anything. Well, almost anything, but you can decide. Most businesses agree that rebooting a server isn’t a change, but that most other things are.
Examples of changes you probably want to capture might be;
- Stopping a service
- Adding a user account
- Adding a source address to a firewall group
But they might not be. It all depends on what your platform is functionally doing, how it does it, and how risk-averse your business is. That’s why I worded the firewall change so clumsily, since you might have a standard firewall rule and you just add new users’ public IP’s to the group. I think you could reasonably argue that it isn’t a change – again, depending on your environment.
Manage What?
The management part of change management relates to lots of areas of your business;
- System availability
- Client expectations
- System resources
- Human resources
Imagine any one of those 4 things running out, you can see that we would have problems, and so it is important to manage them accordingly.
- If we change something and the system becomes unavailable, it’s very hard to put things back the way they were if we didn’t manage that change.
- Not telling the client or other stakeholders that we were making a change means we haven’t managed their expectations.
- If we didn’t check the technical impact of turning off or on a particular service, we might run out of server resource, and impact everything else.
- And if we didn’t plan in the right staff to complete the work, then it just won’t be done, or won’t be completed to the required standard.
How?
That’s up to you. It can be as simple as a flat document where you fill in details about what is changing, or it can be as feature rich as some online tools like Atlasian Jira. You need to work out what your business needs before you start looking at tooling.
Some questions you might want to think about in the planning phase might be;
- What constitutes a change in the context of your business?
- Who will make the changes?
- Are they in different teams?
- Which other teams need a good oversight of the changes taking place?
- Who should have authority to approve changes?
There are lots of other things you could think about, but we’re already getting a bit listy in this post, and actually, if you start with these questions you will quickly expand the thought process anyway.
When?
Do it now! I know right now it’s just you and Jill the developer, and you talk all day on Slack. But how will you ever use the information about these changes again? Could you work out how to put something right if it went wrong now?
Change management systems often link into wider knowledge sharing platforms like Wikis or shared document libraries. All these things sound like lots of work, and something which you can put off for another day. We’re only a small outfit, we don’t need these processes, you might think. Well you might be surprised at how much you come to rely on the data you record once you start recording it.
Design a slick, simple and easy to use process for change management, and I promise, it will make your life easier in the long run. Why not get more ideas on how to streamline your technology by reading some of our other posts?
