Change Management

Posted on by

Receive Change Request

  • The Change Request can be raised through a defined tool, or a Change Report or equivalent.
  •  The team responsible for processing change Requests receives the details in pre-defined format, in form of the raised CR.
  • Identify if the CR raised is complete in all sense with all required information.
  • Log each Change Request in Change Log

Expedited Changes:

  • The lead time for expedited changes is 5 working days from the moment the Release Manager received the full approved request. It can be shorter if the Change Implementer (read Capability) agrees.

Emergency Changes:

  •  There is no lead time for emergency changes. Emergency changes always must be connected to an incident record severity 1 or 2.

Urgent Changes:

  • The lead time for these urgent changes is 5 working days from the moment the  Change Manager received the full approved request. It can be shorter if the Change Implementer (read Capability) agrees. Urgent changes must always be connected to an incident or a problem recorded in the registration tool.                                                                              

Evaluate Change Impact

  • The received CR is first analyzed/ evaluated briefly.
  • Evaluate the impact of CR on current CIs, in terms of volume and impact of change. Note that the impact can be for a service that is offered and not only on work products or the product delivered.
  • In case the impact is on the services offered, the corresponding CI should be the requirements, scope, or other work products that describe the parameters of the service.
  • Identify clearly the impact on the schedule, cost, and size/scope of work
  • Analyze the change for potential compatibility, functionality, quality attribute, or interface issues.
  • Identify any risks associated with the change

Estimate Change

  • Based on the assessed Impact, arrive at a broad estimate for the CR.
  • Assumptions and constraints for arriving at the estimate should be provided

Obtain CAB Approval

  • CAB meetings are scheduled in advance at a defined frequency.
  • In case of urgency, an unscheduled CAB meeting could be held to deliberate and decide a specific CR
  • CAB members will review  and discuss the proposed estimate and Impact during the meeting
  • The CAB shall approve/ reject/ put the CR on Hold, depending on various factors like its urgency, availability of resources, and priority of other Open pieces of work.
  • All relevant stakeholders are invited to the CAB meeting and their agreement is obtained prior to CAB approval

Plan and Prepare for the Change

  • Plan and prepare for the change from development through implementation
  • Decide on the detailing and rigor of the planning and management depending on the size, complexity, and impact
  • Plans should include the following
  • Identification of configurable items to be deployed
  • Whether it is added, changed, or deleted
  • Integration and interface considerations
  • Post-deployment support if needed
  • Rollback procedures
  • Training of users and support personnel
  • Communication of status to relevant stakeholders

Perform detailed Impact Analysis

  • If the CAB approves the CR in the step above, then the CR Action Team should do a detailed impact analysis.
  • The list of CIs that need to be changed due to the CR is listed.
  • The other CIs in the configuration Library that is related to this list of CIs are also listed.
  • The nature of change (Addition, Modification, Deletion) on each impacted CI is recorded.
  • Any known limitations that cannot be addressed through the CR should also be recorded.

Prepare detailed estimates

  • Based on the detailed Impact Analysis above, the estimate should be derived for working on each impacted CI.
  • Other constraints like Skill availability, risks, etc. should be borne in mind while arriving at estimates.
  • All impacted stakeholders should be kept informed of the Impact Analysis Results and proposed Estimates.

If detailed estimates are largely different from broad-level estimates that CAB has approved, re-approval from CAB should be sought.

Design Changes

  • Depending on the individual requirements for the CR, solutions should be proposed for meeting each requirement.
  • Any known limitations in satisfying a particular requirement should also be recorded.
  • Impacted Stakeholders should sign off the Design.
  • Ensure that deployment, release, and implementation constraints and parameters are considered during the design of the CR.

Update the Change Report based on detailed Impact Analysis, estimates, and design changes.

Plan for verification and validation of the change

  • If the change is a valid change, for each listed requirement, develop the test cases to verify if requirements are met, once the changes are done.
  • Ensure test cases include all possible scenarios while testing a requirement for being met.

For all other changes, plan for any verification and validation of the change to ensure that the change when implemented meets the requirements of the change.

Build the Changes

  • Make the required changes on the impacted CIs, after checking them out from the Configuration Library.
  • Ensure they are also marked “Checked Out” in the CONFIGURATION MANAGEMENT DATABASE, to help address other CRs impacting a specific CI from this CR.

If the change is a valid Change, apply all applicable standards while making changes to the Impacted CIs.

Verify the Components impacted

  • Check the changed CIs against developed test cases to verify and validate if all requirements are met.
  • Log all defects, and track the same to closure.
  • Obtain approval from stakeholders on the CIs, before planning for their release.

Update Support Documentation

If applicable, update all Supporting Documentation and User Manuals related to impacted CIs, to align with the changes made.

Package Release Components

  • Logically package all components of Release, like Impacted CIs, Supporting Documentation, etc.

Update Release Logs or equivalent with the details of this release.

Coordinate Formal Acceptance Testing (T)

  • If the change is valid Change, coordinate formal acceptance testing by the End Users.

For all other types of changes ensure end users or those impacted by the change validate and agree to the changes made prior to deployment.

Establish Production Environment

Determine and establish the production environment for the release.

Deploy in Production Environment

  • Deploy on Production Environment or make the CIs available in the Production Environment.
  • For CIs added as part of the CR: Make new entries available in the Production environment and CONFIGURATION MANAGEMENT DATABASE
  • For CIs modified as part of the CR: Replace old versions with the new ones in the Production environment and update the CONFIGURATION MANAGEMENT DATABASE.

For CIs Deleted as part of the CR: Remove CIs from the Production environment, Archive them as per applicable policy and update the CONFIGURATION MANAGEMENT DATABASE.

Perform Deployment Testing and review

  • Test the Deployed change or CIs for successful deployment

Review the change and ensure the deployed CIs are working as expected in the production environment.

Post Deployment Support

  • Communicate the release of the CIs under the CR to the impacted stakeholders.
  • Support the user base during the implementation of the new CIs.

Collect feedback from the users, and raise required change Requests if any.

Close Change Request

  • After the predefined period of Deployment, support is over, close the CR in the tool/ CR Log

Maintain all records of the closed CR for future reference.