Process 7: Validate and Review the Change

  • Article

Published: April 25, 2008   |   Updated: October 10, 2008

 

The final process is to validate that the change has been released correctly and to review the effectiveness of the change.

Cc543242.image9(en-us,TechNet.10).jpg

Figure 9. Validate and review the change

Activities: Validate and Review the Change

After the team has successfully released the change into the production environment, the next important process is to validate the release and then review it. The goal of validation is to verify that the change has actually been released as expected. The goal of reviewing the change—typically called a post-implementation review (PIR)—is to determine whether the change has had the desired effect and has met the requirements from the original RFC.

Determining whether the released change has been effective and has achieved the desired results requires monitoring the change in the production environment. For a small change, this might be a matter of checking on the desired functionality. Larger changes might require monitoring of network and server information, performance data, event logs, and response times.

After the release of the change has been validated, the PIR can be performed. The results of the PIR should include:

  • A success/failure decision on the change implementation.
  • A review of how the change was released and whether it was implemented on time and on budget.
  • Documentation of the lessons learned from the change process.

The following table lists the activities involved in validating and reviewing the change. These include:

  • Validating the technical success or failure of the change.
  • Validating the business success or failure of the change.
  • Auditing the configuration database.
  • Communicating and recording the change.
  • Updating and closing the RFC.

Table 10. Activities and Considerations for Validating and Reviewing the Change

Activities

Considerations

Validate the technical success or failure of the change

Key questions:

  • Did the change meet the technical requirements? This may be verified in different ways based on the type of change. For example:
    • User testing
    • IT testing
    • Monitoring tools
  • Are all site deployments complete and stabilized?
  • Have all the project team members transferred out of the project?
  • Was the quiet period uneventful or were numerous incidents documented?

Input:

  • Data about the technical success of the change

Output:

  • Management review report

Best practices:

  • Incidents related to the change are a reactive indicator of the success of the change.
  • For workstation changes, a phone call or a walk around check-in after a change is made are proactive verifications.

Validate the business success or failure of the change

Key questions:

  • Did the change meet the business requirements and objectives?
  • Are customers and users satisfied with the solution and its release?
  • Are customers and users happy with the results?
  • Have there been any unexpected side effects?

Inputs:

  • Feedback regarding technical aspects of the change
  • Feedback regarding business requirements aspects of the change

Output:

  • Validation of the change

Audit the configuration database

Key questions:

  • How accurate is the data about the change that has been stored in the CMS?
  • Who updates the CMS, and what happens if the data is incorrect?

Input:

  • Information about the changed CIs

Output:

  • Accurate and updated information in the CMS

Communicate and record the change

Key questions:

  • Has the team documented the results of the change, including the service type, completion date, and technology type in a data store that has query capability?
  • Has the team provided feedback (including issues and a summary of the PIR) about the change to the appropriate parties? For example:
    • CAB members
    • Customers and users who are affected
    • The change management and release management teams
    • IT management
    • IT staff

Input:

  • Information about the change

Output:

  • Communications about and a record of the change. This information feeds into the Operations Health Review

Update and close the RFC

Key questions:

  • Has the RFC been updated to include feedback from the PIR?
  • Does the RFC accurately reflect the change just completed?
  • Have the results of the PIR been documented?

Input:

  • Updated information about the change

Output:

  • Closed RFC