Ch-Ch-Ch-Changes

In this post, I’m going to talk about Change Control and how important it is for all organisations to have a proper process to document any and all changes to their infrastructure.

risual has two technical teams: Managed Services (rMS) and Consultancy Services (rCS). As a member of rCS, I wouldn’t be involved in raising changes, but with the recent security work with one of our customers (who I’ve named Customer U), I have become involved in raising changes, and that was an interesting experience to both watch and be involved with.

As you can imagine, there are different software packages available for Change Management, and a small list of them is here:

Change Management Software

  • Wrike
  • ESM
  • Viima
  • Howspace
  • WalkMe

At risual, we use Dynamics to document all changes, whether be they for risual or one of our customers. The process of Change Control will differ from software to software, and from organisation to organisation, but the basics are much the same.

Basic Change Control Process

  • Customer requests a change.
  • IT documents the change into the system using the following details:
    • Description of the change.
    • Owner of the change.
    • Implementor of the change.
    • Schedule of the change (and Type).
    • Risk, Impact and Security Assessments.
    • Steps for implementing the change.
    • How to validate that the change is successful.
    • Steps for backing out changes if unsuccessful.
  • A list of approvers will look at the change and can ask for more information.
    • Depending on the organisation, these may require a Change Advisary Board meeting, or it may just follow an internal workflow.
  • IT will implement the change as per schedule.
  • The customer reviews the implemented change and determines if it was successful or not.
    • If successful, IT document the change as completed successfully and close the change.
    • If unsuccessful, IT backout the change as failed and close the change.
  • For an unsuccessful change, the organisation should have an internal process to review why the change failed and how to prevent it in the future.

So the next time you are updating your infrastructure, take a moment to think about what is going on in the background process that led to your implementation of that change, and you’ll see that there are a lot more people involved than you originally thought.

About the author