Overview of Request For Change (RFC) Review Process

Change Review Board (CRB)

Overview of the process the Change Coordinator and the Change Review Board (CRB) follow for acting on Request for Changes (RFCs), based on procedures from the Change Advisory Board (CAB) and ITIL Change Control and Validation practices.

  • Understand why the change is being made, how it will be made, and what it is supposed to accomplish by:
    • Reviewing the reason, description, implementation steps, and return in the submitted Request for Change (RFC) form. If any of these items are missing, the Request for Change (RFC) will be returned to the requestor for more detail.
    • Reviewing the staff and system resources required to implement.
    • Discussing the Request for Change (RFC) with CRB subject matter experts (SMEs) and departmental representatives to clarify the technical and business aspects.
    • When necessary, communicating with the Request for Change (RFC) implementers, functional users and relevant managers to further clarify.
    • Assessing the additional resources (IT staff, business staff, other systems) required to implement the change
    • Analyzing the effect of not implementing the change
  • Assess the total risk (impact and probability-refer to chart) to services provided to the user community based on:
    • The manager who approves the Request for Change (RFC) is ultimately responsible for assessing the impact of the Request for Change (RFC) before approving it.
    • The CRB will review all high and critical risk Request for Change's (RFC's) and send their recommendation to the CAB. However, they are not allowed to approve these Request for Change's (RFC's).
    • The factors for assessing risk (impact and probability) include: number of clients/systems affected; duration and scope of possible service disruption; availability of work-around; the criticality of the services being disrupted; awareness of the impact to the university.
    • The CRB's understanding of what is being done.
    • An analysis of the risk assessment made by the change implementer and verified by the manager who approved the Request for Change (RFC) for CRB/CAB review.
    • An analysis of other services that run on the same infrastructure or server, that is, other systems and resources that could reasonably be affected by the change.
    • The extent to which the change has been tested, including pre-implementation and post-implementation testing.
    • The details of the restoration plan, should the change produce unintended or undesired results. This includes an assessment of an impact to end-user services, including any possible degradation or interruption of service. If the restoration plan is missing or insufficient, the Request for Change (RFC) will be returned to the requestor for additional details.
  • Assess whether the Implementation schedule is appropriate for the Request for Change (RFC), based on:
    • The total risk to services provided to the user community.
    • Whether the time falls within a scheduled maintenance window for the services affected.
    • Whether the time falls inside or outside normal business hours for the services affected.
    • Whether the time coincides with another ITS activity or known / planned University events (e.g. impact on instruction, finals, beginning or end of quarter, testing, grading, events, etc.)
    • Any special circumstances which would justify any of the above.
  • Check the type of Request for Change (RFC) (normal, emergency) and assess whether it is appropriate, based on the total impact and proposed schedule.
  • Act on our overall assessment of the Request for Change (RFC) by:
    • Passing emergency Request for Changes (RFCs) to the CAB with any appropriate recommendations or information.
    • Passing high impact Request for Changes (RFCs) to the CAB with any appropriate recommendations or information.
    • Passing Request for Changes (RFCs) with unusual circumstances or requirements to the CAB, with any appropriate recommendations or information.
    • Making a determination for all other Request for Changes (RFCs), documenting our review in the Request for Change (RFC) forms, assigning them the appropriate status, and sending email notification to all assignees, contacts and copied users.
  • Assess whether or not communication is needed based on the risk (impact and probability).
    • Communication for all Request for Change's (RFC's) that might affect the entire campus must be sent at least one week in advance.
    • This may affect the implementation date for the Request for Change (RFC).

Change Advisory Board (CAB)

Overview of the Request for Change (RFC) review process by the CAB:

  • The process listed above for the CRB also applies to the CAB.
  • Responsibilities of the CAB:
    • Reviews and approves all high and critical impact Request for Change's (RFC's) no matter the probability.
    • Ensures that Request for Change (RFC) requestors, initiators, and CRB have proper training regarding the change management process.
    • Updates the change management process as needed.
    • Ensures Post Implementation Reviews (PIRs) are performed when required and properly documented.
    • If necessary, the CAB will recommend communication with the affected campus community.