1.DOC #4IT Service Management Change Management Mark McCormack Project Manager, IT Service Management Queensland University of Technology m.mccormack@qut.edu.au http://www.itsmproject.qut.edu.au 4.0 Change Management v1.04 129 March 2007

2. Version Control Version DateReason/Comments/Approvals Number 1.0 2005-10-24First draft 1.012005-11-16Inclusion of process maps, process descriptions, update of process overview, update of Terms of Reference. 1.022005-12-13Update of categorisation matrix definitions and process rules. 1.0.3 2005-12-19Update purpose. 1.0.4 2007-03-29Change Category Matrix Medium changed to Moderate; CAB membership 4.0 Change Management v1.04229 March 2007 3. 4.0 Change Management 4.1Introduction44.1.1 Goal4.1.2 Purpose4.1.3 Benefits4.1.4 Scope4.1.5 KPIs4.1.6 Process Overview4.1.7 Priority Matrix4.1.8 Category Matrix4.2Roles and Responsibilities84.2.1 Change Manager (local area)4.2.2 IT Service Manager (local area)4.2.3 Change Manager (University)4.2.4 CAB Member4.2.5 ITSM Reference Group4.3Process Rules 104.4Process Maps114.5Legend204.5.1 Process4.5.2 People4.5.3 Technology4.6Process Descriptions234.7Self Assessment 414.8Appendix A: TIDG Terms of Reference 464.9Appendix B: CAB Terms of Reference474.10 Appendix C: Approval to Build Checklist 494.11 Appendix D: Approval to Implement Checklist 504.12 Appendix E: CAB Meeting Agenda Template 51 4.0 Change Management v1.04329 March 2007 4. 4.1Introduction4.1.1 Goal The goal of the Change Management process is to ensure that standardised methods and procedures are used for efficient and prompt handling of all Changes, in order to minimise the impact of Change-related Incidents upon service quality, and consequently to improve the day-to-day operations of the organisation (Service Support, CCTA, 2000). 4.1.2 Purpose This document defines the Change Management process and associated process rules to be adopted across all IT areas at QUT. Guidance in following these processes is provided by a series of process rules. These provide a measure of compliance to the process, and will be used to guide the continuous improvement of the process. The ITIL Self Assessment tool is also included, and is used to provide a measure of process maturity. The Change Management process is to be used by IT staff across all faculties and divisions of QUT involved in defining, implementing and supporting change to services provided to university clients. A glossary of ITIL terms can be found at http://www.ogc.gov.uk/embedded_object.asp?docid=1000379. 4.1.3 Benefits Benefits of Change Management include: Reduced adverse impact of changes on the quality of IT services. Improved client productivity. Fewer changes are reversed, and any back-outs that are implemented proceed more smoothly. Improved IT staff productivity through less need for urgent changes and fewer calls for back-out procedures. Increased ability to accommodate frequent changes without creating an unstable IT environment. Enhanced management reporting is available which enables better diagnosis of problem areas. Better estimate of costs of proposed changes. Source: IT Service Management: An introduction based on ITIL, 2004, itSMF 4.1.4 Scope The Change Management process at QUT applies to all changes to Configuration Items (see Configuration Management). This includes hardware, software and documentation. 4.1.5 KPIs Percentage increase in process rule adoption. ITIL Self Assessment process maturity level. Others as agreed by the Change Advisory Board. 4.0 Change Management v1.04429 March 2007 5. 4.1.6 Process OverviewProject Management Service Management FrameworkFrameworkProblem Incident Project ManagementManagement ManagementNTIDG AssessY Classify Project ProposalRFC (Build)Y N Significant? (see matrix)Classify N Significant? (see matrix)Y Y TIDG/CAB?TIDG AssessmentNCAB AssessmentCAB Assessment(build checklist) (build checklist)Approve?Approve? ScheduleSchedule Project Rel. / Prob. Project Rel. / Prob.ManagementManagement ManagementManagementPlan CoordinatePlan Plan Coordinate Plan --- - BuildBuildBuild Build --- - Test Test TestTest --- -Rollout University RolloutRollout ChangeRollout PlanningCABPlanning PlanningCoord PlanningCAB Assessment Assessment RFC(imp. checklist) RFCRFC (imp. checklist)RFC(Implement) (Implement)(Implement) (Implement) Approve?Approve? ScheduleSchedule Project Rel. / Prob. Project Rel. / Prob.CoordinateCoordinateManagementManagement ManagementManagementCommunicateCommunicateCommunicate Communicate--- - EvaluateEvaluate RolloutRolloutRollout Rollout4.0 Change Management v1.045 29 March 2007 6. 4.1.7 Priority Matrix Urgency ImpactProjectLow MediumHigh Project ProjectProject Project Project Low Project Low LowMedium MediumProjectMedium HighHigh HighProjectMedium High CriticalUrgency Description Project There is no urgency to complete the task. Low Client is able to work. Little or no functionality is unavailable. MediumClient is able to work. Some functionality is unavailable. HighClients ability to work is severely impeded. ImpactDescription Project There is no impact on the clients ability to work. Low One client is affected. MediumVIP or a group of clients is affected. HighEntire area affected (building, campus, major system) 4.0 Change Management v1.046 29 March 2007 7. 4.1.8 Category MatrixBusiness ContinuityBusiness ImpactLow Medium HighLow Minor MinorModerateMediumModerateMajorMajorHighModerateMajorSignificant Business Description Continuity LowNegligible risk of business disruption if Change fails.Medium Moderate risk of business disruption if Change fails.High Certain risk of business disruption if Change fails. BusinessDescription Impact LowChange affects part of one area or a small client group. Medium Change affects a single faculty/division or medium/criticalclient group. High Change affects more than one faculty/division or a largeclient group. 4.0 Change Management v1.04 7 29 March 2007 8. 4.2 Roles and Responsibilities 4.2.1 Change Coordinator The main duties of the Change Coordinator for changes in their local area are outlined below. 1. Ensure RFCs are submitted for all changes. 2. Assist University Change Manager with allocating a priority to all significant RFCs. 3. Ensure all significant RFCs are forwarded to the University Change Manager. 4. Reject any impractical RFCs. 5. Coordinate local area change building, testing and implementation. 6. Update change logs as required. 7. Review all outstanding RFCs. 8. Perform trend analysis on all change records. 9. Produce reports for the University Change Manager on the progress and review of changes.4.2.2 IT Service Manager (local area) The main duties of the IT Service Manager for changes in their local area are outlined below. 1. Monitor the Change Management process. 2. Produce Change Management reports. 3. Provide recommendations for Change Management process improvement to the University Change Manager.4.2.3 Change Manager The main duties of the University Change Manager are outlined below. 1. Receive and register all significant RFCs. 2. Allocate a priority to all RFCs with assistance from the RFC Initiator. 3. Reject any impractical RFCs. 4. Issue CAB meeting agendas and circulate all RFCs to CAB members. 5. Table all significant RFCs at CAB meetings. 6. Determine list of invited guests for CAB meetings in relation to tabled RFCs. 7. Coordinate CAB or CAB/EC meetings for all emergency changes. 8. Chair all CAB and CAB/EC meetings. 9. Authorise acceptable changes following consideration and advice from CAB or CAB/EC. 10. Issue FSCs via the Service Desk. 11. Coordinate change building, testing and implementation through liaison with appropriate people. 12. Update change logs as required. 13. Review changes to ensure they have met their objectives. 14. Refer all failed changes to the CAB. 15. Review all outstanding RFCs. 16. Perform trend analysis on all change records. 17. Close RFCs. 18. Produce reports for the CAB and management.4.2.4 CAB Member The main duties of a CAB member are outlined below. 1. Review all RFCs submitted to the CAB. 2. Where possible, determine and provide details of impact, resource and costassessment. 3. Attend all relevant CAB and CAB/EC meetings.4.0 Change Management v1.04 829 March 2007 9. 4. Consider all changes and give opinion on which changes should beauthorised. 5. Assist in the scheduling of changes. 6. Assist with consultation on urgent changes through CAB/EC. 7. Provide recommendations for Change Management process improvement tothe Change Manager.4.2.5 ITSM Reference Group The main duties of the ITSM Reference Group are outlined below. 1. Drive the implementation and continuous improvement of ChangeManagement across all QUT faculties and divisions. 2. Report to ITCG on IT Service Management activities. 4.0 Change Management v1.049 29 March 2007 10. 4.3 Process Rules 4.0 Change Management v1.04 10 29 March 2007 11. 0.Overall Process Rule Benefit 0.1 The focus on all Change Management effort is to ensure thatImproved service delivery. standardised methods and procedures are used for efficient Less demand on Incident Management. and prompt handling of all changes, in order to minimise the impact of change related incidents upon service quality. 0.2 Every action in relation to a change is to be documented within Assist with communication with clients and other change request record. stakeholders. 0.3 Any relationships to existing incidents or problems are Assists with recovery from incidents and problems. communicated to all relevant staff. Reduce business downtime. 0.4 The QUT Change Management tool will be used to log all Increase integration between IT service areas. RFCs. Assist with communicating changes. 0.5 All RFCs are to be categorised using the Change Management All changes are authorised with the correct level of Categorisation Matrix. authority. 1.Recording & Filtering Process Rule Benefit 1.1 An RFC is to be submitted for every significant change to the IT A record is kept of all changes to the infrastructure. infrastructure.Track the number of changes to the infrastructure. 1.2 All RFCs are to be reviewed and filtered by the ChangeOnly legitimate changes are forwarded for approval. Coordinator. Change coordinators are aware of all local changes. 2.Classification Process Rule Benefit 2.1 All minor/moderate/major changes requiring CAB discussionEscalation path available for Change Coordinators. are to be forwarded to the University Change Manager. 2.2 All significant changes are to be forwarded to the University Significant changes are formally approved and Change Manager.communicated at university level. 3.Impact & Resource Assessment Process Rule Benefit 3.1 An impact and resource assessment is carried out for all All changes are assessed against common criteria. changes (see checklist). 4.Approval Process Rule Benefit 4.1 Financial approval is obtained for all changes.Changes are implemented with correct approval. 4.2 Technical approval is obtained for all changes.Changes are implemented with correct approval. 4.3 Business approval is obtained for all changes. Changes are implemented with correct approval. 5.Scheduling Process Rule Benefit 5.1 The FSC is updated with details of all approved changes. All changes are advertised to the university. 5.2 Changes are communicated to all relevant stakeholders andAll stakeholders affected by a change have an client groups.awareness of what the change entails. 6.Coordination Process Rule Benefit 6.1 Changes which can be incorporated into a release are to be Larger changes are introduced into the university forwarded to either Release Management or Project using a formalised and coordinated approach. Management for coordinated implementation. 6.2 Full or partial roll-back is to be considered for any changes Reduced business downtime. which fail to meet objectives, or adversely impact the business. 6.3 All changes to CIs are to be referred to Configuration Infrastructure configuration details are kept up to Management.date. 7.Evaluation Process Rule Benefit 7.1 Client/Customer feedback is to be sought for all changes.Provision of feedback to improve quality of service. 7.2 All completed changes are to be matched against currentReduce the number of active incidents/problems. incidents and problems.Reduced business downtime. 7.3 A record is to be kept as to whether a change has achieved its Measure of changes which achieve their objectives. stated objectives. 7.4 Changes are formally reviewed and evaluated at the discretion Changes are reviewed to evaluate the quality of of the Change Coordinator, Change Manager or CAB.implementation. 7.5 All completed changes are to be closed. Provides statistics for reporting on closed changes. 4.0 Change Management v1.0411 29 March 2007 12. 4.4 Process Maps 4.0 Change Management v1.04 12 29 March 2007 13. DOC #ClassificationImpact &1. Change ManagementRecording &Resource Approval SchedulingCoordination EvaluationFiltering Assessment Recording & Filtering1. Project Management8. Configuration15. Impact & Resource 5. Approval Management [Control]Assessment2. Problem Management9. Incident Management [Error Handling]6. Coordination[Investigation & 16. Classification Diagnosis]3. Incident Management 10. Incident Management[Resolution & Recovery][Resolution & Recovery] 7. Completed4. Need for11. 17. AppealemergencyInconsistentChange change to beCI detailsrejectedDetermined registered RFCdetected--- EMERGENCY CHANGE14. Enter details on RFC 12. 18. Update RFCform.Inaccurate CI record for30. Problem Managementreporting [Error Handling] Change RFCRFC ToolInitiator13.ConfigurationInitiator31. Incident ManagementManagement[Resolution & Recovery] [Status Accounting] ChangeRFC32. NeedTool19. Submit RFC toInitiator for Change Management emergencyChangeRFC Determined InitiatorChange Coord. 20. Initial review of RFCs Service Owner 33. Enter details on RFC 34. Prepare form when possible andcommunications for CAB/ submit to Change EC Management. 21. Are any YRFCsrejected? ChangeTool 35.Commu 25. Document reasonsChange Change nicationsfor rejection in ChangeCoord. Coord. prepared Management action log. for CAB/ECN Change22. Update RFC status to 26. Return RFC toChangeTool Acceptanceinitiator Coord. 36. ClassificationChangeTool --- EMERGENCY CHANGE23. RFCAccepted 27. Appeal Ydecision to reject RFC?24. Classification N28. Close RFC Change RFCToolInitiator 29. ChangeRejected4.0 Change Management v1.0413 29 March 2007 14. 4.0 Change Management v1.04 14 29 March 2007 15. ClassificationImpact &2. Change ManagementRecording & Resource ApprovalScheduling CoordinationEvaluation FilteringAssessment Classification 1. Recording & FilteringChangeChange ToolMgr18. Is advice--- EMERGENCY CHANGE --- from the Y Change Change Mgr Coord.2. RFC required for acceptedchangeapproval? 33. Recording & Filtering19. Submit informally to Change Manager for advice N 3. Review Priority and34.Categorisation Communicatio RFC n prepared for InitiatorCAB/ECChange MgrChangeCoord. 20. Is changeChangeto be Y Coord.4. Is change 35. Convene/adviseY forwarded forcategoryCAB/EC approval? minor?21. Update RFC form. CAB EC 36. Emergency Change N communicated NChangeTool22. Change 5. Request FSC and/or PSAdoes notdetails associated to RFC require CAB 24. Doesdiscussion change needN37. Impact & ResourcefurtherAssessmentdiscussion?ChangeCoord. 23. Impact & Resource Assessment--- EMERGENCY CHANGE --- 6. Is Change Y categorymoderate/ Y Major (see catmatrix)?25. Change requires CABChange discussionCoord. 7. DoesN N change require CAB discussion? 12. Change categorised as 26. Impact & Resource 10. Change significant Assessment does not require CABdiscussionY8. Change requires CAB discussion11. Impact & ResourceAssessment13. Is N escalation toSenior Managementrequired? 9. Impact & ResourceAssessment ChangeY Tool 14. Forward RFC to seniormanagement (eg. ITAC,P&V, VCAC) CommunicationChange 27. Document reasons forCoord.rejection and return to RFCChangeinitiator. Mgr15. Has change been Napproved by seniorChange management?Tool 28. Appeal N RFC decision toInitiatorreject RFC? Y31. Close RFC.Y 16. Change requires CAB29. Appeal32. Change discussion rejected RFCRejected17. Impact & Resource 30. Recording & FilteringAssessment 4.0 Change Management v1.0415 29 March 2007 16. ClassificationImpact &3. Change ManagementRecording & FilteringResourceApproval SchedulingCoordination Evaluation Assessment Impact & Resource8. Configuration1. Classification Assessment Management[Control] 6. Configuration 4. Evaluation Management--- EMERGENCY CHANGE --- [Audit] 2. Change9. New CI requires CABrejected discussion 7. 29. Classification 5. ChangeConfiguratioreview to ben audit tabled.report3. Obtainadvice/recommendations available10. Report rejected CI from TIDG if required. 30.Emergency change communicate Config CMDBCommunicationStaff14. Classification31. Conduct impact and11. Plan and schedule resource assessment CABCAB meetingECChange 15. Change ChangeMgr does not Coord. 12. Circulate agenda and require CABall RFCs, PSAs anddiscussionFSC updates to CAB32. Shouldmembers prior to meetingchange beY rejected?Change Mgr13. Hold CAB meetingCAB N 33. CMDBEmergencyimpact and resourceRFCassessment 16. Conduct impact andInitiatorresource assessment [Checklist] ConfigStaff 34. Approval 17. Review changeCAB priority 35. Lodge RFC andRFCChangecomplete formal change Initiator Mgrdocumentation andproceduresChangeCoord.18. Should 36.the changeYEmergencypriority be change to be altered?registered Change 19. Update priority Coord. ChangeNToolChange 37. Recording & FilteringMgr--- EMERGENCY CHANGE --- Change 20. Is impact Coord.23. Document reasons for and resource Nrejection and return to assessment RFC initiator.Changeapproved?MgrChange ToolYRFC 21. Change24. Appeal N Initiator impact anddecision toresourcereject RFC? assessmentcomplete27. Close RFC. ChangeToolY 22. Approval 25. Appeal rejected 28. Change RFC Rejected 26. Recording and 4.0 Change Management v1.04 16 Filtering 29 March 2007 17. 4.0 Change Management v1.04 17 29 March 2007 18. Classification Impact & Recording & 4. Change Management Filtering ResourceAssessment Approval SchedulingCoordination EvaluationApproval1. Impact & Resource Assessment --- EMERGENCY CHANGE --- 2. Change impact andRFC resourceInitiator 4. Determine who will assessment provide financial approval 21. Impact & Resource completefor change. Change Assessment Coord. 22.Emergency3. Is financialimpact andapprovalY 5. Is there resource required for financialNassessment the change? approval for completethe change?N 23. Is thereYfinancial Napproval forthe change?RFC Initiator 7. Determine who will6. Is provide technical technical approval for change.ChangeY Yapproval Coord.required for the change?24. Is theretechnical Napproval for8. Is therethe change? NtechnicalN approval for the change? YY9. Is business Y 25. Is there approvalbusinessN required forapproval for the change? RFCthe change?Initiator10. Determine who will provide business approval for change.ChangeNCoord.ChangeYTool26. Emergency Change 11. Is there 14. Update status of RFCApproved business Nto Approved, and inform approval for RFC initiator of approval. the change? Change 12. Document reasons for Coord. 27. Scheduling 15. Update university rejection and return to FSC and PSARFC initiator. YChangedocuments. MgrChange Change 28. Lodge RFC andRFCCoord.Tool complete formal change Initiator13. Change documentation andRejected proceduresChange16. Are any Mgr changesYrequired to29. SLAs? Emergencychange to be registeredN 30. Recording & Filtering19. SLA17. Change Changes Approved required --- EMERGENCY CHANGE ---20. Service Level 18. SchedulingManagement []4.0 Change Management v1.0418 29 March 2007 19. 4.0 Change Management v1.04 19 29 March 2007 20. ClassificationImpact & Recording & 5. Change Management Filtering Resource Assessment Approval Scheduling Coordination EvaluationScheduling 1. Approval 3. Release Management [Acceptance] --- EMERGENCY CHANGE --- 2. Change 4. Release 13. Approval approved requiresrescheduling14.Emergencychange approved RFC5. Make Initiator recommendations to theServiceallocation of resourcesOwner15. Consult FSC andPSA and advertise toorganisation 6. Update FSC and PSAChangeand advertise toMgrorganisation 16.Emergency changescheduled7. Distribute FSC andPSA to those outsideWWWCRMservice management via 17. Coordination customer liaison process Change 8. Forward changeCoord. --- EMERGENCY CHANGE --- schedules to all other processesChange Mgr9. Forward changeschedules outside of Communicationservice management via CRM SD, SLM, CRM SLM Staff10. Reinforce informationthrough proactiveawareness programme to CRM areas of specific impact.ChangeCoord. 11. Changescheduled Change Mgr12. Coordination4.0 Change Management v1.04 20 29 March 2007 21. 4.0 Change Management v1.04 21 29 March 2007 22. Recording & Classification Impact & ApprovalScheduling CoordinationEvaluation 6. Change Management Filtering Resource AssessmentCoordination 1. Release Management 5. Scheduling[Distribution &Installation] 2. Release Management --- EMERGENCY CHANGE ---[Acceptance]6. Changescheduled30. Scheduling Change 7. Dispatch authorised Coord.31.RFCs for changeEmergency development / build / test. Change3. Change changestatus report Mgrscheduledavailable Change Coord. Change32. Dispatch authorisedMgr RFCs for change development / build / test. 4. Receive change statusreport.ChangeTool33. Coordinate communication of changeto customers and users.Change22. Record all costs and 8. Coordinate Coord.resources used in RFC communication of change RFC34. Coordinate andto customers and users.record. Initiator monitor changeChange implementation.CRM Staff 35. Lodge RFC andcomplete formal change 23. Isdocumentation andY 9. Is rollback specific Yprocedures required?configurationaudit required?RFC 36.InitiatorCompletedemergency change to beNNregistered37. Recording & Filtering14. Have any YCIs been 24. Specific changed? configuration audit required --- EMERGENCY CHANGE ---N 25.Configuration Change Management Coord.[Control]26. Change 15. Change 17. Coordinate andapproved to CI details monitor change implementation. 16. Configuration Management 27. Incident Management [Control]18. Has [Resolution & Recovery]change been Nimplemented ?Service 28. Problem ManagementOwner[Error Handling]10. Request rollback ofchanges. PM Staff Y29. Release Management[Planning] 19. UpdateChange11. Changedocumentation Coord.rollbackChange requiredTool20. ChangeImplemented12. Release Management13. Problem Management[Distribution & [Error Handling]Installation] 21. Evaluation4.0 Change Management v1.0422 29 March 2007 23. Classification Impact &Recording & 7. Change ManagementFiltering ResourceAssessmentApproval SchedulingCoordination EvaluationEvaluation 1. Coordination2. Change implemented Change3. Review change.Coord. Change 4. Gather feedback fromCoordChangecustomer. ToolCRMCAB 5. Is CABinput orYassistancerequired in Change review Coord. process? 6. Involve CAB in reviewprocess. ChangeMgrN 7. Determine if change achieved its objectives.8. Does changereview need Y tabling at CABfor follow-up action or info? ChangeMgr9. Schedule tabling ofchange review at next CABmeeting.N12.Feedback outcomes to CAB, customer, ReleaseCommunicationManagement, and other 10. Changeinterested parties.review to betabled.Change 13. Update Change ToolManagement action log and update FSC. 11. Impact & Resource Assessment14. RFC is formally closed.Change Coord. ChangeMgr 15. Change completed. 4.0 Change Management v1.04 23 29 March 2007 24. 4.5 Legend 4.5.1 Process 4.0 Change Management v1.04 24 29 March 2007 25. SymbolDescriptionCurrent Process: This is a link to or from an activity or sub process within the current process.Alternate Process: This is a link to or from a process outside of the current process. Event: This is the status of information at single point in time. Function: This is a task to be carried out. Decision: This is a decision point to determine the flow of the process.Logical XOR0 00 The process comes from 0 11 or goes to one path only. 1 01 1 10 Logical AND0 00 The process comes from 0 10 or goes to all paths. 1 00 1 11 4.5.2 People 4.0 Change Management v1.04 2529 March 2007 26. SymbolDescriptionService Desk staffSD Staff (Level 1 Incident Management) IncidentStaff Incident Management staffProblemStaff Problem Management staffChangeManager Change Manager ChangeCoord. Change CoordinatorConfig.Staff Configuration Management staffRelease Staff Release Management staffSLMStaff Service Level Management staffFinancialStaff Financial Management staffCapacity Staff Capacity Management staffContinuity IT Service Continuity ManagementStaff staff Avail.Staff Availability Management staffSecurity Staff IT Security Management staffCABChange Advisory Board membersCABChange Advisory Board/Emergency ECChange members 4.0 Change Management v1.042629 March 2007 27. Symbol DescriptionRFCPerson who submits a Request forInitiator ChangeCRM Client Relations Manager (ITS)ServicePosition responsible for the day-to-Owner day delivery of the service ClientPerson who uses services provided by IT External Support staff external to theSupport University 4.5.3 TechnologySymbol Description Application System Communication System 4.0 Change Management v1.042729 March 2007 28. 4.6 Process Descriptions 4.0 Change Management v1.0428 29 March 2007 29. 1. Change ManagementRecording & Filtering ClassificationImpact & ResourceAssessment Approval Scheduling Coordination Evaluation Recording & Filtering1. Project Management This part of the process links from the Project Management Framework.2. Problem Management [Error Handling] This part of the process links from the Problem Management [Error Handling] process.3. Incident Management [Resolution & Recovery] This part of the process links from the Incident Management [Resolution & Recovery] process.4. Need for Change Determined A change of the IT infrastructure is required.5. Approval This part of the process links from the Change Management [Approval] process.6. Coordination This part of the process links from the Change Management [Coordination] process.7. Completed emergency change to be registered An emergency change has flowed through the process, and now needs to be documented.8. Configuration Management [Control] This part of the process links from the Configuration Management [Control] process.9. Incident Management [Investigation & Diagnosis] This part of the process links from the Incident Management [Investigation & Diagnosis] process.10. Incident Management [Resolution & Recovery] This part of the process links from the Incident Management [Resolution & Recovery] process.11. Inconsistent CI details detected CI details on the infrastructure are different from the details listed in the CMDB.12. Inaccurate CI record for reporting Details of an inaccurately recorded CI need to be reported to Configuration Management.13. Configuration Management [Status Accounting] This part of the process links to the Configuration Management [Status Accounting] process.14. Enter details on RFC form. Details of the RFC are to be registered. 4.0 Change Management v1.0429 29 March 2007 30. 15. Impact & Resource Assessment This part of the process links from the Change Management [Impact & Resource Assessment] process.16. Classification This part of the process links from the Change Management [Classification] process.17. Appeal rejected RFC A rejected RFC is being appealed.18. Update RFC The RFC is updated with new details to support the appeal.19. Submit RFC to Change Management The RFC is forwarded to Change Management.20. Initial review of RFCs The RFCs receive an initial review to determine if they should continue through the Change Management process.21. Are any RFCs rejected? This determines if an RFC should be accepted and continue through the Change Management process.22. Update RFC status to Acceptance The status of the RFC is changed to Accepted to reflect that it is to continue through the Change Management process.23. RFC Accepted The RFC status has been changed to being accepted.24. Classification This part of the process links to the Change Management [Classification] process.25. Document reasons for rejection in Change Management action log. The reasons for rejection of the change are recorded within the RFC log.26. Return RFC to initiator The rejected RFC is returned to the initiator.27. Appeal decision to reject RFC? The RFC initiator has the right to appeal a decision to reject the change.28. Close RFC The RFC has its status changed to closed.29. Change Rejected The change has been rejected.30. Problem Management [Error Handling] This part of the process links from the Problem Management [Error Handling] process. 4.0 Change Management v1.043029 March 2007 31. 31. Incident Management [Resolution & Recovery] This part of the process links from the Incident Management [Resolution & Recovery] process.32. Need for emergency Change Determined It has been determined that a change should be dealt with as an emergency, as it cannot wait for the process before the change is made.33. Enter details on RFC form when possible and submit to Change Management. If time permits, the details of the change request should be logged on the change form.34. Prepare communications for CAB/EC Details of the change are to be prepared for communication to the CAB/EC.35. Communications prepared for CAB/EC Communications have been prepared for the CAB/EC.36. Classification This part of the process links to the Change Management [Classification] process. 4.0 Change Management v1.0431 29 March 2007 32. 2. Change ManagementRecording & Filtering ClassificationImpact & ResourceAssessment Approval Scheduling Coordination EvaluationClassification1. Recording & Filtering This part of the process links from the Change Management [Recording & Filtering] process.2. RFC accepted The submitted RFC has been accepted.3. Review Priority and Categorisation The priority and categorisation of the RFC are reviewed for accuracy against the category matrix.4. Is change category minor? From the categorisation of the RFC, it is determined if the change is minor.5. Request FSC and/or PSA details associated to RFC The FSC and PSA associated with the change are requested if required.6. Is Change category Moderate/Major (see cat matrix)? From the categorisation of the RFC, it is determined if the change is moderate or major.7. Does change require CAB discussion? Determine if the change needs to be discussed by the CAB.8. Change requires CAB discussion It has been determined that the change does need to be discussed by the CAB.9. Impact & Resource Assessment This part of the process links to the Change Management [Impact & Resource Assessment] process.10. Change does not require CAB discussion It has been determined that the change does not need to be discussed by the CAB.11. Impact & Resource Assessment This part of the process links to the Change Management [Impact & Resource Assessment] process.12. Change categorised as significant From the categorisation of the RFC, it is determined if the change is significant.13. Is escalation to Senior Management required? Determine if senior management need to provide any input into the decision regarding the change.14. Forward RFC to senior management (eg. ITAC, P&V, VCAC) The change is to be forwarded to senior management for discussion / advice / recommendations and approval. 4.0 Change Management v1.0432 29 March 2007 33. 15. Has change been approved by senior management? Determine if senior management have approved the change.16. Change requires CAB discussion The RFC needs to be forwarded to the CAB for discussion.17. Impact & Resource Assessment This part of the process links to the Change Management [Impact & Resource Assessment] process.18. Is advice from the Change Mgr required for change approval? Determine if an RFC needs to be escalated in order to have it approved.19. Submit informally to Change Manager for advice Forward RFC to Change Manager for advice.20. Is change to be forwarded for approval? Determine if it is OK to forward the change for approval.21. Update RFC form. The RFC form is to be kept up to date of all details and decisions regarding the change.22. Change does not require CAB discussion It has been decided that the RFC does not need to be forwarded to the CAB.23. Impact & Resource Assessment This part of the process links to the Change Management [Impact & Resource Assessment] process.24. Does change need further discussion? Determine if the RFC requires further discussion.25. Change requires CAB discussion It has been decided that the RFC does need to be forwarded to the CAB.26. Impact & Resource Assessment This part of the process links to the Change Management [Impact & Resource Assessment] process.27. Document reasons for rejection and return to RFC initiator. The RFC form is to be kept up to date of all details and decisions regarding the rejection.28. Appeal decision to reject RFC? The RFC initiator has the right to appeal a decision to reject the change.29. Appeal rejected RFC It has been decided to appeal the decision to reject the RFC.30. Recording & Filtering This part of the process links to the Change Management [Recording & Filtering] process. 4.0 Change Management v1.04 33 29 March 2007 34. 31. Close RFC. The RFC has its status changed to closed.32. Change Rejected The RFC has been rejected.33. Recording & Filtering This part of the process links from the Change Management [Recording & Filtering] process.34. Communication prepared for CAB/EC Communications have been prepared for the CAB/EC.35. Convene/advise CAB/EC The CAB/EC is made aware of the details of the change request.36. Emergency Change communicated The details of the change have been communicated to the CAB/EC.37. Impact & Resource Assessment This part of the process links to the Change Management [Impact & Resource Assessment] process. 4.0 Change Management v1.04 3429 March 2007 35. 3. Change Management Recording &FilteringClassificationImpact &Resource AssessmentApproval Scheduling Coordination EvaluationImpact & ResourceAssessment1. Classification This part of the process links from the Change Management [Classification] process.2. Change requires CAB discussion It has been decided that the RFC does need to be forwarded to the CAB.3. Obtain advice/recommendations from TIDG if required. RFCs are forwarded to TIDG for discussion as required.4. Evaluation This part of the process links from the Change Management [Evaluation] process.5. Change review to be tabled. A review of a change is available, and is to be forwarded to the CAB for tabling.6. Configuration Management [Audit] This part of the process links from the Configuration Management [Audit] process.7. Configuration audit report available An audit report from Configuration Management is available.8. Configuration Management [Control] This part of the process links from the Configuration Management [Control] process.9. New CI rejected A new CI has been rejected by Configuration Management.10. Report rejected CI A rejected CI is being reported by Configuration Management.11. Plan and schedule CAB meeting The next CAB meeting is planned and scheduled.12. Circulate agenda and all RFCs, PSAs and FSC updates to CAB members prior to meeting. Materials in relation to the next CAB meeting are made available for members.13. Hold CAB meeting The CAB meeting is run.14. Classification This part of the process links to the Change Management [Classification] process.15. Change does not require CAB discussion It has been determined that the change does not need to be discussed by the CAB.16. Conduct impact and resource assessment [Checklist] An assessment of the proposed change is carried out. 4.0 Change Management v1.04 35 29 March 2007 36. 17. Review change priority The priority of the change is reviewed to ensure it is accurate.18. Should the change priority be altered? Determine if the change priority should be altered.19. Update priority The priority of the RFC is updated.20. Is impact and resource assessment approved? Determine if the impact and resource assessment is satisfactory.21. Change impact and resource assessment complete The impact assessment for the RFC has been completed.22. Approval This part of the process links to the Change Management [Approval] process.23. Document reasons for rejection and return to RFC initiator. The RFC form is to be kept up to date of all details and decisions regarding the rejection.24. Appeal decision to reject RFC? The RFC initiator has the right to appeal a decision to reject the change.25. Appeal rejected RFC It has been decided to appeal the decision to reject the RFC.26. Recording and Filtering This part of the process links to the Change Management [Recording and Filtering] process.27. Close RFC. The RFC has its status changed to closed.28. Change Rejected The RFC has been rejected.29. Classification This part of the process links to the Change Management [Classification] process.30. Emergency change communicated The details of the change have been communicated to the CAB/EC.31. Conduct impact and resource assessment An assessment of the proposed change is carried out.32. Should change be rejected? Determine if the change should be rejected.33. Emergency impact and resource assessment complete The emergency impact assessment for the RFC has been completed.34. Approval This part of the process links to the Change Management [Approval] process. 4.0 Change Management v1.043629 March 2007 37. 35. Lodge RFC and complete formal change documentation and procedures Submit the RFC to the change process and document all activities associated with the change.36. Emergency change to be registered An emergency change has flowed through the process, and now needs to be documented.37. Recording & Filtering This part of the process links to the Change Management [Recording & Filtering] process. 4.0 Change Management v1.043729 March 2007 38. 4. Change Management Recording &FilteringClassificationImpact &Resource AssessmentApproval Scheduling Coordination EvaluationApproval1. Impact & Resource Assessment This part of the process links to the Change Management [Impact & Resource Assessment] process.2. Change impact and resource assessment complete The impact assessment for the RFC has been completed.3. Is financial approval required for the change? Determine if the change requires financial approval.4. Determine who will provide financial approval for change. Determine the correct person to provide approval.5. Is there financial approval for the change? Determine if the change has financial approval.6. Is technical approval required for the change? Determine if the change requires technical approval.7. Determine who will provide technical approval for change. Determine the correct person to provide approval.8. Is there technical approval for the change? Determine if the change has technical approval.9. Is business approval required for the change? Determine if the change requires business approval.10. Determine who will provide business approval for change. Determine the correct person to provide approval.11. Is there business approval for the change? Determine if the change has business approval.12. Document reasons for rejection and return to RFC initiator. The RFC form is to be kept up to date of all details and decisions regarding the rejection.13. Change Rejected The RFC has been rejected.14. Update status of RFC to Approved, and inform RFC initiator of approval. Update the RFC status, and communicate status to the RFC Initiator.15. Update university FSC and PSA documents. The FSC and PSA are updated with latest information, and are made available to all stakeholders.16. Are any changes required to SLAs? Determine if any changes are required to existing SLAs. 4.0 Change Management v1.04 38 29 March 2007 39. 17. Change Approved The change has had its status updated to Approved.18. Scheduling This part of the process links to the Change Management [Scheduling] process.19. SLA Changes required Changes are required to existing SLAs.20. Service Level Management [] This part of the process links to the Service Level Management [] process.21. Impact & Resource Assessment This part of the process links to the Change Management [Impact & Resource Assessment] process.22. Emergency impact and resource assessment complete The emergency impact assessment for the RFC has been completed.23. Is there financial approval for the change? Determine if the change has financial approval.24. Is there technical approval for the change? Determine if the change has technical approval.25. Is there business approval for the change? Determine if the change has business approval.26. Emergency Change Approved The emergency change has been approved.27. Scheduling This part of the process links to the Change Management [Scheduling] process.28. Lodge RFC and complete formal change documentation and procedures Submit the RFC to the change process and document all activities associated with the change.29. Emergency change to be registered An emergency change has flowed through the process, and now needs to be documented.30. Recording & Filtering This part of the process links to the Change Management [Recording & Filtering] process. 4.0 Change Management v1.04 39 29 March 2007 40. 5. Change ManagementRecording & Filtering ClassificationImpact & ResourceAssessment Approval Scheduling Coordination Evaluation Scheduling1. Approval This part of the process links to the Change Management [Approval] process.2. Change approved The change has had its status updated to Approved.3. Release Management [Acceptance] This part of the process links to the Release Management [Acceptance] process.4. Release requires rescheduling A planned release needs to be rescheduled.5. Make recommendations to the allocation of resources Change Management provides recommendations for the allocation of resources.6. Update FSC and PSA and advertise to organisation The FSC and PSA are updated with latest information, and are made available to all stakeholders.7. Distribute FSC and PSA to those outside service management via customer liaison process The FSC and PSA are distributed to stakeholders via the customer liaison process.8. Forward change schedules to all other processes The FSC is made available to all other service management processes.9. Forward change schedules outside of service management via SD, SLM, CRM The FSC is made available to areas outside of the service management processes.10. Reinforce information through proactive awareness programme to areas of specific impact. Communicate changes to areas who will be affected by the changes.11. Change scheduled The approved change has been scheduled.12. Coordination This part of the process links to the Change Management [Coordination] process.13. Approval This part of the process links to the Change Management [Approval] process.14. Emergency change approved The emergency change has been approved.15. Consult FSC and PSA and advertise to organisation Advertise the change to all stakeholders. 4.0 Change Management v1.0440 29 March 2007 41. 16. Emergency change scheduled The approved emergency change has been scheduled.17. Coordination This part of the process links to the Change Management [Coordination] process. 4.0 Change Management v1.04 4129 March 2007 42. 6. Change Management Recording &FilteringClassificationImpact &Resource AssessmentApproval Scheduling Coordination EvaluationCoordination1. Release Management [Distribution & Installation] This part of the process links to the Release Management [Distribution & Installation] process.2. Release Management [Acceptance] This part of the process links to the Release Management [Acceptance] process.3. Change status report available A status report on the progress of a change is available.4. Receive change status report. The change status report has been received by Change Management.5. Scheduling This part of the process links to the Change Management [Scheduling] process.6. Change scheduled The approved change has been scheduled.7. Dispatch authorised RFCs for change development / build / test. Authorised changes are dispatched to other processes.8. Coordinate communication of change to customers and users. Changes are communicated to customers and users who will be affected.9. Is rollback required? Determine if the change is successful, and whether a rollback is required.10. Request rollback of changes. Request to the change implementer that a change rollback is required.11. Change rollback required A change needs to be rolled back.12. Release Management [Distribution & Installation] This part of the process links to the Release Management [Distribution & Installation] process.13. Problem Management [Error Handling] This part of the process links to the Problem Management [Error Handling] process.14. Have any CIs been changed? Determine if any CIs have been introduced, altered or removed as a result of the change.15. Change to CI details CI details have been changed.16. Configuration Management [Control] This part of the process links to the Configuration Management [Control] process. 4.0 Change Management v1.04 42 29 March 2007 43. 17. Coordinate and monitor change implementation. The change implementation is coordinated and monitored by Change Management. They do not carry out the change.18. Has change been implemented? Determine if a change has been implemented.19. Update documentation All details regarding the change are to be updated on the RFC.20. Change Implemented The change has been implemented.21. Evaluation This part of the process links to the Change Management [Evaluation] process.22. Record all costs and resources used in RFC record. All details regarding the change are to be updated on the RFC.23. Is specific configuration audit required? Determine if an audit of a part of the infrastructure is required to be carried out prior to a change.24. Specific configuration audit required A specific configuration audit has been requested.25. Configuration Management [Control] This part of the process links to the Configuration Management [Control] process.26. Change approved The change has been approved.27. Incident Management [Resolution & Recovery] This part of the process links to the Incident Management [Resolution & Recovery] process.28. Problem Management [Error Handling] This part of the process links to the Problem Management [Error Handling] process.29. Release Management [Planning] This part of the process links to the Release Management [Planning] process.30. Scheduling This part of the process links to the Change Management [Scheduling] process.31. Emergency change scheduled The approved emergency change has been scheduled.32. Dispatch authorised RFCs for change development / build / test. Authorised changes are dispatched to other processes.33. Coordinate communication of change to customers and users. Changes are communicated to customers and users who will be affected.4.0 Change Management v1.04 43 29 March 2007 44. 34. Coordinate and monitor change implementation. The change implementation is coordinated and monitored by Change Management.35. Lodge RFC and complete formal change documentation and procedures Submit the RFC to the change process and document all activities associated with the change.36. Completed emergency change to be registered An emergency change has flowed through the process, and now needs to be documented.37. Recording & Filtering This part of the process links to the Change Management [Recording & Filtering] process. 4.0 Change Management v1.044429 March 2007 45. 7. Change ManagementRecording & Filtering ClassificationImpact & ResourceAssessment Approval Scheduling Coordination Evaluation Evaluation1. Coordination This part of the process links to the Change Management [Coordination] process.2. Change implemented The change has been implemented.3. Review change. The completed change is reviewed.4. Gather feedback from customer. Feedback following the change is obtained from the customer.5. Is CAB input or assistance required in review process? Determine if CAB input is required in the review process.6. Involve CAB in review process. The CAB takes part in the change review process.7. Determine if change achieved its objectives. The change is reviewed to see if it has achieved its objectives.8. Does change review need tabling at CAB for follow-up action or info? Determine if the change review needs to be tabled at a CAB meeting.9. Schedule tabling of change review at next CAB meeting. A change review is scheduled for tabling at a CAB meeting.10. Change review to be tabled. A review of a change is available, and is to be forwarded to the CAB for tabling.11. Impact & Resource Assessment This part of the process links to the Change Management [Impact & Resource Assessment] process.12. Feedback outcomes to CAB, customer, Release Management, and other interested parties. Outcomes from a change review are provided to stakeholders.13. Update Change Management action log and update FSC. All details in relation to a change are updated as a part of the RFC record.14. RFC is formally closed. The RFC has its status changed to closed.15. Change completed. The change is completed. 4.0 Change Management v1.0445 29 March 2007 46. 4.7Self Assessment Level 1 Pre-requisites ClarificationY/NM 1. Are at least some change management The change management activities activities established in the organisation, e.g. include Recording & Filtering; logging of change requests, change Classification; Impact & Resource assessments, change planning, change Assessment; Approval; Scheduling; implementation reviews?Coordination; and Evaluation. Doesyour work area have establishedprocedures encompassing at leastone of these activities? 2. Are change management activities assigned Are the established change to specific individuals or functional areas? management activities mentionedabove assigned to specific people orpersons? 3. Is there a procedure for raising and issuingIs there a procedure in place, and is it requests for change? being followed? Minimum score to achieve this level: 'Y' for all mandatory ('M') questions + 1 other answer 'Y' Level 1.5: Management Intent ClarificationY/NM 4. Has the purpose and benefits of changeHave all of the IT staff in your work management been disseminated within thearea been informed of the purpose organisation?and benefits of Change Management(see Change Management ReferenceGuide 4.1.1 4.1.3)? 5. Has the scope of change managementHas it been clearly defined within your activity been established within the work area as to when a request for organisation?change is required to be submitted? 6. Does the organisation have standards or Does your work area have defined other quality criteria for the raising and standards or quality criteria which registering of changes?they are expected to follow whenraising and registering changes? Minimum score to achieve this level: 'Y' for all mandatory ('M') questions + 1 other answer 'Y' Level 2: Process CapabilityClarificationY/NM 7. Have responsibilities for various changeDo you have specific people who are management activities been assigned? responsible for the changemanagement activities includingRecording & Filtering; Classification;Impact & Resource Assessment;Approval; Scheduling; Coordination;and Evaluation? M 8. Are the procedures for initiating changeAre well defined procedures in place, always adhered to? and are they being followed by yourwork area when initiating change ie.Recording & Filtering? M 9. Is there a procedure for approving, verifying Is there a procedure in place, and is it and scheduling changes?being followed? 10. Are the business and technical impacts ofIs the impact of the change at the changes always assessed? business and technical levels alwaysassessed prior to the change beingimplemented? 4.0 Change Management v1.0446 29 March 2007 47. 11. Is change progress monitored adequately by Change Management may or may notChange Management? be within your work area ie. monitoring may occur from outside of your work area.12. Is the successful implementation of achange confirmed by Change Management?13. Is there a procedure for the review of all Is there a procedure in place, and is itchanges? being followed?14. Are adequate change management reportsproduced?Minimum score to achieve this level: 'Y' for allmandatory ('M') questions + 2 other answer 'Y'Level 2.5: Internal IntegrationClarificationY/NM15. Are all changes initiated through the agreed Does your work area initiate allchange management channels, for example achanges through the equivalent of aChange Advisory Board? CAB? M16. Are changes planned and prioritised,centrally or by common agreement?17. Are change records maintained to reflect the Is there documentation with theprogress of changes? change to show the status and progress of the change (ie. same idea of action log for Incidents)?18. Are the reasons for change failure explicitlyThese reasons must be bothrecorded and evaluated?recorded AND evaluated.19. Are successful changes reviewed againstBusiness needs as determined by thethe original business needs? business, rather than by IT.Minimum score to achieve this level: 'Y' for allmandatory ('M') questions + 1 other answer 'Y'Level 3: ProductsClarificationY/NM20. Are formal change records maintained?Formal change records are those which adhere to university standard requirements. M21. Is a change schedule of approved changes and do staff in your work area knowroutinely issued?where to access it, and when they are required to use it?22. Are standard reports on changes produced Regular as determined by the need ofon a regular basis?your work area.23. Are there established standards fordocumenting changes?Minimum score to achieve this level: 'Y' for allmandatory ('M') questions + 1 other answer 'Y'Level 3.5: Quality Control ClarificationY/NM24. Are there standards and other quality criteriafor the documentation of change made explicitand applied? M25. Are the personnel responsible for change The Change Management activitiesmanagement activities suitably trained?include Recording & Filtering; Classification; Impact & Resource Assessment; Approval; Scheduling; Coordination; and Evaluation. These are covered in ITIL Foundations training. 4.0 Change Management v1.044729 March 2007 48. 26. Does the organisation set and review eithertargets or objectives for Change Management?27. Does the organisation use any tools tosupport the change management process?Minimum score to achieve this level: 'Y' for allmandatory ('M') questions + 1 other answer 'Y'Level 4: Management InformationClarification Y/NM28. Does Change Management providepertinent information concerning requests forchange received (e.g. a breakdown of reasonsfor changes)? M29. Does Change Management providepertinent information concerning the changeschedule?30. Does Change Management providepertinent information concerning number and %of changes?31. Does Change Management providepertinent information concerning number ofsuccessful and failed changes?32. Does Change Management providepertinent information concerning businessimpact of changes?33. Does Change Management providepertinent information concerning changeslippage (including backlogs and bottlenecks)?34. Does Change Management providepertinent information concerning number ofproblem record initiated changes?Minimum score to achieve this level: 'Y' for allmandatory ('M') questions + 2 other answer 'Y'Level 4.5: External IntegrationClarification Y/NM35. Do you hold regular meetings withThis may include businessinterested parties in which Change representatives, management,Management matters are discussed?clients, staff from other work areas at QUT, external vendors etc. M36. Does CM exchange information withConfiguration Management refers toConfiguration Management regarding changestaff involved in the Configurationprogress and change closure? Management process who maintain records associated with the CIs which are involved in the change. This is more than having change staff speaking to the person who maintains a work areas asset database. M37. Does CM exchange information withSee above.Configuration Management regarding changeimpact assessment on configuration items? M38. Does CM exchange information withProblem Management regarding changesrequired to resolve problems / known errors? M39. Does CM exchange information withProblem Management regarding progressreporting and for receiving problem escalationreports? 4.0 Change Management v1.04 4829 March 2007 49. M40. Does CM exchange information withProblem Management regarding obtainingproblem information relating to change?41. Does CM exchange information with theService Desk refers to all relevant ITService Desk for notification of changehelpdesks across QUT eg. staff,progress?student, OLT etc.42. Does CM exchange information with theSee above.Service Desk for notification of changeschedule?43. Does CM exchange information with theSee above.Service Desk for assessing impact of change onService Desk support levels?44. Does CM exchange information with theSee above.Service Desk for obtaining informationconcerning incidents and calls relating tochange?45. Does CM exchange information withThis refers to Release ManagementRelease Management concerning change staff who follow the QUT Releaseimplementation?Management processes in relation to specific releases received from Change Management.46. Does CM exchange information withSee above.Release Management concerning thenotification and scheduling of software andhardware releases?47. Does CM exchange information withThis refers to Service LevelService Level Management regarding the Management staff who follow thechange schedule? QUT Service Level Management processes.48. Does CM exchange information withSee above.Service Level Management regarding potentialchange impact on service level agreements?49. Does CM exchange information with IT This refers to IT Service ContinuityService Continuity Management for notification Management staff who follow theof change schedule?QUT IT Service Continuity Management processes.50. Does CM exchange information with IT See above.Service Continuity Management for assessingimpact of change on contingency plans?51. Does CM exchange information withThis refers to Capacity ManagementCapacity Management regarding performancestaff who follow the QUT Capacityand capacity issues relating to change?Management processes.Minimum score to achieve this level: 'Y' for allmandatory ('M') questions + 2 other answer 'Y' Level 5: Customer InterfaceClarification Y/NM52. Do you check with the customer if theNote the words customer andactivities performed by Change Managementbusiness needs. Business needs areadequately support their business needs? defined by the customer (ie. faculty or divisional representative), not by IT. M53. Do you check with the customer that they Note the word customer andare happy with the services provided?services. M54. Are you actively monitoring trends inThis is regularly receiving feedbackcustomer satisfaction? from customers regarding their satisfaction with respect to changes AND monitoring this feedback over time to uncover trends.4.0 Change Management v1.0449 29 March 2007 50. M55. Are you feeding customer surveyinformation into the service improvementagenda? M56. Are you monitoring the customers value How well are the services providedperception of the services provided to them? meeting the business needs of the customers?Minimum score to achieve this level: 'Y' for allmandatory ('M') questions 4.0 Change Management v1.04 50 29 March 2007 51. 4.8 Appendix A: TIDG Terms of Reference The Technical Infrastructure Development group (TIDG) provides a high level channel to consider and address university IT initiatives and direction. Elements to consider include:1. Technical architecture2. Infrastructure capacity3. Cross-sectional considerations4. Integration across other areas at QUT5. Cost6. Benefits, including ROI7. FeasibilityThe TIDG is closely aligned with the Project Management Framework and IT Service Management Framework. A process overview of the alignment of the PMF and SMF with the TIDG is available here - TIDG Process Overview.One of the mechanisms the TIDG will use to assess the impact on the QUT infrastructure is the RFC (Approval to Build) form (previously Impact Infrastructure Statement) which will need to be submitted and approved by the TIDG for all major and significant IT projects and service changes. Project and service changes can be categorised using the change Category Matrix.The university Technical Infrastructure Development Group will: Formulate IT strategies according to criteria above Provide a gating process for conceived IT technical infrastructure initiatives,including new projects, according to criteria above Advise on and resolve broad technical issues that may emerge as projectsprogress Preview departmental roadmaps Use the ITIL framework as its process basis Advise on exceptions to SOAs and PSAs Provide advice and recommendations on RFCs to the Change AdvisoryBoard.Membership: Advising members: IT Architect (Chair) Manager, Desktop Management & Integration, IT Services (Deputy Chair) Deputy Chair, ITCG Network Services nominee x 2 Central Systems Services nominee Corporate Information Systems nominee High Performance Computing nominee QUT Web nominee TALSS nomineeGuests: RFC Initiator (as requested) Project Manager, IT Service Management (process coach)Consultation occurs with external stakeholders to ensure that outcomes best fit in with IT requirements and University business.4.0 Change Management v1.04 51 29 March 2007 52. Meeting Schedule: Meetings will be held monthly for a duration of 1 hour. 4.0 Change Management v1.04 5229 March 2007 53. 4.9 Appendix B: CAB Terms of Reference The Change Advisory Board (CAB) spans the university and approves changes to the QUT IT infrastructure. All IT-related service and system requests for change (RFC) are to be applied to the Change Management Category Matrix. All significant changes are to be forwarded to the CAB for approval in order for the change to proceed. The approval process for RFCs forwarded to the CAB is in two parts:Approval to Build This addresses initiatives and direction, and includes: Technical architecture Infrastructure capacity Cross-sectional considerations Integration across other areas at QUT Cost Benefits, including ROI FeasibilityRequests for Approval to Build are to be submitted on an RFC-Approval to Build form (previously Infrastructure Impact Statement) and come to the CAB via the Technical Infrastructure Development Group (TIDG). These requests are discussed by the TIDG, with advice and recommendations being forwarded to the CAB.Approval to Implement This takes into account: Timing, especially with respect to other "events"; Contingency planning (such as rollback options); Stakeholder communication; Training, help desk and other support group (orientation); and Other issues to ensure quality of service and facilities during and after each change.Requests for Approval to Implement are to be submitted on an RFC-Approval to Implement form (previously ITS Change Request form).The CAB is the custodian of the Forward Schedule of Changes (FSC), which lists University dates and events, including IT-related service and system changes that the CAB endorses.The CAB is closely aligned with the ITIL Release Management process, and the Project Management Framework. The Change Management Process Overview diagram shows these interrelationships. 4.0 Change Management v1.045329 March 2007 54. Membership: Approving members, and members of CAB/EC: University Change Manager - Manager, Client Quality Services, IT Services(Chair) Manager, Project Portfolio Office, IT Services (Deputy Chair) Chair, ITCG or nominee Chair, TIDGAdvising members: Associate Director, Integrated Help Services Manager, Network Services, IT Services Manager, Corporate Information Systems, IT Services Manager, Central Systems Services, IT Services Manager, Desktop Management and Integration Student advocate Staff advocateGuests: RFC Initiator (as requested) Project Manager, IT Service Management (process coach)Consultation will occur with external stakeholders to ensure that outcomes best fit in with University IT requirements and University business.Meeting Schedule: Meetings will be held weekly for a duration of 1-1.5 hours. 4.0 Change Management v1.04 5429 March 2007 55. 4.10 Appendix C: Approval to Build Checklist CompatibilityYes No N/AThe change is compatible with the current IT infrastructure. The change is compatible with the stated direction on QUT IT Architecture roadmaps. The change is compatible with the stated direction on QUT Business Architecture roadmaps (when available). The change is compatible with the stated direction on QUT Data Architecture roadmaps (when available). Interdependent changes/projects have been identified. ImpactsYes No N/ABusiness impact determined if RFC postponed/rejected Security impact determined if RFC postponed/rejected Service/infrastructure impact determined if RFC postponed/rejected Ongoing support impact determined if RFC implemented Planning Yes No N/AProposed implementation date entered on FSC (Events Calendar) Client groups affected by change have been identified. Stakeholders have been identified All required resources are planned and available Approval Yes No N/AService Manager/s of service/s affected by change accept the RFC 4.0 Change Management v1.04 55 29 March 2007 56. 4.11 Appendix D: Approval to Implement Checklist ResourcesYes No N/AResources and materials are in place for RFC implementation Post change support is available Planning Yes No N/AImplementation plan is complete and signed off Test plan is signed off Backout plan is signed off Communications and training plan for clients is signed off Communications and training plan for IT staff is signed off Relationship with current Incidents and Problems has been communicated to owners Service documentation has been updated as required Service Desks have required information in preparation for change Approval Yes No N/ARisks have been communicated and accepted All prerequisites have been authorised Service Manager/s of service/s affected by change accept the RFC Stakeholders have accepted RFC CAB has approved RFC Implementation date has been agreed 4.0 Change Management v1.045629 March 2007 57. 4.12 Appendix E: CAB Meeting Agenda Template AGENDA Change Advisory Board Meeting Number # Meeting Date and TimeMeeting Venue CHAIR:Change Manager SECRETARY:Executive Officer1. Welcome 1.1 ApologiesList meeting members unable to attend and any representatives in their place. 1.2 Additional Attendees/GuestsList any additional attendees/guests, welcome and introduce.2. Confirmation of Previous Meetings Minutes and Review Action ItemsConfirmation of accuracy of previous meeting minutes and any furtheredits/amendments, then review of outstanding action items.3. Approval to BuildThis relates to agenda items which would formally have been submitted to theTechnical Infrastructure Development Group (TIDG). Provide specific detailsincluding RFC #, Brief description of Change, and the name of the RFCInitiator.4. Approval to ImplementThis relates to agenda items which would formally have been submitted to theService Change Management Group (SCMG). ). Provide specific detailsincluding RFC #, Brief description of Change, and the name of the RFCInitiator.5. Review of Activities 5.1 Activities since last meeting 5.1.1 Minor changes This relates to minor RFCs which have been carried out since the last meeting. Provide specific details including RFC #, Brief description of Change, and the name of the RFC Initiator. 5.1.2 Moderate/Major changes This relates to moderate/major RFCs which have been carried out since the last meeting. Provide specific details including RFC #, Brief description of Change, and the name of the RFC Initiator. 5.1.3 Emergency Changes This relates to agenda items which Provide specific details including RFC #, Brief description of Change, and the name of the RFC Initiator.5.2 Status ReportsThis relates changes where status reports have been submitted relating to theprogress of a change. Provide specific details including RFC #, Brief descriptionof Change, and the name of the RFC Initiator.5.3 PIR 4.0 Change Management v1.04 57 29 March 2007 58. This relates changes where PIRs have been completed relating to the implementation of a change. Provide specific details including RFC #, Brief description of Change, and the name of the RFC Initiator.6. Non-complianceThis relates to changes which were carried out on the infrastructure which didnot have approval, or which did not follow process.7. Process ReviewProcess review provides an opportunity to see how well the process is workingand provide recommendations for improvement. 7.1 KPIs and Metrics7.2 Process Improvement8. Other Business9. CloseNext meeting 4.0 Change Management v1.04 58 29 March 2007