This action might not be possible to undo. Are you sure you want to continue?
Welcome to Best Practices for Change Management. This book is comprised of templates, documents and examples of Change Management sourced through Content on Demand Online: http://content.theartofservice.com/. Content on Demand Online is an on-demand digital library you can use to search, download, learn, edit and directly use applicable documents for technology and business professionals. In this edition, you will find documents showing how to create Change Management documents, useful examples and case studies to show you how other businesses have done it, and adaptable template documents for you to apply to your own business.
Free Access to the Content on Demand Online database!
In addition to the documents included in this book, you are now welcome to enjoy complimentary access to the Content on Demand Online database. Once logged in, you will be able to download electronic copies of these documents or if you prefer, the equivalent number of other documents of your choosing. To gain access, please send your proof of purchase to CODOchangemanagement@theartofservice.com
Notice of Rights
All rights reserved. No part of this book may be reproduced or transmitted in any form by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. No Claim to Orig. (U.S.) Govt. Works.
Notice of Liability
The information in this book is distributed on an As Is basis without warranty. While every precaution has been taken in the preparation of the book, neither the author nor the publisher shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the instructions contained in this book or by the products described in it.
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations appear as requested by the owner of the trademark. All other product names and services identified throughout this book are used in editorial fashion only and for the benefit of such companies with no intention of infringement of the trademark. No such use, or the use of any trade name, is intended to convey endorsement or other affiliation with this book.
INTRODUCTION........................................................................................................... 1 CONTENTS .................................................................................................................. 3 CHANGE MANAGEMENT DOCUMENTS ....................................................................... 4 ORGANIZATIONAL CHANGE MANAGEMENT PLAN TEMPLATE ..................................................... 5 CHANGE MANAGEMENT TEMPLATE - DEPARTMENT OF TRANSPORT.......................................... 14 CHANGE MANAGEMENT PLAN TEMPLATE ............................................................................ 41 CHANGE MANAGEMENT PROCEDURE.................................................................................. 55 CHANGE MANAGEMENT POLICY – STATE OF ILLINOIS ............................................................. 74 CHANGE MANAGEMENT PROGRAM PRESENTATION – DEPARTMENT OF POLICE AND EMERGENCY MANAGEMENT ............................................................................................................... 81 CHANGE REQUEST PROCEDURES ........................................................................................ 94 MANAGING CHANGE IN THE WORKPLACE ............................................................................ 99 THINKING THROUGH CHANGE .......................................................................................... 104 CHANGE ADVISORY BOARD (CAB) MEETING MINUTES ........................................................ 108 REQUEST FOR CHANGE CATEGORY DEFINITIONS .................................................................. 116 CHANGE MANAGEMENT COMMUNICATION PLAN ............................................................... 123 CHANGE SCHEDULE TEMPLATE ........................................................................................ 129 REQUEST FOR CHANGE (RFC) TEMPLATE........................................................................... 138 ADMINISTRATIVE STRATEGIC PLANNING AND CHANGE MANAGEMENT – POWERPOINT PRESENTATION ................................................................................................................................. 158 CHANGE MANAGEMENT PROCEDURE – RAIL TOURIST SERVICES............................................. 170 CHANGE MANAGEMENT GUIDELINES – DEPARTMENT OF COMMERCE ..................................... 178 FURTHER INFORMATION .........................................................................................193
Change Management Documents 4 .
This document is a great starting point when you are looking at implementing Change Management in your organization. It is a ready-made template with prompts for you to add information relevant to your situation. to create a Change Management Plan 5 . It ensures preparedness and risk management for the inevitable changes which all companies go through.Organizational Change Management Plan Template Change Management is an invaluable process for businesses.
Overview Stakeholder Management 6 . Introduction 2. Organizational Change Management Scope .PROJECT NAME Project Name: Prepared by: Date (MM/DD/YYYY): 1.
Stakeholder Name Awareness (H/M/L) Degree of Support Influence (H/M/L) Plan Communication Training Stakeholder Objectives Optimum Communication Stakeholder Group Channel Known Concerns: <suspected basis for resistance (if any)> 7 .
Name of Executive Position Proposed Supporting Actions Name Division / Dept Contact Information 3. Communication Objectives 8 .
Perform and Analyze the Results of a Job/Workflow Impact Analysis Position Task <-> Workflow Name Position Task Skill Required Skill Exists? Type of Training Required 9 . Training Objectives 5.4.
Provide the Organization with Information Necessary to Prepare for Upcoming Changes Policy / Procedure Type of Change Required Suggested Plan 7. Training Documentation Requirements Training Documents Author(s) Reviewer(s) 10 .6. Develop Curriculum and Content Stakeholder Group Type of Training Required Optimum Setting Delivery Method Suggested Job Aids 8.
9. Post Implementation Steps – Super Users Group Department/Division Support Staff Name Support Period 11 . Training Facility Requirements Training Facility Stakeholder Group(s) Type of Training Date 10.
Organizational Change Management: Approach and Resources Contact Liaison Name Department Information Team Member Name Department Contact Information Speaker Target Organization Type of Presentation Date(s) 12 .11.
they agree to this as the formal Organizational Change Management Plan document. 13 . Organizational Change Management Plan Document / Signatures Project Manager: I have reviewed the information contained in this Organizational Change Management Plan Document and agree: Name Title Signature Date (MM/DD/ YYYY) The signatures above indicate an understanding of the purpose and content of this document by those signing it.12. By signing this document.
Department of Transport This Organizational Change Management Plan provides a comprehensive and detailed template and is a fantastic resource for businesses looking for a starting point to implement Change Management. 14 . It provides explanations of the different factors involved in change management planning.Change Management Template . and areas for you to edit and adapt by adding information relevant to your organization.
Program Name Prepared by: Date: 15 .Department of Transportation Project Name Organizational Change Management Plan Project ID: Division.
Template Revision Approvals Name Role Date Insert Project Approvals here. 16 .0 Date of Release 8/2009 Owner ETID PMO Summary of Changes Initial Release of Caltrans Organizational Change Management Plan template Remove template revision history and insert Organizational Change Management Plan revision history.Template Revision History Revision History Revision # 1.
1 1.9 17 .1 5.9 DEFINED.4 2.6 1. 3.3 2.5.6 3.5.7 2. 5.5 INTRODUCTION PURPOSE 19 20 19 ORGANIZATIONAL CHANGE MANAGEMENT PLANNING19 PRINCIPLES OF ORGANIZATIONAL CHANGE MANAGEMENT 20 21 22 22 TRANSLATING ORGANIZATIONAL CHANGE MANAGEMENT PRINCIPLES INTO A REFERENCES 21 STRUCTURED APPROACH 1.2 2.1 4.3 ORGANIZATIONAL CHANGE MANAGER LEAD ORGANIZATIONAL CHANGE EVALUATOR CHANGE MANAGEMENT STAKEHOLDER PROJECT TRAINING COORDINATOR – DEPARTMENTAL ROLES 25 25 25 ORGANIZATIONAL CHANGE MANAGEMENT TEAM MEMBERS ORGANIZATIONAL CHANGE MANAGEMENT SCOPE 26 COMMUNICATION/STAKEHOLDER OBJECTIVES ANALYSIS OF JOB/WORKFLOW IMPACT MARKETING ORGANIZATIONAL CHANGE 28 30 32 32 ENGAGING STAKEHOLDERS IN THE PROGRESS OF THE PROJECT METHODOLOGY AND TOOLS FOR COMMUNICATIONS ERROR! BOOKMARK NOT BUILDING ACCEPTANCE TO CHANGE ERROR! BOOKMARK NOT DEFINED.5 2. 1.2 5.3 1. External References Project Centralized Repository Document 22 GLOSSARY AND ACRONYMS DOCUMENT MAINTENANCE ORGANIZATIONAL CHANGE MANAGEMENT PARTICIPANTS ROLES AND 23 23 23 24 RESPONSIBILITIES 2. 5.1 1.4 1.1 2.2 1.Table of Contents 1.2 1.
TRAINING AND KNOWLEDGE TRANSFER 35 AN EFFECTIVE TRAINING PLAN SHOULD INCLUDE: ERROR! BOOKMARK NOT DEFINED.1 KNOWLEDGE TRANSFER PLAN ERROR! BOOKMARK NOT DEFINED.11 18 .10 6.5.11 6.4 MONITORING THE EFFECTIVENESS OF THE CHANGE MANAGEMENT PROGRAM ERROR! BOOKMARK NOT DEFINED.
business process. provide good communications. Employees are better prepared for and involved in achieving and sustaining those changes. Understanding and effectively implementing change allows transformation of strategy. The greatest threat to successful organizational change management is the failure to address stakeholder concerns.” A well thought out and responsive Organizational Change Management Plan significantly mitigates business disruption and facilitates the time it takes to adopt change. A structured approach to organizational change management is critical for any project which brings about significant change. technical and cultural changes that occur as the result of project initiatives. 19 . technology.Introduction Purpose The purpose of the Organizational Change Management Plan is to actively design. and execute a strategy for preparing all employees for business. Embracing and magnifying the positive aspects of change help employees align themselves with long term success in an organization‟s newly defined “desired future state. Organizational Change Management Planning Organizational change management planning encompasses all the activities an organization needs to successfully accept and adopt new business models. develop. the results can lead to lack of acceptance of business process changes and poor end user performance. strategies and the new technologies for supporting them. and people into achieving performance and enhancing continual improvement in a dynamically changing environment. and assure adequate training and staff acquisition planning in preparation of organizational change. Without this attention to detail.
Effective project planning – planning is structured and methodical and all plans are agreed to with regard to organizational change management objectives. with mutual respect. These elements are: 20 . Resources and support – organizational change management implementers and recipients receive the resources and support throughout the change process. Measurable objectives – organizational change management objectives are realistic and measurable and progress toward their achievement is shared with all major stakeholders.Principles of Organizational Change Management A principled approach to communicating and implementing change fosters openness and trust which ultimately improves the project‟s chances of success. Translating Organizational Change Management Principles into a Structured Approach There are a number of elements when understood and adopted that can help communicate and gain acceptance of the need for complete and timely organizational change. regarding organizational changes and their impacts. and resources. Key underlying organizational change management principles are: Committed project sponsorship – organizational change management objectives have the support and resources of key decision makers within the organization. roles. Engaged stakeholders – project stakeholders are encouraged to openly participate in dialogue.
in specific and defined terms. Identify and mitigate potential risks that accompany organizational change management. resource owners and stakeholders who will be impacted by change(s. References External References PMBOK Guide. Identify changes that will impact the organization and who will be impacted as a result of a project‟s implementation. recognizing and rewarding success. Make the change(s) permanent by institutionalizing them. Facilitate action by removing obstacles and listening for constructive feedback.) Ensure that changes and their impacts are properly understood by all and that there is a comprehensive marketing plan to address stakeholder concerns. Build the structure and staff with the right skills to affect the change. Garner support by bringing together Caltrans project and program decision makers. Name individuals to specific activities and tasks. Section 2. Put organizational change management goals in specific and defined terms for achieving desired outcomes. making them responsible for organizational change management goals and desired outcomes.3 – Organizational Influences OCIO CA-PMM. The change will eventually become part of the culture. Section 3. 3rd Edition. Explain why they are important and when they need to happen.2 Organizational Change Management Plan 21 .
These files are located on the network in the directory N:\PMO_New. control agency approval documents. If the project is not using a specific tool. the document should be revised into the latest PMO template format at the next quarterly review. When changes occur. and change description will be recorded in the revision history log of the document. If the document is written in an older format. the owner making the change.Project Centralized Repository Document If applicable. FAQs OCIO PMBOK PMO Frequently Asked Questions Office of the Chief Information Officer Project Management Body of Knowledge Project Management Office Document Maintenance This document will be reviewed quarterly and updated as needed. 22 . the document‟s revision history log will reflect an updated version number as well as the date. This document contains a revision history log. list any relevant documents that can be used as references for this document and its corresponding location. and project status reports must be saved into the IT Project Management Office (PMO) centralized document repository. as the project proceeds through each phase of the system development life cycle. indicate the name of the document management tool the project is using. A copy of all project management plans. Glossary and Acronyms List only glossary and acronyms that are applicable to this document.
Lead Organizational Change Evaluator – The <Project Name> Project Manager will serve as the Lead Organizational Change Evaluator for the project. Serving as the single point of contact for organizational change management activities. Recording changes according to provisions of the Organizational Change Management Plan. Responsibilities include: Developing/executing the Organizational Change Management Plan. Responsibilities include: 23 . Note that these are roles. There are various staff resources and stakeholders involved in managing project risks. one individual may perform multiple roles in the process. Monitoring the effectiveness of organizational change management activities and recommending actions to resolve issues. One person may fulfill more than one role. Coaching/mentoring Caltrans organizational change management staff in providing timely communication with project stakeholders.Organizational Change Management Participants Roles and Responsibilities This section describes the roles and responsibilities of the <Project Name> staff with regard to the Organizational Change Management Plan. Organizational Change Manager . In some cases. not positions or titles.The <Project Name> Technical Lead will serve as the Organizational Change Manager/Coordinator for the project. Ensuring that changes are incorporated into appropriate project documents. Recording decisions on proposed changes.
and town hall meetings. Coaching and mentoring Caltrans staff in providing effective organizational change management. their impacts and resolution. Delivering organizational change management communications and leading activities involving Caltrans executives and stakeholders. systems demos. Monitoring the effectiveness of organizational change management activities and making recommendations to resolve issues. Approving key communications. Tracking and facilitating timely decisions on changes. Acting as champions of change for their respective functional areas. workshops. Documenting proposed changes. Outlining options and making recommended courses of action and priorities for changes. Ensuring appropriate levels of review and approval. 24 . Facilitating Caltrans organizational change management activities. Circumscribing and implementing change management activities Participating in evaluating proposed changes. Organizational Change Management Team Members – Individuals may come from sources internal or external to the project. Responsibilities of Organizational Change Management Team Members include: Identifying changes and their impacts. Timely and adequate evaluation of organizational changes in terms of their impact on programs/projects. Developing and scheduling outreach programs. performing analysis functions such as planning for and assessing the impacts of change.
Developing/implementing the Organizational Change Management Training Plan. Approving or rejecting organizational change actions. Proposing alternative courses of action for organizational change impacts. Developing written communications materials – newsletters. Developing/implementing the project‟s Knowledge Transfer Plan. Change Decision Maker(s) may be the Project Manager. and determining appropriate training solutions. Overseeing and assisting in documenting the results of training and knowledge transfer. posters. Change Management Stakeholder – Depending on significance of change. the Project Sponsor and/or the Steering Committee. e-mails. Overseeing the development of “Lesson Plans” for all identified training and knowledge transfer needs. Establishing mechanisms for gathering information on training and knowledge transfer activities feedback. Web content. Program Managers) 25 .6 Departmental Roles (Information Technology Governance Board. the Program Manager. Project Training Coordinator – Responsibilities include: Participating in Job/Workflow impact analysis. assessing change impacts. 2. Responsibilities include: Evaluating options and recommended courses of action for changes. and leaflets. Participating in evaluating whether learning is taking place.
Assist in documenting proposed organizational change. Goals and objectives from the project‟s Feasibility Study Report (FSR) provide how change influences the organization at a high level and is a good place to start. and their impacts become clearer and more specifically detailed as the project moves from the design phase to the development phase. Advise Project Manager of proposed organizational change. (Project Technical Lead) will identify and document the impacts of change to the organization due to the project‟s implementation as well as work with affected functional organization managers/stakeholders to create and implement an action plan for mitigating those impacts. functional. The <Project Name> Organizational Change Manager. interfaces and systems. Complete the table below: Stakeholder – the individual or entity impacted 26 . It is only then that the full impact to the organization is known. Participate in evaluation of proposed organizational change. applications. The known drivers of change. The whole of organizational change is accreted until the project‟s design is accepted and all design decisions made. the project‟s business. Organizational Change Management Scope One of the best ways to deal with organizational change is to identify and document its root causes and resulting impacts. Change from implementing a project can entail something as small as a field modification on an input screen or involve wide spread changes to data elements. This is where the cause and impact of change is broken down. technical requirements.
Medium.Awareness – the level of awareness the stakeholder has regarding the upcoming changes (High. Low) Known Concerns – the concerns the stakeholder has regarding the upcoming changes How change is Communicated – the way the stakeholder is contacted regarding upcoming changes Proposed Actions – the actions that will prepare the stakeholder for upcoming changes 27 . Medium. Medium. Low) Degree of Support – the degree to which the stakeholder is responding to requests for participation in the project (High. Low) Influence – the level of influence the stakeholder has in the organization (High.
Constant and consistent communications with all organizational stakeholders helps to ensure that no significant change is overlooked or not responded to. As organizational stakeholders look to see that their concerns and objectives are being met. Maintaining a detailed stakeholder 28 . the more likely it is that those changes will be accepted even by those who would otherwise resist them.Organizational Change Management Action Plan Stakeholder Name Awareness (H/M/L) Degree of Support (H/M/L) Influence (H/M/L) Known Concerns How Change is Communicated Proposed Actions <Project Name> Communication/Stakeholder Objectives Change must be understood and managed in such a way that stakeholders can effectively cope with it. The greater the number of stakeholders who are “on board” with anticipated changes as communication allies equipped to socialize the benefits of change. Proactively understanding how certain stakeholders will be impacted by change and involving them in proposed outcomes helps reduce resistance to it. the Organizational Change Manager needs to provide a more detailed stakeholder communications log.
actions and manage stakeholder expectations. Name the group‟s representative. the individual or entity impacted. Include the representative‟s Division/Department. Indicate how communications are conducted. phone. Indicate the representative‟s position and contact information. Show the date communications took place. List corresponding actions taken to address stakeholder concerns and objectives. List all known concerns and stakeholder objectives for each stakeholder/group. in person. e-mail. List relative follow-up actions or notes. Over the course of the project dates and action items can be referred to for clarification and resolution. 29 . The log can be as simple as an Excel Spreadsheet or can be a variety of issue tracking and management software for more complex projects. At a minimum the log should: Identify the stakeholder group.communications log enables the project manager and organizational change manager to document stakeholder contact.
The <Project Name> Organizational Change Manager must work with the project team and 30 . in which case positions and job descriptions have to be reclassified and/or revised. A more common example would be the impacts technology imposes such as when old systems are replaced with newer ones that leverage automation. Project team members and stakeholders will be notified of changes as appropriate. Analysis of Job/Workflow impact Often organizational change impacts workflows and job compositions at the position level. Job classifications that contained manual work processes are no longer applicable or even become obsolete.Stakeholder Communications Log <Project Name> Stakeholder/ Group Name Representative/Divisi on/Office Positi on and Cont act Info Date/H ow Contac ted Known Conce rns Actio ns Take n Follo w Up Actio ns Note s Overall project communication objectives are outlined in the <Project Name> Communication Plan.
the individual or entity impacted. Indicate if the person possesses the skill necessary to complete the task or if the task requires new skills that the organization does not currently possess. List the type of training required if re-training or knowledge transfer is an option. The job/workflow impact analysis is a useful tool in identifying which jobs in the organization will be impacted and what planning will become necessary to revise processes. position and contact information. and re-train staff. jobs. Indicate the person‟s name. Show the skill(s) required for successfully completing the task. Job/workflow impact analysis should: Identify the stakeholder group. Job/Workflow Impact Analysis Worksheet <Project Name> Stakeholder/Group Name Name of Employee Impacted Position and Contact Info New or Revised Position/Workflow Task Skill(s) Required Skill(s) Exists Follow Up Actions Notes 31 .stakeholders to determine at the lowest level of detail impacts to jobs. Identify the new or revised position or workflow task.
Indicate how the project will actively disseminate factual information about project goals.Marketing Organizational Change A great deal or time. themes for correspondence. Explain the benefits of implementing <Project Name>. Building a project image as being a catalyst for positive improvements. Project marketing activities are specifically designed to reach out to stakeholders. logos. project name. Sometimes it is automatically assumed that the changes will be accepted by those impacted or that information regarding change would be given on a “need-to-know” basis. 32 . Marketing these changes correctly is integral to the project‟s organizational change management plan. Show how enthusiasm for promoting “buy in” of <Project Name> will be generated and achieved. Receptiveness to organizational change is required to keep pace with evolving technologies. Creating a unique project identity. status and organizational-wide impacts of <Project Name>. Engaging Stakeholders in the Progress of the Project Steps Include: Developing a communication strategy tailored to targeted user and stakeholder groups. and shifting global economic uncertainties. users and groups who are impacted by change to: Provide insight into how application components and new business processes will come together to define the organization‟s future state. effort and money are invested when major changes to an organization are attempted. essentially project/product branding.
newsletters. emails. individual discussions. Building Acceptance for Change Techniques and tools for building acceptance to change include: Enlisting the support of project champions and stakeholders that are most accepting of the changes to come. Offering employees concrete incentives to help ensure their cooperation. Establishing a point of contact for communications and elevating issues and concerns. Providing formal presentations and informal sessions to share information and manage stakeholder expectations. Using the power of the organization through memos. bulletin boards. System Walkthroughs that focus on new business processes. resulting changes and impacts to lessen user and stakeholder anxiety about changes to come. 33 . applications and features that reduce or streamline work tasks. memos and other low cost ways of communicating change information. Talking up the changes and their benefits. presentations to “advertise” the importance and benefits of upcoming change. displays. explaining project objectives. Methodology and Tools for Communications Methods and tools for communications include: Developing a project website and providing a list of Frequently Asked Questions (FAQs) Using focus groups to move through the organization. enlisting sympathetic stakeholder support. Creating and maintaining a project newsletter.
Giving resistance leaders prominent positions or roles in the organizational change management program. Indicate how the project will actively disseminate factual information about project goals. status and organizational-wide impacts of <Project Name>. Explain how the <Project Name> will plan for and build acceptance to change. including: Change management readiness surveys used to determine if the purpose of the <Project Name> project is understood and if stakeholders believe the project is necessary to achieve improvements as well as whether or not it will be successful. Offering employees. Work them twice as hard for a reward of a 15% pay cut. Monitoring the Effectiveness of the Change Management Program Periodically. 34 . the organizational change manager and the lead organizational change evaluator monitor the effectiveness of the organizational change management program. There are a number of elements that can be employed to assess change readiness. users and stakeholders training and adequate knowledge transfer/skills development. Using coercion and punishment of people who resist change. Show how enthusiasm for promoting “buy in” of <Project Name> will be generated and achieved. Assessments are conducted to confirm progress toward achieving readiness to implement the project and to identify specific areas where a more concerted effort is required to successfully make change occur.
” and “to-be. The sessions should also provide insight into what challenges the change management leadership and team can expect to 35 . status and organizational-wide impacts of <Project Name>. Completion of training sessions and employee skill assessment evaluations Resolution of key differences between “as-is. Indicate how training/training evaluations will be used to confirm progress toward achieving the effectiveness of the organizational change. Identify what metrics the <Project Name> will use to monitor the effectiveness of its organizational change management program. First. and managed. commitment to change and skill development. the project must plan for hands-on sessions to educate those who will lead and assist in integrating organizational change. These sessions should cover how change will be initiated. Indicate how the project will actively disseminate factual information about project goals. Evaluations used to measure stakeholder knowledge and understanding of project changes and benefits. communicated. Show how assessments will be used to determine when the project is ready to implement.” business processes. It is important to note that for any change initiative the objective of training has a two-fold focus. Training and training evaluations User and stakeholder attitudes. Training and Knowledge Transfer An indispensable tool for Caltrans key managers and change leadership is training. implemented.
developed or adopted by individuals in one part of the 36 . and who will be trained. policies. Note. the subject of training is presented in more detail in the Project Training Plan Template. (Link to the Project Training Plan) Knowledge Transfer Plan Knowledge is an important organizational asset. Assessment of the training‟s effectiveness Post training support and follow-up. Knowledge and knowledge transfer is influenced by an organization‟s common culture. An effective training plan should include: A detailed training needs assessment identifying all required changes. venue. infrastructure. the training needed to meet those requirements. It is the acquisition of specialized skills. use of tools. A training curriculum and content that is developed based upon the needs assessment. Training facility requirements. processes. goals and objectives. The project change leadership and team will work with Caltrans management and staff on an individual basis to create and execute training plans that address and resolve organizational change management impacts. collaborative efforts. developed over time. communications. Knowledge transfer is the process for communicating specialized knowledge created. The second training focus is centered on Caltrans functional organizations that will be impacted as a result of project objectives. and scheduling.encounter as the project moves through its full lifecycle. Training documentation requirements and the development of training materials. and shared belief systems. unique abilities and experiences by staff. standards.
motivational problems. union/management relations. culture. A knowledge transfer plan can help organizational change management leadership and staff effectively transition knowledge elements crucial to business continuity and success. Successfully accomplishing knowledge transfer can be complicated by such things as the inability to identify and articulate intuitive competencies.organization to another part. <Project Name> Project Number 2660-XXX 37 . Complete the Knowledge Transfer Plan for <Project Name>. areas of expertise or lack of expertise just to name a few. language barriers. incentives.
Knowledge Transfer Plan Name (Employee’s Name) Role Description Role (Role Title) Key Competencies and Required Skills for the Role (Enter Role Description) Existing Skill Yes New Required Knowledge. Skill or Competency No Target Date: (Enter Planned Date for Acquiring Knowledge. Skill or Competency) Achieved Date: (Enter Actual Date Knowledge. Skill or Competency was Acquired) Status In process Complete Caltrans Manager Verification Yes No 38 .
Knowledge Transfer Method Training: Required Training Courses (Enter Required Training) Mentorship: Mentor Assigned (Individual’s Name) (Describe how mentoring was done to ensure competency) Self Study/Documents Review (Enter Documents Reviewed) On-the-Job Sessions (Enter Content of Each Session and Dates Each Session was Completed) Draft (Enter Date) Final Is This a Formal Contract Deliverable? Comments Yes No (Enter Any Comments) 39 .
Signatures Below Indicate Approval of the Attached Document Name (Enter Approver‟s Name Project Role (Designated Role) Organization (Sponsoring Organization) Signature: ___________________________ Date: _____________ Name <Project Name> Functional Project Manager Functional Project Manager’s Organization (Organization Name) Signature: ___________________________ Date: _____________ Name <Project Name> Technical Project Manager Caltrans IT. Project Management Office (Organization Name) Signature: ___________________________ Date: _____________ 40 .
it is a valuable step to scout examples and use a template as a basis for your next plan. This document provides a pre-prepared template for you to adapt to your businesses needs. as well as example of a Change Request Form and a Change Tracking Log. or considering improving your processes. It includes direction on what information to include. 41 .Change Management Plan Template When instigating Change Management within your organization.
Business Transition Manager or Appointed Reviewer (name & position)> <Agency/Organization/Division Name> <PROJECT NAME> VERSION: <VERSION NUMBER> REVISION DATE: <DATE> Executive Sponsor and/or Business Owner <Name> Signature: <Email> <Telephone> Date: Project Manager and/or Business Transition Manager <Name> Signature: Other (CIO/DCIO) <Name> Signature: <Email> <Telephone> Date: <Email> <Telephone> Date: 42 .Change Management Plan This document prepared and owned by <Business Owner.
Schedule. determine how the change will occur. 43 . Configuration Change Management Plan Establish Change Management Responsibilities Executing and Controlling Purpose of the Document The purpose of the Change Management Plan is to define and agree on how changes are to be coordinated within the project and organization. Scope. The plan addresses how the <Project Name> project will ensure that the changes are beneficial.Planning Identify the Type of Changes That Will be Coordinated and Controlled Determine the Overall Change Management Process & Identify Change Control Board Determine Specific Processes & Tools For Changes to Cost. and manage the changes as they occur.
Table of Contents PURPOSE OF THE DOCUMENT TABLE OF CONTENTS 44 45 43 CHANGE MANAGEMENT PLAN PURPOSE CHANGE MANAGEMENT GOALS 45 CHANGE MANAGEMENT RESPONSIBILITIES 45 OVERALL CHANGE MANAGEMENT MODEL 47 SCOPE CHANGE/REQUIREMENTS MANAGEMENT SCHEDULE CHANGE MANAGEMENT COST CHANGE MANAGEMENT 49 49 50 49 48 TECHNICAL CONFIGURATION MANAGEMENT BUSINESS TRANSITION CHANGE MANAGEMENT CHANGE MANAGEMENT FORMS AND LOGS50 CHANGE MANAGEMENT TRACKING LOG DOCUMENT INFORMATION PAGE 54 AMENDMENT HISTORY 54 52 44 .
It is assumed that a request for change may occur in many forms – oral or written. Change Management Goals The goals of <PROJECT NAME> Change Management Plan: 1. The Business Transition change management plans are managed by the Business Transition manager/coordinator and are to be incorporated into the overall project change management plan. 45 . 3. externally or internally initiated.Change Management Plan Purpose The purpose of the <PROJECT NAME> Change Management Plan is to coordinate changes across the entire project. 2. Project plans are changed to reflect the requested changes. Change Management Responsibilities The change management responsibilities are: 1. Changes are identified. and legally mandated or optional. The <PROJECT NAME> project is responsible to develop the Change Management Plan. Changes are negotiated and communicated to all affected parties. Reasonable change activities are planned. 2. defined. approved and tracked through completion. The plan will address how the <Project Name> project will ensure that the changes are beneficial. 4. Adequate resources and funding are obtained to ensure the change management plan can and will be executed. 3. evaluated. direct or indirect. and manage the changes as they occur. determine how the change will occur.
6. The <PROJECT NAME> is responsible for ensuring that changes are delivered as planned. The change management activities will be reviewed with senior management on a periodic basis. 46 .4. Records of changes are tracked and maintained. 5.
This template has included sections that reference more rigorous subsidiary change management processes. but the specific change process in the areas of scope.assess impact or risk of change to the project.analyze changes to the project plan. scope. Assess for risk . rejection. or rework and negotiate agreements on schedule and effort commitments of all affected parties. system. Higher risk projects require more rigorous change management that addresses not only the overall coordinating change management process. schedule and technical configurations are developed and managed throughout the life of the project. Templates are provided for managing overall change control on a project. schedule. Evaluate a change . cost.propose or recommend the change solution. These subsidiary processes describe how scope/requirements. Obtain change decision . The <enter project manager or project office coordinator or other appropriate title> will be assigned and have full responsibility for facilitating or executing the change management process to officially provide new requirements. obtain approval. Lower complexity project may use just the overall change management plan and have no need for the more rigorous processes. and technical configuration. work products or activities. and changes to project time and effort estimates. or business. cost. schedule and resources as follows: Identify a change -document and log a change request. 47 .the following is an overall change management process to manage and coordinate changes across the various aspects of the project.Overall Change Management Model Note to template user.
prioritize. the code meets the design specification. and prepare a matrix for tracing requirements. and documentation needs. assigns responsibilities and identifies the techniques to be used. Transform needs into high-level requirements. Verify through each phase of the project that the end product or deliverable meets the requirements specifications. Track to completion – track the change from identification through update project plan and schedule. Identify stakeholders and gather. and validate that the detailed requirements align with the high-level requirements. 3. and obtain approval of the updated project plan and schedule. 2. validate findings with stakeholders. 4. It details the process. Assign and categorize the high-level requirements to products. and document stakeholder needs and constraints. i. refine the high-level requirements to obtain greater precision and detail. validate. associated tools.update or re-baseline the project plan(s). 48 . Scope Change/Requirements Management The Requirement Management Plan will be used to define and manage the product scope of the project in support of and consistent with the project objectives throughout the life of the project. evaluate and correct deficiencies. In summary the plan for Requirements Management is to: 1. Integrate changes into project plan . and schedule.e. Communicate the final changes to commitments or assignments to all affected parties. estimates.
The Requirements Management Plan is a subsidiary plan of the change management plan and is located in the project planning/change management section of the project file or notebook.5. Technical Configuration Management Describe how the technical configurations of the project will be developed. modifications and additions to stay in line with the original objectives or to formally modify these objectives. What roles and responsibilities they will 49 . but the project team needs to know how the tool will be utilized and managed. If the project‟s Cost Management Procedures are detailed a general description should be provided here with a reference to the cost management plan and processes. On more rigorous projects a configuration management tool will be referenced. Schedule Change Management Describe how and when schedule changes and schedule baselines will be changed and under what conditions or agreements. Cost Change Management Describe how the budget will be developed how cost change and cost baselines will be changed and under what conditions or agreements. and managed. Use the project‟s change management process to manage deletions. organized. and the supporting schedule and resourcing.
Some projects modify the actual templates to represent a more or less rigorous process. and managed. 50 . Both the change request form and change log are available separately on the PMO Website “Templates” page under “Controlling Templates”. Change Management Forms and Logs The following is a change request form and change management tracking log template. The project business transition team needs to know what roles and responsibilities they will have and what will be standardized. A reference should be made here to the detailed use of the tool should be described in the tools reference manuals. They are included in the plan to give its‟ readers a view of the forms associated with the process. organized.have and what will be standardized. The following pages contain pictures of suggested templates. Others may prefer to collect and monitor the change information via spreadsheets or other automated tools. Business Transition Change Management Describe how the business transition activities of the project will be developed.
Completion Recommendation Deliverables Person Date Affected or Status 52 .Change Management Tracking Log <Project Name> No Issue Requestor Title of Date Request Impact and Resp.
Text Modified [insert version number] [insert approval date here] [insert document author] [outline sections modified] [insert version number] 54 . Page(s).Document Information Page Required Information Definition Document: Document ID: Version: Approval Date: Location: Owner: Author: Approved by: [insert document name] [insert document control number or unique ID] [insert version number] [insert approval date here] [insert document file location] [insert document owner] [insert document author] [insert document approver] Amendment History Document Approval Date Version # Modified By Section.
including the roles and responsibilities for those involved. It is an excellent example of a Change Management Process that can be easily adapted to suit the nature of your business. This document provides a Change Management Process which outlines procedures for managing change. 55 .Change Management Procedure Organizations require a process to manage proposed changes to production systems in order to assure the highest performance and availability of the systems we provide for the state.
and ultimately a threat to the safety and welfare of Maine‟s citizens. Additionally. Everyone who has the ability to affect the operation of a system is accountable to ensure that she or he carries out their duties with the highest standards of practice possible. secure. Everyone who has the ability to affect the operation of a system must communicate effectively with customers who could be affected by changes to the system.OIT ENTERPRISE SERVICES CHANGE MANAGEMENT PROCESS Change Control Rationale Technological organizations require a process to manage proposed changes to production systems in order to assure the highest performance and availability of the systems we provide for the state. 56 . Management of the Office of Information Technology is committed to the highest standards of operation. and available computer systems we can afford to produce. effective. Change – An action by any OIT individual that has a possibility of having a noticeable impact on an enterprise or agency production system. it applies to any non-CTS personnel who can modify an enterprise system. or modifies any computer or network systems used by others. Poor change control and the lack of a disciplined approach to making changes results in outages. leading to the most efficient. manages. the inability of people to work. a great amount of wasted time and lost productivity. Scope and Definitions This process document applies to all OIT staff that administers.
The test is whether a user application on that system would be adversely affected if the system were not running properly. Change Initiator (CI) – The individual requesting a change. Production System – A computer or network system and its related software and components that are used to do useful agency work. Request for Change (RFC) – Footprints ticket used to monitor and track changes. or is a subject matter expert or contributor to that system. Stakeholder – A person or group that has an investment. but applications associated with that component.A group of Information Technology professionals that reviews all changes that will cause any possibility for risk of service impact and for scheduling conflicts. A system used solely for testing is not a production system. share. 57 .Contains details of all proposed changes and the proposed implementation dates. Change Summary Report (CSR) . Change Implementer (CIM) – The individual executing the change. Serve as „facilitators‟ for all proposed changes.Responsible for the change process communications and monitors all assigned changes.Change Manager (CM) (CAB chairperson) . or interest in a computer system. Technical Business Consultant (TBC) – Individual(s) assigned to perform as liaison between OIT technology sections and user agencies System Testing – Includes not only the changed component. Enterprise System – A system managed and operated by OIT for the benefit of one or more outside agencies. Change Advisory Board (CAB) .
programmers and others involved with change particularly regarding appropriate testing processes. and disaster recovery. things to consider when planning it. change approval. quality control. workers will be able to identify the reason for a change. how to communicate it and to whom. and how to learn from it in order to improve future change process. By following this process and these guidelines. Continuous Improvement Cycle PLAN -----TEST-----COMMUNICATE-----EXECUTE-----ASSESS-----IMPROVE Use what is learned to continually improve the change process. Set perfection as the goal and use each event as a springboard toward perfection.Intent This document is intended to provide a set of rules and guidelines so that workers will clearly understand the required change management process. the risks posed by it. Considering a Change 58 . how best to ensure success and prevent damage. This process also applies to system administrators. how to document it. version control.
Note and be aware of who uses the system and the impact on them or the people they serve if the system is not available. begin to document and plan the change. but it is always good to be clear about them. Note any dependencies. 2. performant and accurate. clearly state in your documentation the reason(s) for the change. appointed authorities. Identify stakeholders. Note any other systems that are served by the one you plan to change. When considering a change. and many others can be stakeholders. since any change implies some amount of risk. other technicians. Think of who is responsible for the work the system produces and communicate proposed change times to gain feedback into business unit impact. What will be the benefit? What would be the effect if the change were not made? This can be a simple and quick task. Consider what the impact of the change could be if it causes a problem. Agency managers.Changes are required for many reasons. where testing may also be necessary and peers must be consulted. 59 . 1. This is a formal process. OIT managers. Planning the Change Once you have decided a change is required.
Work through objections. Prepare a checklist of steps to implement the change and back it out. 6. Consider what could be done to mitigate the risk. communicate the change proposal to the stakeholders. Ask for confirmation of the risk assessment. If the risk is MEDIUM or HIGH. Document the tests you will perform to mitigate the risks. If the risk is HIGH or if there is disagreement from stakeholders or peers. 8. This is a simple factoring of THREAT times IMPACT. Work with stakeholders to identify the best time to make the change. 4. subject your plan to peer review. If the risk is small but thousands of people could be affected. Perform a preliminary risk assessment. Prepare a comprehensive change detail. If you assess the risk to be MEDIUM or HIGH. you must obtain approval 60 . Finalize your risk assessment.3. If the risk is moderate but few would be affected. it can still be low. What kinds of tests would provide assurance that the change will not do harm? What is the back-out strategy and how quickly can it be done? Can the backout be thoroughly tested before the change? Has the same exact back-out been done before? 5. If the change poses a small chance of causing a problem and few people are affected. 7. the risk may be medium or even high. the risk is low. The detail should be thorough enough that a peer will be able to see what you have done.
UPDATE your plan according to your results. giving as much advance notice to the community as possible. Review the change and learn from any deviation from plan. When feasible. and make it a permanent part of the system documentation. Implement the change according to your plan. FINALIZE your plan. TEST your plan according to your documentation. Follow up. Expect your plan to be reviewed by your director. 13. Your director may want to see changes that have risks lower than HIGH. Communicate the change. Document the change and what was learned.of your plan from your division director. Communicate the change status. confirm your judgment with your director. Decide whether the test was successful. 11. (See AFTER-ACTION REVIEW) 61 . REVISE your risk assessment with what you learn in testing. If in your judgment the change has caused some problems but should not be backed out. 9. (See IMPLEMENTATION) 12. TEST the system and its dependencies. (See CHANGE NOTICE) 10.
time and duration of action Description of action System(s) and application(s) affected User groups affected Plain-English meaning to end users – what they will be unable to do during change. the approximate number of people affected. Any 62 . Changes submitted with a large impact or high risk may result in an implementation delay to ensure adequate publication time has been provided. This subjective risk assessment will be based on the likelihood of a problem. the degree to which the system‟s operation is mission-critical. HIGH. change they will notice afterwards Risk factor – LOW. substantial modification of the information requires re-notification. and the likely longest-time-to-recover. if any. Person responsible. MEDIUM. After the change. including contact information. users and the help desk. If the change was unsuccessful and left a lasting impact. Date. and any known negative consequences of the back-out such as data loss. the CI will include in the RFC the following actions germane to the requested change.Change Notice All Request for Changes (RFC) will be submitted via Footprints by the Change Initiator prior to one CAB meeting (Thursdays at 10:00). whether the back-out has been tested. what. a status update showing whether the change was successful and any current impact must be annotated in the RFC. The information will contain nothing that would compromise system security. The process to back out the change and restore it to its prior state if necessary. At a minimum. notice must be sent to stakeholders.
Implementation Follow your plan‟s checklist step by step. It will 63 . DOCUMENT. Requested changes allowing for only one (1) CAB review may be subject to delay pending requests for more information. and the help desk and the CAB. Your director will work with the system‟s owner and may decide to convene an incident management team to assist you. You must communicate the status immediately to your director. STOP. document the recovery effort. After thorough planning and testing. unless there are extenuating circumstances or your division manager approves the short notice. duty manager. you are in a disaster management mode. ensuring adequate user notification. the AAR is the most important tool for achieving excellence. and assist in any effective way possible. an AAR is required to document the lessons learned. If you find yourself deviating significantly from your plan or if you find you underestimated the risk. stakeholders. etc. If the change causes a system malfunction and the back-out process does not work as planned. If as you proceed you find you have left anything out.Non-emergency changes must be posted to allow for one (1) CAB review prior to execution. After-Action Review (AAR) If the change implementation deviated in any significant way from your plan. This team will handle communications. BACK OUT if necessary. Short notice change approvals must be annotated in the RFC. RETHINK. add it to the RFC in order to document the steps you actually took.
Report back to the CAB within two days of the incident or event. and other technically qualified staff personnel. and lead to improving change management and this document. An AAR is not about assigning blame. 5. The CTO or CAB chair will designate an appropriate individual to initiate an “Incident Management Report”. work as planned? 4. If the change led to a catastrophe – a case where the back-out process did not work and recovery had to be done by making decisions on the fly. Did the agent follow the plan as written? Was there significant deviation? What was different. 3. and what was learned. which will consist of the CAB.. the effects they had. the OIT CTO will convene the AAR group. those who provided technical or planning assistance. 2. and why? Did the back-out plan. If deemed necessary. if used. key stakeholders. The CTO and CAB chair will lead the AAR and ensure that it is documented. Document the lessons learned and make them a permanent part of the system‟s documentation so that future change plans can be informed by what was learned. The proper steps of an AAR are: 1. document what those decisions were. 6.document what was learned by the change agent and anyone else affected by the change. If the change created an unplanned outage or malfunction. The CAB will conduct a standard review of the outcome of the change. the AAR must be formal and detailed. Review the plan. If required. 64 . but it is intended to discover the root cause(s) of problems so they can be fixed.
They may require additional documentation. They will meet on a weekly basis and review all change requests brought before them by the change agent in accordance with the guidelines outlined above.Change Advisory Board (CAB): The CAB will consist of IT representatives from each OIT CTS discipline. 65 . This will allow for the identification of RFCs that will impact their supported agencies/departments to mitigate any conflicts. Alters or modifies a production system. Will cause a predictable user impact or outage requiring sufficient user notification. and/or testing to ensure the requested change is needed has been properly planned for and that appropriate communications to stakeholders have taken place. 1. 2. When to Initiate a Change Management RFC Purpose – The purpose of this section of the document is to explain the OIT process for submitting RFCs or when to use the Customer Support project trouble ticket system. Scope – This document will describe the overall process intent for the use of the Footprints „Request for Change‟ (RFC) ticket and applies to all OIT employees. (RFCs may be used to document changes to test/development systems at section discretion). This section is intended to assist with determining if filing of an RFC is required. A change – Documented via the Change Management project via RFC.
2. Unplanned and unscheduled and not expected. normally. leading to a required immediate fix action. and scheduled for quick implementation. Can be planned and scheduled for convenience or by mutual agreement at user request. 1. next month. RFC ownership – Ownership is delegated to the section implementing the change. 3. 2 weeks. If any change is in response to a trouble ticket. 2. A change or correction is required for production system. The change can be planned. without anticipated or planned modification. Restores or corrects unexpected system issues or outages.) Emergency Change Requests For emergency change requests. the RFC contains a field to reference that ticket. 66 . the following should be present: 1. Maintenance action / fix – NO RFC REQUIRED – Documented via the Customer Service project via trouble ticket.3. (In a week. etc. User service is not impacted but the change needs to be accomplished prior to the next CAB meeting. Has adverse user impact or outage resulting in lack of services to agency or public. 3.
or 3. back-out.1. risk. Completed by technical staff after receiving a user request and gathering appropriate information. or 2. etc. Submitted by OIT staff. Changes to production systems between 7:00am-6:00pm – Any change during this time period must be approved by the CTO or both CAB chairs in the CTO’s absence. 67 . impact. Completed by staff member knowledgeable about the details of the change (procedure.).
ALTHOUGH CAB INPUT SHOULD BE SOUGHT OUT. Scope – This document will describe the overall process. This process is not intended to impede changes. and detail the actions that are required. At this point. Approval must come from a direct supervisor or manager. but to facilitate. the Footprints „Request for Change‟ (FRC) ticket. Non-emergency changes must be posted to allow for one (1) CAB review prior to execution. Requested changes allowing for only one (1) CAB review may be subject to delay pending requests for more information.Use of the Change Management Procedure Purpose – The purpose of this section of the document is to explain the OIT process for scheduling and implementing a change related to OIT production systems and infrastructure architecture. etc. Short notice change approvals must be annotated in the RFC. and mitigate impact. the approving management entity becomes the Change Manager and that individual must update the RFC indicating their approval. unless there are extenuating circumstances or your division manager approves the short notice. THE CHAIR OF THE CAB WITHOUT CAB REVIEW . Procedure – Once a change has been determined to be required. WHEN POSSIBLE. document. ensuring adequate user notification. OR IN HIS ABSENCE. the change must be entered by the initiating party (Change Initiator) into the Footprints OIT Change Management Project. the following procedure must be adhered to: After supervisory approval. EMERGENCY CHANGE APPROVAL MAY BE APPROVED BY THE OIT CHIEF TECHNICAL OFFICER. 68 . The Change Manager assumes the responsibility for ensuring that appropriate notification actions have occurred and for overseeing and monitoring the change and its outcome.
Footprints will notify the Change Advisory Board (CAB) and the OIT TBCs of the nature of the change via the automated Daily Change Summary Report. Mandatory fields are in red text and include items such as date. 4. The summary report is also publicly available on the INET Customer Support page at http://bisisa1asfoot/webreports/Upcoming Changes. The Change Implementer (may be other than the Change Initiator) may then implement the change. All mandatory fields in the “Request for Change (RFC)” must be completed for proper submission. 5. the responsible Change Manager (CM) (or approving management staff member) or CI will be notified via standard Footprints notifications. time. the status will be upgraded to „Authorized‟. system. contacts. impact duration estimate. 69 . 2. Upon acceptance of a change. The change will then be reviewed by the CAB to detect any conflicts with other changes and by the TBCs to detect business unit conflicts.1. The CAB may also request clarification from the CI before authorizing the change at which point the RFC will be placed in the status of „Under Review‟. Any conflicts must be resolved prior to the implementation of the change by feedback to the initiator for a change or scheduling adjustment. Upon successful change implementation. back-out process. Once clarification has been provided. 6. The RFC fields are detailed later in this document. etc. possible global impact.html 3. the change implementer is responsible for annotating the change results and changing the status of the Footprints RFC to „Completed‟.
8. it must be re-submitted to the CAB for review with any planned alterations. The implementer must update the Footprints RFC and document the change issues and reason for back-out. 70 . the implementer will notify the CM and begin the back-out / recovery process. If the change is to be attempted again. 9. The CAB and CM will then receive. In the event that a change must be backed-out. and the CM will publish the results and coordinate user queries. via E-mail the updated ticket. The CAB will then close the ticket upon satisfactory review. The CM is tasked with responding to user queries about the change failure and updating senior management in the event of serious service impact. The CAB will perform an after action review.7. if deemed necessary. If deemed necessary. (Return to Step#2). The CTO or CAB chair will designate an appropriate individual to initiate an “Incident Management Report”.
system reload.) Priority . etc. Comments and Updates – Required field for annotation of changes. Change Initiator Information CI‟s work information. screen modification. Most fields have “drop-down menus” to simplify the entering of the required data. detailed information regarding changes is required.How urgent is the change? Status – Current state of change request. The RFC has been designed to collect that information. 71 . New RFC for OIT Change Management Brief Description – What is the change? (Code upgrade. The following describes the entry fields of the RFC and the type of information to be entered.Footprints Request for Change (RFC) Fields Purpose: This section of the document describes the individual fields of the RFC. yet be simple to use. Introduction: As with any change management system. Scope: Any individual that is required to comply with the OIT Change Process.
Reason for Change – Select an appropriate category from the list. select an appropriate category from the list. Internet. Category . start time. (Shift-End for all.Select an appropriate category from the list. Changes to be Made – What is the change? Detailed Reason for the Change – What is the need for the change? 72 . Related Tickets – If there are related trouble tickets pertaining to the change. MOSES. Agencies Impacted – Select all that apply. ACES. Control-click to select multiple) Systems Impacted – What user services will be impacted? (E-mail. enter them here. mainframe. etc. Risk Analysis – After analyzing the risk.RFC Information Supported Agency – Read the print above this box!! . and end time.This field is used to assign the RFC to a specific TBC.) Authorized By – Approving management individual (that person MUST update the RFC with their approval recommendation). Implementation Date/Time – Scheduled date. MERITS.
who should be contacted? CAB Review Date – When the CAB reviewed the request. CAB Recommendation – Review of the request for authorization. Alternate Contact – Should the change cause issues and the implementer is not reachable.Detail Change Procedure – How is the change going to be implemented? What are the steps? Back Out Plan – If the change fails. Duration of Service Disruption – How long was the user community without service? Change Implementer – Information of the individual actually performing the change. request rescheduling. or request for more information. 73 . how will you recover? Sites Impacted – What physical locations are going to be impacted by the change? Actual Start/End Date/Time – The date and time the change was actually done and completed. CAB After-Action Review – AAR by CAB to detect flaws in the process and research failed changes that caused an adverse impact for the user community.
as this example illustrates. These are the rules of how you want Change Management to work within your business. It does not need to be a long document. This example. shows a clear.Change Management Policy – State of Illinois Change Management Policy is an integral part of Change Management. from the State of Illinois Department of Central Management Services. succinct document which outlines definitions and policies in numbered dot points. 74 .
It‟s a great example if you are looking at making a presentation on Change Management to staff or stakeholders in your organization. It is designed to educate staff about Change Management within the Department and covers the basics of the program. definitions. The following document is a PowerPoint presentation prepared by the Department of Police and Emergency Management on their Change Management Program. 81 . policy and roles and responsibilities.Change Management Program Presentation – Department of Police and Emergency Management Change Management is an integral part of all organizations. including government departments.
they ensure that changes are dealt with promptly and in the most appropriate manner. If formulated correctly. along with steps to change request approval. It‟s a great starting point if you are looking for an example of a succinct. They also ensure that no requests for change go unnoticed. steps for submitting change requests are clearly outlined. 94 .Change Request Procedures Change Request Procedures are an important part of Change Management. In this example. smart approach to change request procedures.
is an excerpt from a larger document sourced from the Department of Innovation. It lists instructions and ideas to try implementing in your business. Read this document and think about which suggestions will work best in your own workplace. It aims to assist your workplace in effectively managing workplace change. Managing Change in the Workplace.Managing Change in the Workplace This document. Australia. Industry and Development of Victoria. 99 .
or rather. how do we deal with change? This document presents many ideas on how to think about tackling change within with workplace.Thinking through Change Change is an inevitable part of running a successful business. and then how to turn those thoughts into positive action. A large part of Change Management is thinking through change. 104 .
or those who are looking to improve their minute-taking at meetings. Please not that this document is not in the Public Domain. Because of the significant matters discussed within CAB meetings. Just add your own logo. It plays an important role in discussing changes and making tough decisions. it is imperative that meeting minutes are kept in a clear and comprehensive way. adapt and use this template to assist in your organization. This template is a great resource for businesses that would like to institute a CAB. 108 .Change Advisory Board (CAB) Meeting Minutes The Change Advisory Board is an integral part of Change Management in most large organizations.
IT Services CAB Meeting Minutes and Process Process: Change Management Status: In draft Under Review Sent for Approval Approved Rejected Version: <<your version>> Release Date: 109 .
This document was. This document provides a basis for completion within your own organization. However. the reader will certainly be prompted with the key topics that have to be considered. Prepared by: On: And accepted by: On: <<date>> <<date>> 110 . This document serves as a guide for DOCUMENTING CAB MEETINGS for the Change Management process. This document contains suggestions regarding information to share with others. The document is deliberately modular so that the reader can pick and choose different sections that may or may not suit their particular purposes.Change Advisory Board Template for Meeting Minutes The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization.
111 . Making sure only suitable Changes are put before the CAB. RFCs 3. The Change Management process requires the following inputs: 1. These include: 1. Change Schedule Activities that are required for the process to function correctly include: 1. RFCs 2. CAB minutes and actions 2. 2. CMDB (Configuration Management Data Base 3. regarding action items (and following up). Change Schedule 4. Change Management reports. The ultimate decision is made in consultation with the Change Advisory Board (CAB).The Change Advisory Board process Change Management is responsible for the approval (or rejection) of any proposed change. It is key that the process activities produce relevant deliverables. Taking minutes. Taking charge at the CAB and any CAB/Emergency CAB meeting 3.
3. 5. 9. 11. 4. REFERENCE NUMBER: Capacity (Role/title) 1. 4. Guest Members Present Capacity (Role/title) Apologies Received 1. 2.CHANGE ADVISORY BOARD MEETING MINUTES Document Location: Meeting Date: Meeting Time: Standard Members Present 1. 10. 7. 4. Capacity (Role/title) Carry over items from last meeting: Action Responsibility Timeline/Notes/Comments 112 . 3. 2. 3. 2. 12. 6. 8.
113 High Medium Low Waiting approval Postponed Cancelled In progress <<others>> Priority Status .Suggestions for next meeting: Item/Action Responsibility Timeline/Notes/Comments RFC’s for Discussion – Summary Table RFC Reference Number 1 RFC346 Immediate Third party pending 2 3 4 5 6 7 RFC 1.RFC346 – the following section is repeated for each change request.
SLA345 / <<role/title>> Security Note <<number of days since this RFC raised>> Install plan sighted Backout plan sighted <<Short description of the change>> Current RFC Status Waiting 114 . that this is a template for documenting a meeting. mobile/cell Related Documents 1. SLA365 2. e-mail.Note. OLA443 3. not for documenting all the details of a change. RFC Reference RFC Owner RFC Contact details Days outstanding RFC346 <<name>> Phone.
Discuss the FSC and the way the change is to be publized. Capture salient points only at the end of the discussion. Remember to repeat the above for each RFC 115 . Ensure that EACH PERSON involved in the meeting fully understands what is expected of this.Approval Notes on RFC346 taken during the meeting. WITH a timeframe for completion. Discuss the rollout and backout plan for suitability.
in an easily adaptable template for you to edit and make your own. This document lists all the most used terms in Change Management. 116 .Request for Change Category Definitions Change Management Category Definitions are an important tool to have at your fingertips when implementing or carrying out Change Management. Please not that this document is not in the Public Domain.
IT Services Category Definition Process: Change Management Status: In draft Under Review Sent for Approval Approved Rejected Version: <<your version>> Release Date: 117 .
If such a change is required the process owner can “submit” the change in the Approved status. Another exception concerns Emergency changes. This document serves as a GUIDE ON SUITABLE CATEGORIES FOR A REQUEST FOR CHANGE FORM within the Change Management process. This document contains suggestions regarding the status that any particular Request for Change (RFC) can be held in. Prepared by: On: And accepted by: On: <<date>> <<date>> 118 . With these changes the “paperwork” is usually done after the change. In nearly all cases the Change requestor will submit the change with the category “Submitted”. The Change Management Process owner may be granted authority to approve minor changes. The Category is initially set by the person submitting the Change request. the reader will certainly be reminded of the key topics that have to be considered. However. This document provides a basis for completion within your own organization. There are exceptions to this. This document was.Request for Change Category Definitions The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization.
It will be your choice whether a change request can hold multiple statuses. or at certain times. For example. An important aspect that the table below should raise is the ability of the Change Management tool. IN PROGRESS After being accepted a Change may take some time to complete. With regard to CHANGE MANAGEMENT the following categories can be used to indicate the current state of activity for a Request for Change. The status field should be able to present a drop down list of choices. The tool may also allow certain status descriptions to be automatically filled in. Meetings can be structured to review RFC‟s of a certain status only. Category ACCEPTED Accepted definition This change has passed through the CAB and has been authorized. REJECTED This change has not been deemed necessary or the change submission is incomplete or inaccurate. a Variance change could also be an Excluded change.Change Category Definitions Having a clear list of categories that a Request for Change (RFC) submission can hold makes the process of running Change Advisory Board (CAB) meetings and reporting much easier. Comments regarding the reason for rejection should be attached. if certain conditions are met. With respect to reporting the categories can be used to show management the different types of changes that are in the Change system. 119 .
but the CAB is waiting on information from a third party (typically someone from outside the organization). It is used primarily for minor changes that 120 . THIRD PARTY PENDING When a change request has been submitted. EXCLUDED Excluded indicates that the change does not have to follow the standard Change Management process. then this status can be applied.This status indicates that work is underway. VARIANCE This change has been submitted to complement or substitute a previously submitted change. EMERGENCY The typical characteristic of an Emergency change is that the approval and associated “paperwork” is completed post change. Care must be taken that this category definition is not abused by those looking to bypass the process.
as the value of the change can be seen. the CAB or Change Manager is seeking additional clarity regarding specific points. REVISED A change that has been HOLDING can be REVISED with new information. 121 . Careful steps should be taken to independently audit Excluded changes on a periodic basis.the Change Manager can selfapprove. There should be some process of appeal in such a situation. This status recognizes the fact that it would be inefficient to have to reject and then re-submit the change. HOLDING A submitted change that has not been rejected. UNDER APPEAL The person submitting a change may not agree with a CAB decision to reject their change. just with the additional information. however.
An example of when it could be used is when the organization is making a major announcement. HISTORIC Once your change management process has been implemented it may be useful to test the process by raising changes for recently performed events or activities. TESTING A change can be lodged that is a trial run change. 122 . This status can also be used to capture details regarding highly significant changes to the infrastructure that may have happened months or years ago. Great care would be taken to ensure that such a change is also taking place with test infrastructure and not in the production environment.INFORMATION This change status is useful when there is no actual change to any element of the IT infrastructure to be made. By capturing these details we create milestone events that can help us to explain or justify changes that may soon follow.
so that you can pick and choose information for e-mails. Please note that this document is not in the public domain. The document is deliberately concise and broken into communication modules. It provides a basis for completion within your own organization. flyers. etc. 123 .Change Management Communication Plan This document serves as a guide for communications required for the Change Management process. It contains suggestions regarding information to share with others. from one or more modules if and when appropriate for your business.
IT Services Communication Plan Process: Change Management Status: In draft Under Review Sent for Approval Approved Rejected Version: <<your version>> Release Date: 124 .
Prepared by: On: And accepted by: On: <<date>> <<date>> 125 . flyers. However. from one or more modules if and when appropriate. This document contains suggestions regarding information to share with others. This document was. The document is deliberately concise and broken into communication modules. the reader will certainly be reminded of the key topics that have to be considered. etc. This document provides a basis for completion within your own organization. This will allow the reader to pick and choose information for e-mails.Communication Plan for Change Management The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. This document serves as a GUIDE FOR COMMUNICATIONS REQUIRED for the Change Management process.
Allows us to more carefully control the valuable IT infrastructure.1. severe penalties. individual and the company face The above Communication module (or elements of) was/were distributed. Initial Communication Sell the Benefits. the IT department in recent times has… A recent example of … saw the In recent times our control on IT has… Specific Organizational example This is important because… unauthorized software. be cautious of using generic words. Generic Benefit statements CM provides accurate information on our IT components. However. Cite specific examples from your own organization that the reader will be able to relate to. WHY? It is here that we need to promote and sell the benefits. Assists with protecting against illegal or Apart from the obvious benefits. To: On: By: On: <<date>> <<date>> 126 . a new way of working. Helps us to more effectively manage our expenditure on IT. First steps in communication require the need to answer the question that most people (quite rightly) ask when the IT department suggests a new system.
Gather specific Change Requirements from nominated personnel (Special Tip: Beware of using only Managers to gain information from. Official Goal Statement: Using a series of standardized and repeatable procedures and actions to be able to introduce changes to the IT infrastructure in such a way that any negative impact is minimized. If you speak to a lot of people regarding Service Delivery then you need to establish ways to report to these people the outcomes and progress of the discussions).2. Provide relevant reports to nominated personnel. Always bear in mind the “so what” factor when discussing areas like goals and objectives. 3. The Goal of Change Management can be promoted in the following manner. High visibility and wide channels of communication are essential in this process. Change Management Goal The Goal of Change Management. but taking into account that changes are required to ensure continued high levels of IT Service Delivery. as the resistance factor will be high) Oversee the monitoring of IT Infrastructure Changes to ensure that the business needs of IT are not impacted. 127 . (Special Tip: Beware of reporting only to Managers. If you cannot honestly and sensibly answer the question “so what” – then you are not selling the message in a way that is personal to the listener and gets their “buy-in”.
database management team (Set-up and ongoing) Accommodation – Physical location (Set-up and ongoing) Software – Tools (Set-up and ongoing) Hardware – Infrastructure (Set-up) Education – Training (Set-up and ongoing) Procedures – external consultants etc (Set-up) The costs of implementing Change Management will be outweighed by the benefits. A well run Change Management process will make major inroads into To: altering that perception. If required.3. Change Management Planning Costs Information relating to costs may be a topic that would be held back from general communication. costs fall under several categories: Personnel – audit verification staff. many organizations have a negative perception of changes that are made by the IT Department. For example. There is a lot of thought that too many changes are made and the changes that do take place cause more problems that they solve. Details regarding the cost of Change Management were distributed. On: By: On: <<date>> 128 <<date>> . Failure to convince people of the benefits will mean total rejection of associate costs.
the Change Manager should be able to coordinate the production and distribution of a Change Schedule. This template is a good example for those looking to create their own Change Schedule. It is considered that in order to correctly facilitate the Change Management process. It is easily adaptable and can be edited to suit your business.Change Schedule Template The document provides an example of a Change Schedule. 129 . Please note that this document is not in the Public Domain.
Change Schedule Process: Change Management
In draft Under Review Sent for Approval Approved Rejected
Document Control Author
Prepared by <name and / or department>
This document is located on the LAN under the path: I:/IT Services/Service Support/Change Management
This document has been approved for use by the following: <first name, last name>, IT Services Manager <first name, last name>, IT Service Delivery Manager <first name, last name>, National IT Help Desk Manager
Issue Date Amendments Completed By
When this procedure is updated the following copyholders must be advised through email that an updated copy is available on the intranet site: <Company Name> Business Unit IT Stakeholders
The purpose of this document is to provide the IT Organization with the specifications of the information to be captured on a Change Schedule
This document provides the following: details of the Forward Schedule of Changes
This document is relevant to all staff in <company name>
IT Services has ownership of this document.
Include in this section any related Change Management reference numbers and other associated documentation: Change Management Implementation Plan / Project Plan Change Management Policies, Guidelines and Scope Document Change Management Process
and contain details of those Changes to the agreed Service Level Agreements and service availability resulting from the planned changes. Agreements on the Change Schedule. Change Management Overview The document‟s intent is to provide an example of a Change Schedule. It is considered that in order to correctly facilitate the Change Management process. scope and organization of the document. is agreed upon with the Business and the IT Departments. the Change Manager should be able to coordinate the production and distribution of a “Change Schedule. It is also advisable that the Change Schedule.” and a “Projected Service Availability” (PSA). This step in the process is critical for the success of Change Management. and Availability Management. Service Level Management. The PSA will be a component of the Change Schedule. 133 . be published via the organizations Intranet or where applicable. will include relevant Customers.Executive Overview Describe the purpose. the internet. The typical parties that will be involved in determining and structuring an Change Schedule. Changes that have been approved for implementation will be listed in the FSC along with their proposed implementation dates. As such it is then important to ensure the Change Schedule. and its subsequent communication will be performed by the Service Desk. Service Desk.
Pending Approval. if unsuccessful. Description: Phase: A brief description of the RFC will be listed. will impact immensely on the organization itself. For example: Assessment. For example: MAC Server. For example.. A High Risk would indicate that the change. This will be allocated either manually by the Change Manager or automatically by an IT Service Management Tool Chg Category: This defines the category for the change. MAC PC. Risk Level: The risk level will indicate the risk of the change to the business. Approved. 134 . etc. Shows the current phase of the listed changes. Build. RFC #: This is the Change Number (Request For Change (RFC). Testing. The following table provides a template for a Change Schedule. Approval Status: This column shows the current approval status of the change. Under Review.Change Schedule. Implementing etc. etc. Software Install.
Initiated By: Shows who actually requested the change originally. 135 .Priority: Priority is used to sort out which changes will occur first. This will be a constant changing value. The actual day that the change will be released into the IT Infrastructure. especially as the needs of the business may change. there would be a need to understand the amount of activities that would occur as a result. Outage Required: Indicates if the change will require an outage. These are called Tasks. Planned Start Date: Planned End Date: Release Date: The planned start date for starting the change. The expected end date for the change. # of Tasks: As some changes are quite complex.
137 .Appendices Include any applicable appendixes that are needed. Terminology Make sure that all terminology is captured and documented correctly.
an RFC is defined as a ticket to record information regarding any request that results in changes to the IT Infrastructure. 138 . This template is a great example of a Request for Change. In this document.Request for Change (RFC) Template This template of a Request for Change (RFC) document provides a list of attributes/fields that need to be captured on an RFC. and could easily be adapted to different types of organizations. Please note that this document is not in the public domain.
IT Services Request for Change Template Process: Change Management Status: In draft Under Review Sent for Approval Approved Rejected Version: <<your version>> Release Date: 139 .
IT Service Delivery Manager <first name. last name>. National IT Help Desk Manager Amendment History Issue Date Amendments Completed By Distribution List When this procedure is updated the following copyholders must be advised through email that an updated copy is available on the intranet site: <Company Name> Business Unit IT Stakeholders 140 . last name>.Document Control Author Prepared by <name and / or department> Document Source This document is located on the LAN under the path: I:/IT Services/Service Support/Change Management Document Approval This document has been approved for use by the following: <first name. last name>. IT Services Manager <first name.
Guidelines and Scope Document CHG7500 Change Management Objectives/Goals 141 . Scope This document describes the following: details of RFC attributes Audience This document is relevant to all staff in <company name> Ownership IT Services has ownership of this document.Introduction Purpose The purpose of this document is to provide the IT Organisation with the specifications of the information to be captured on a Request for Change (RFC). Related Documentation Include in this section any related Change Management reference numbers and other associated documentation: CHG7200 Change Management Implementation Plan / Project Plan CHG7300 Change Management Policies.
The document will guide you through several sections of information. an RFC will be defined as a ticket to record information regarding any request that results in changes to the IT Infrastructure. at which point they may choose a value to populate the field with. Linked Record: Means that the field provides a button to allow the user to click on. User Defined: Field allows the user to enter any value that they wish User Defined Array: Field is considered a large text box which will allow the user to type multiple lines of text 142 .Executive Overview Describe the purpose. which will take them to a list of records in the database. The following definitions apply for the below tables: Read Only: No data may be entered into the field System Generated: The application will automatically generate the correct value(s). For the purpose of this document. indicating that the box has been activated. Change Management Overview The documents intent is to provide a list of attributes / fields that need to be captured on an RFC. These sections could be considered as different tabs on a ticket with in an ITSM tool. Check Box: A box. that when clicked upon will then show a mark. scope and organization of the document.
Drop Box – Nested: The values in this field are dependent on the values listed in the above Drop Box. where they are allowed to make one selection to populate the field. Drop Box: Field allows the user to click on a drop down list of information. 143 . Break in Format: Indicates where there will be a visual break in sets of information captured on the RFC Ticket.
The current phase the Change is in. Drop Box. MAC PC. Field Change No. Drop Box. Test. Pending 3 Party. The current approval status for that Phase. Implement etc. 144 . The level of risk to the Business in conducting the change. Build. Phase Planned Start Planned End Status Approval Status Risk Level Priority The actual status of the Change for that Phase. Date / Time Field Date / Time Field Drop Box. The priority of the change based on implementation. etc. Description (Where Necessary) This is the number for the RFC. Assessment. For example. System Generated. etc. The planned start date for the change. Analysis. etc.General Details This is a common set of information to be gathered for each RFC. Awaiting Approval. Break In Format – INITIATED BY Initiated By First Name This is the person who logged the RFC. This should be an incremental number. Linked Record. For example. Drop Box. The planned end date for the change. Category This will define the category for the change. Drop Box. For example. Drop Box. Approved. Populated by Contact Name. rd Type of Field Read Only. Work In Progress. Read Only. For example: MAC Server. Self Explanatory. Software Install.
Populated by Contact Name. however. An employee id is common solution. Read Only. Type of Field Read Only. Populated by Contact Name. Linked Record. this is a changeable field as tickets may change ownership due to various reasons. Populated by 145 . Phone # Phone Number Read Only. Ext # Extension Number Read Only. Fax # Facsimile Number Read Only. Initially populated by the individual (operator) logging the ticket. Populated by Contact Name. Self Explanatory. Read Only. Populated by Contact Name. Populated by Contact Name. Department Name The company department the person comes from. Email It may be necessary to have a unique ID for each contact on the ticket. Populated by Contact Name. Linked Record. Employee Id. The owner of the ticket can only be a Service Desk representative. Break in Format .Field Last Name Description (Where Necessary) Self Explanatory.COORDINATOR Phone # Phone Number Read Only.
Field that shows all previous entered updates. User Defined Array. Field to allow the users to type any updates. Department The company department the person comes from. Description (Where Necessary) The configuration items being used in the RFC.Field Description (Where Necessary) Type of Field Contact Name. A full description of the ticket. User Defined Array. Read Only. Field RFC Title Description RFC Update RFC Update History Description (Where Necessary) A title for the RFC. Linked Record. Auto Populated based on CI. RFC Description This is a common set of information to be gathered for each RFC. User Defined. Field Configuration Item (CI) Type The type of configuration item being used in the RFC. Type of Field 146 . Linked Record. Type of Field Inventory This section allows user input to capture all the work being carried out during the assessment of the Known Error.
Floor The floor where the CI is located. Vendor The vendor responsible for the CI. Auto Populated based on CI. Auto Populated based on CI.Field Network Description (Where Necessary) The Network that the CI belongs to. Building The building where the CI is located. Room The room where the CI is located. Type of Field Auto Populated based on CI. The serial number for the CI. down. Auto Populated based on CI. Status The Status of the CI. repaired etc. Auto Populated based on CI. installed. Serial No. Auto Populated based on CI. Vendor ID. Auto Populated based on CI. 147 . Auto Populated based on CI. Auto Populated based on CI. For example. The vendor ID for the CI. Location The actually location of the CI within the Company.
Field Description (Where Necessary) Break in Format – SCHEDULED OUTAGE Start Time End Time The start time for the outage for the RFC. Field Justification Code Justification Description Justification History Description (Where Necessary) A code used to provide a brief description for the justification of the RFC. The end time for the outage for the RFC. A capture of the previous justifications for the RFC. Date / Time Field. Read Only. Date / Time Field. Date / Time Field. The actual end time for the outage for the RFC. A full description explaining the justification for the RFC.Justification This section allows input to capture information about justifying the RFC. Drop Box. User Defined Array. Date / Time Field. Break in Format – ACTUAL OUTAGE Start Time End Time The actual start time for the outage for the RFC. Type of Field Outage This section captures any outage information required for the RFC. Break in Format – OUTAGE INFORMATION Type of Field 148 .
Back Out Method This section allows information to be captured regarding back out methods. History of all previous comments captured regarding the outages for this RFC. User Defined Array. Date / Time Field. Column 2 – Table 1. Read Only. Back Out Method A field to capture the back out procedure for the RFC. Field Back Out Duration Description (Where Necessary) Field to capture the expected amount of time to back out of the implementation resulting from the RFC. List of cancelled outages for this RFC. User Defined Array. Type of Field 149 .Rescheduled Outages Cancelled Outages List of rescheduled outages for this RFC. Table Array. Table Array. Outage Comments Outage Comments History Field allowing any comments or information regarding the outages planned for the RFC. Column 1 – Table 1.
Approved. Column 1 – Table 3. Column 3 – Table 2. Table Array. Rejected. Table Array. Column 5 – Table 2. Service Management. For example: Change Sponsor. etc. Column 1 – Table 2. Table Array. etc. # Pending Number of pending approvals from that group. Column 2 – Table 3. an RFC will need to be approved before it can progress from one phase to another. Table Array. # Approved Number of approvals from that group. This section captures the approval process for the RFC. Approver / Operator Group who approved / rejected the change. Table Array Type of Field 150 . Field Description (Where Necessary) Break in Format – CURRENT APPROVALS Approval Type The group that will be responsible for approval. For example. Approval Status The approval status for the approval group listed in column 1 – Approval Type. for example. Reviewed. Pending. Column 2 – Table 2. Table Array. LAN Support.Approvals During certain times. Break in Format – APPROVAL LOG Action The action taken during the approval phase. etc. # Denied Number of Denials from that group. Approved. Table Array. Column 4 – Table 2. There may be more than one person per group.
Table Array. Approved. etc. completed. Status The status for the task. Table Array. etc. For example. Table Array. Approval Status Approval status for the task. Installation. Column 4 – Table 4. Category Category for the task. Security. Field Task No. Tasks As some RFCs may be more complex than others. Column 5 – Table 3. etc. Connectivity. Description (Where Necessary) The number for the task. Table Array. Column 1 – Table 4. Date / Time Date / Time the action occurred. Column 2 – Table 4. Column 4 – Table 3. Pending. initiated. For example. This section provides a list of information to capture regarding these tasks.By Individual who approved / rejected the change Column 3 – Table 3. Type of Field 151 . work in progress. These tasks can be run either sequentially or in parallel. it is possible for them to require a series of tasks to occur so that the RFC can be completed. For example. Table Array. Column 3 – Table 4. Table Array. Phase The phase when the action occurred. Table Array.
Table Array. Column 5 – Table 4. This may include values such as: Change Successful. Post Implementation Review (PIR) PIR Details A full description of the resolution applied to the ticket. A brief description of the results of the Change. Table Array. This information can then be used to improve the Change Management process. Change Successful but Early etc. Field PIR Code Description (Where Necessary) The Post Implementation Review (PIR) code for the RFC. Table Array. Type of Field Drop Box. Column 6 – Table 4. Change Not Successful. End Date The expected end date for the task.Assigned To Who the task has been assigned to for completion. User Defined Array. 152 . Column 7 – Table 4. Post Implementation Details It is important to capture Post Implementation Details after the RFC has been completed. Change Successful but Late. User Defined. Description A brief description of the task.
Auto Populated. See document INC8800 Incident Ticket Template. Auto Populated. Read Only. Brief Description See document INC8800 Incident Ticket Template. Read Only. Open Time See document INC8800 Incident Ticket Template. Auto Populated. Type See document INC8800 Incident Ticket Template. Auto Populated. Read Only. Read Only. Category See document INC8800 Incident Ticket Template. the following information will automatically be attached. Description (Where Necessary) Type of Field 153 . Read Only. When associating another ticket to the RFC. Status See document INC8800 Incident Ticket Template. Auto Populated. The association would be done by a corresponding search and attachment process. Read Only.Related Tickets Details It should be a function of the IT Service Management tool to allow users to associate other tickets to the RFC being worked on. Field Incident Tickets Incident ID. This will be determined by the tool itself. Auto Populated.
Read Only. Read Only. Open Time See document PROB6800 Problem Ticket Template Status See document PROB6800 Problem Ticket Template Category See document PROB6800 Problem Ticket Template Brief Description See document PROB6800 Problem Ticket Template Known Error Tickets Error ID See document PROB6900 Known Error Ticket Template Open Time See document PROB6900 Known Error Ticket Template Status See document PROB6900 Known Error Ticket Template Category See document PROB6900 Known Error Ticket Template Read Only. Read Only. Auto Populated. Read Only. Auto Populated. Auto Populated. Auto Populated. Auto Populated. Auto Populated. Auto Populated. Read Only. Auto Populated. Auto Populated. Read Only. Read Only.Field Problem Tickets Problem ID Description (Where Necessary) See document PROB6800 Problem Ticket Template Type of Field Read Only. 154 .
Auto Populated. Read Only. Category The category type for the RFC. Read Only. Asset The Critical configuration item being used in the RFC. Read Only. Read Only. Request For Changes Change Number The RFC number. Planned Start Date The planned start date for the RFC. Auto Populated. Auto Populated. Auto Populated. Read Only. Planned End Date The planned end date for the RFC. Description A brief description of the RFC. Auto Populated. Auto Populated. Read Only. 155 . Auto Populated. Read Only. Auto Populated.Field Brief Description Description (Where Necessary) See document PROB6900 Known Error Ticket Template Type of Field Read Only. Phase The current phase that the RFC is in.
Linked Record. Time the RFC was opened / created / logged. Name of the individual who closed the RFC. Time the RFC was closed. Linked Record. Name of the individual who last updated the RFC Date / Time Field. Date / Time Field. Type of Field 156 .History Field Opened By Opened At Updated By Update At Closed By Closed At Time the RFC was last updated. Date / Time Field. Description (Where Necessary) Name of the individual who opened / created / logged the RFC. Linked Record.
Include any applicable appendixes that are needed. Terminology
Make sure that all terminology is captured and documented correctly.
Administrative Strategic Planning and Change Management – PowerPoint Presentation
This PowerPoint presentation provides an overview of the administrative strategic planning and change management initiatives of the National Institutes of Health. It is a good example of a presentation your business might deliver to convey upcoming changes or implementations of new or improved policies on change management and strategic planning.
It is an easy-to-understand document which shows what to do in the event of a change.Change Management Procedure – Rail Tourist Services Having good Change Management procedures in place is integral to ensuring your organization can deal with change in an effective and efficient manner. This document could be adapted to use within your own business. This example of a change management procedure is sourced from Rail Tourist Services. 170 .
TOURIST RAIL SERVICES CHANGE MANAGEMENT PROCEDURE April 2006 Rail Safety Regulators Panel Australia 171 .
0 Copy No: 1 1.: TRS P 003 Rev.0 Reviewed & Approved by (Signature) Document Owner revision by 172 .Document Control Record Document Title: Change Management Procedure Document No. Document Status Record Status Date Issue Prepared (Signature) Draft Rev.
2. 173 . Document Distribution List Position Organisation Copy Issued to (Yes/No) Master Copy (Manager) Operations Manager Rail Track Supervisor Rolling Stock Manager Network Manager TRS Yes 1 Copy No.
1. processes and systems including The driving or operation of trains Control of the movement of trains Rolling stock activities Infrastructure maintenance activities Safe working systems and procedures Organizational Structure including Creation or deletion of positions 174 . Scope This process is to be applied to all proposed changes to: Infrastructure including Track and civil infrastructure Signalling. Purpose To provide direction for the planning and safe implementation of change to TRS rail safety activities and the TRS Safety Management System. operational systems and telecommunications infrastructure <Electric traction infrastructure where appropriate> Procedures. 2.
Definitions 175 . 4. Changes to organisation hierarchy Job roles and responsibilities Any other proposed changes that may affect the safety of TRS activities or impact on the safety of other parties including interface with other engineering and operating systems equipment and non-rail infrastructure including roadways personal workplace safety changes to rolling stock or infrastructure or other standards.1 Rail Safety Management Rail Safety Act Australian Standard AS 3911. Responsibilities The Management Committee will determine who will be responsible for safety validation sign off. 3. References Australian Standard AS4292.1 Guidelines for Auditing Quality Systems Australian Standard AS 4360 Risk Management 5.
processes and systems. rolling stock. organisational structure or job roles and responsibilities unless the processes described in this procedure are followed.2 Requirements Any proposed change which could affect safe operations shall require the following: A risk assessment.3) Documentation of the change and a record of the change placed in the Change Register The preparation and lodgement with the rail safety regulator of an application for variation of accreditation if a material change is to be made. 6. procedures. 176 . 6. including relevant rail safety workers A check that the proposed change conforms with relevant legislation The development of a Safety Validation (see section 6. 6. conducted in accordance with the TRS Risk Management Process The identification of suitable controls Consultation with affected internal and external stakeholders.Management Committee The Management Committee identified in the Rail Safety Management Plan (TRS M 001).1 Actions General The Management Committee will collectively and as individuals ensure that no changes to TRS infrastructure.
e. The independent review may be conducted within another area of the organisation. the Safety Validation shall be submitted for independent review. The Safety Validation shall cover each of the life cycle stages affected by the change (i. construction. 177 . operation. In cases where the proposed change is associated with a high degree of risk. In some cases more than one person may need to sign off the safety validation. The Management Committee will determine who will be responsible for Safety Validation sign off.4 Sign Off Safety Validation shall only be undertaken by people who have the skills.3 Safety Validation Before a proposed change is implemented a Safety Validation shall be prepared. decommissioning and demolition. at the discretion of the Management Committee. knowledge and experience in the areas affected by a proposed change. modification. design. maintenance. No change shall be introduced before the Safety Validation is complete and approved by the Management Committee. implementation. commissioning. 6. concept. monitoring. or by an external party.6.
such as change in work practices and business practices that are associated with ICT. It is an excellent example of Change Management Guidelines sourced through the NSW Department of Commerce.Change Management Guidelines – Department of Commerce This document promotes the understanding of the key requirements for the successful management of the change within an agency. It is a great resource if you are looking to implement a document such as this one into your own organization. 178 .
read. Through Content on Demand Online you can find.theartofservice.com/.Further Information Most documents in this book are in the public domain and sourced through the Content on Demand Online service: http://content. edit and use hundreds of documents for technical and business professionals. 193 . Visit the site today for a comprehensive listing of all documents available for download.
This action might not be possible to undo. Are you sure you want to continue?