Manager Responsibilities

Overview

Before a Request for Change (RFC) is submitted to the Change Review Board (CRB) and/or Change Advisory Board (CAB), the MPP manager indicated in the Request for Change (RFC) as the responsible manager must thoroughly review the Request for Change (RFC) , work with the submitter to make appropriate changes as necessary and then change the Request for Change (RFC) status to Manager Approved. After Request for Change (RFC) approval, the manager is accountable for the Request for Change (RFC) implementation and for completion of a Post Implementation Review of the Request for Change (RFC), if needed.

Request for Change (RFC) Review

The manager should review the following sections of the Request for Change (RFC):

1. Description: Review the description for enough clarity and detail that a responsible decision can be made by the manager, CRB and/or CAB. The description should fully describe the scope of the change and the resulting deliverables of the change. It should detail out each step of the change so that CRB/CAB members can review and discuss any possible overlooked impacts or steps.
2. Request for Change (RFC) Information:
   1. Type of Request for Change (RFC): Is the Request for Change (RFC) set to the right selection?
   2. Special Circumstances: Are there any special circumstances to this Request for Change (RFC) that need to be stated to allow for responsible decision-making. For instance, is this Request for Change (RFC) responding to an incident or service failure?
   3. Proposed Implementation Schedule: Review the dates and times for starting and ending the change. Do the times fall into the normal maintenance windows for the service or system being changed? If not, make sure the reasons are described thoroughly and that any impact administrators and users are properly notified of the impending change. Make the change will not impact normal business processes unnecessarily.
   4. Testing: If testing can be done prior to the change, it should be done. Make sure that the testing is described and that all the appropriate parties were involved in the testing including systems administrators, application administrators and functional owners as required. Testing should be done end to end. For instance, if the change involves changing a system parameter, then all the applications and databases impacted by the change should be tested to make sure they still work as intended.  The testing should be performed by subject matter experts for each impacted application. Starting the application is not a thorough test. If test scripts are available, make sure they are attached to the Request for Change (RFC).
   5. Restoration Plan: Is the restoration plan detailed and actually valid?  Has the restoration plan been tested?  Is the restoration plan possible?
   6. Who Raised the Change?: Make sure the correct party is entered.
   7. What is the Reason for the Change?: Make sure the change is justified by a business or technical need.
   8. What is the Return? What is the expected outcome from this change?: This should fully describe the end state and deliverables resulting from the change.
   9. Risk: This is one of the most important areas to review. What is the actual risk of performing this change? Can systems completely fail? Are other systems impacted? What will happen if things go wrong? Make sure the correct selections are made on impact and probability.
   10. Who is Responsible?: Make sure all people that will work on the change are listed. This should include anyone responsible for testing including functional SMEs. Testing should, at minimum, be performed by the same people involved in pre-implementation testing.
   11. Relationship: Make sure that all servers and applications impacted by the change are listed. This will help in identifying additional people that need to be notified or possibly raise red flags during review.
3. Once review is completed and the MPP manager is satisfied, the Request for Change (RFC) should be changed to Manager Approved and the appropriate boxes checked in the Manager Review section. Be sure to communicate to the assigned staff that the Request for Change (RFC) has been manager-approved.
4. If the Request for Change (RFC) falls outside the normal CRB/CAB timeline, the manager should contact CAB via email for approval.
5. If the CRB and/or CAB approves the Request for Change (RFC), make sure the appropriate parties are notified that the change is CRB/CAB-approved
6. In addition, the manager of the Request for Change (RFC) is responsible for coordinating a Post Implementation Review (PIR) on Request for Change's (RFC's) with the following conditions: created an unknown/unexpected impact; a change that failed; a change that was not properly communicated; a change with further impact than indicated from the review process; any lessons learned from Request for Change's (RFC's) should be documented through the Post Implementation Review (PIR) process.
7. The Post Implementation Review (PIR) process will include the following steps: (1) the manager who approved the Request for Change (RFC) will coordinate a detailed investigation with all parties involved and will ensure that a detailed analysis of what went wrong and lessons learned for future improvement is documented. (2) If necessary, the CAB will then review the Post Implementation Review (PIR) against the IT Change Management documentation and will make adjustments to the Change Management process as needed based on lessons learned.  (3)The manager may recommend communication with the affected campus community for major failed changes. 

Request for Change (RFC) Implementation

After the Request for Change (RFC) has been approved, the MPP manager should ensure the following steps are taken to maximize successful implementation.

1. Communications: Make sure the impacted parties are notified prior to the change and ensure that the appropriate people are available for testing.
2. Planning: Make sure all the parties involved in the Request for Change (RFC) fully understand the change, what their specific tasks are during the change and that they are available and easily contacted during the scheduled change process.
3. Implementation: Follow up to make sure the implementation was performed as stated in the Request for Change (RFC). If there were any issues, failures or other lessons learned, make sure those are documented in the Post Implementation Review (PIR) section of the Request for Change (RFC).
4. Documentation: Make sure the Request for Change (RFC) is marked as completed after successful implementation.