Change Management Notes
January 15, 2009
1. We're under pressure to get the change process defined and build a tool to support it ASAP. In order to help fast track, I will work on things in between meetings and use the meetings to update the group, get approval on the work done and solicit input on upcoming tasks. I'll use e-mail and work one-on-one with people as needed to move things along.
2. Define a standard change.
Based on the ITIL best practices, standard changes:
a. are well known, documented and proven
b. have low risk and the risks are well understood
c. have budget approved in advance
d. have authority given in advance
To help keep things simple, we decided for our standard changes that items a, b and d were the essential criteria to use to define a standard change.
We talked a fair amount about how to assess risk. Different categories of risk we discussed:
- Scope - how many
- Timing
- Business criticality
- User impact
- Location/Dept impact
- Has it been tested? Documentation: what was tested; by whom
- Has this been done before?
- Does the change involve other teams? Which ones? Has it been coordinated?
Several risks are related. Need to come up with risk categories.
Also talked about notification required for standard changes and providing examples of standard changes so people have a frame of reference. Need to consider standard change vs service request, i.e. ACL change vs IP/DNS request.
Delegation: Should the manager of the group submitting the change request approve a standard change?
ALL changes logged.
3. Information that should be part of the request for change:
- RFC #
- Date/time RFC submitted
- Submitter info
- Change category
- Description
- Reason for change (business case when appropriate)
- Effect of not implementing
- Identity of item(s) to be changed - description of desired change
- Predicted timeframe, resources, costs
- Risk assessment and risk management plan
- Back-out or remediation plan
- Impact assessment and evaluation (resources, capacity, cost, benefits)
- Decision and recommendations
- Authorization signature with date and time
- Scheduled implementation time (change window, date and time)
- Change implementation status (success, failure, remediation)
- Actual implementation date and time
- Review date
- Review results
- Closure
List of desired tool features/requirements that came up during discussion
Notification to service desk of change request when RFC is submitted
Notification to users of upcoming change(s)
Notification to CAB/EC of urgent changes
Report of changes: daily, weekly? on Dashboard?
Proxy ability (for approval of changes)
Tie to service catalog and CMDB where possible
Automated FSC
Issues
How to handle new services
How to tie to Service Catalog and CMDB into RFC
CI naming convention
Authorization - backup person
Urgent/Emergency changes
Escalation