4.2 Explain basic change-management best practices

4.2 Explain basic change-management best practices

• Documented Business Processes
  • Rollback Plan
  • Sandbox Testing
  • Responsible Staff Member
• Change Management
  • Request Forms
  • Purpose of the Change
  • Scope of the Change
  • Date and Time of the Change
  • Affected Systems / Impact
  • Risk Analysis
    • Risk Level
  • Change Board Approvals
  • End User Acceptance

Change Management

Each time we change something in the organization, we should follow a specific procedure.  This is known as Change Management.

• We should identify the purpose of the change.  Why are we making this change?  What benefit will it bring us, or what harm will it reduce?  For example, we want to upgrade our network.  It will bring us faster speeds, better security, and improved performance.
  
  
• What is the scope of the change?  Exactly what are we going to do?  What equipment will be changed?  What configurations will be changed.  What will they affect?
  
  
• Risk Analysis.  What are the risks?  A risk can be negative or positive.  What is the impact of each risk (if a risk were to happen, what damage will it cause)?  What is the likelihood of each risk?  It will cost money to change the network equipment.  We risk downtime during the change, and there is a possibility that the upgrade doesn’t go as planned, leaving users without internet.
  
  
• Plan for change.  How will we implement the change?  We should clearly write out each of the steps involved in the change.
  
  
• Sandbox Testing.  If possible, we should test the change on an isolated system, known as a sandbox, before implementing it across the entire organization.
  
  
• Change request form.  We must fill out a form to request the change.  The request goes to the organization’s management or to the change control board.  A responsible staff member is somebody who is accountable for the change.
  
  
• Change Board.  Also known as a Change Control Board.  The board decides whether to approve or reject the change.  The board is made up of stakeholders from the organization.    It may include managers and end users.
  
  
• Once the change is approved, the organization sets a date and time for the change.  The change should take place at a time when the impact to end users or customers is low.
  
  
• Rollback / Backout Plan.  We should always have a plan to go back to the old setup in case the change fails.  This plan must be established before the change is approved.  The change may fail during implementation or later.  For example, we might change the network equipment and realize in the middle of the upgrade that some new equipment is missing or defective.  We should have a plan to revert to the old configuration.
  
  
  • We should have specific criteria for when we are going to roll back.  It might be a time, cost, or other measure.
    
    
  • For example, the network appears to be functioning early in the upgrade, but during testing we discover that some resources are inaccessible.
    
    
• Document Changes.  Write down the changes that are made so that others can reference them.  If we don’t document a change, then others will see the change and assume that a mistake has been made.
  
  
• End-User Acceptance.  The people who are affected by the change must accept the change.  They will be required to test their systems after the change has been made.