Change Management – It’s Still Important

While Change Management is a process that I’ve usually encountered in large companies, it’s also a process that is important in companies of all sizes. The biggest issue I’ve found when there isn’t a well-defined process is that there’s no recovery plan should something go wrong with the proposed change.

(Hopefully, you know of my feelings about backups. If you haven’t tested them, you don’t know if they’re any good.)

The best process requires documentation of the state of the environment before the change, including system and performance specifications, the steps taken during the change process, the state of the environment after the change, and the steps required to return the environment to its previous state should anything go wrong.

Without these details you could find yourself scrambling to fix potentially critical systems that worked just fine before you started. I’m not comfortable having to explain myself in that event, and neither should you be.

In earlier times I’d put together a document with the information I described, but there are many ways of recording this information which makes it searchable, so I’ll describe the elements I think are important instead. Here’s the complete list:

1. Target Date
2. Reason for Change
3. Target Server specs
   1. Processor
   2. Memory
   3. Disk
      1. Size
      2. Free space
      3. RAID type
      4. Location (Local, SAN, etc.)
   4. Network channels
4. Target Database Server
   1. Version
   2. Edition
   3. Service Pack/Cumulative Update level
   4. Configuration parameters
5. Target Application Database
   1. Version
   2. Database Size
   3. Database Free Space
   4. Customization details
6. Performance Profile
   1. Dashboard Report
   2. Perf Counter baseline
7. Description of change to be made
8. Anticipated effect of change
9. Steps to be followed to implement change
10. Steps to be followed to rollback change if needed
11. Scheduled time for change
12. Customer approval sign-off
13. DBA Lead approval sign-off
14. Post-change performance assessment
    1. Dashboard Report
    2. Perf Counter baseline
15. Lessons Learned

Of course, the date and reason for change need to be identified. We then want to document the state of the target system, including machine specs, SQL Server specs, and database specs. We also want to capture a performance baseline, so we know what performance looks like before the change.

Next, we need a description of the change and what we expect the effect of that change will be when complete.

We need a detailed checklist of the steps we’ll take to implement the change, so we make sure that the change is done correctly, and we also need a detailed checklist of the steps required to roll back the change should something go wrong. An added bonus would be a detailed checklist of how to back out a change after production processes resume, with (hopefully) a way to keep the data changes made between implementation and rollback.

The time the change is scheduled for, and the sign-offs of the appropriate control people is important to ensure that the changes are approved by the business.

Finally, a detailed assessment of the post-change performance and business effect of the change, including a new performance baseline, allows you to quantify the change for later analysis.

As with anything you do, a lessons learned assessment allows you to define what was done, what went well, what could have gone better, and how you might approach a similar process in later changes. Having this information searchable allows your organization to build a knowledge base that will enable the business to bring new people on and give them an understanding of why things are the way they are.

All business organizations, even small ones, will benefit from having a solid, well documented, change management process.