I want someone who has experience in project management

CHANGE MANAGEMENT PLAN TEMPLATE

Introduction

Start the development of your Project Change Management Plan with this template. Download the Microsoft Word version by clicking on the icon below. This template is completely free and is intended to support your project change management process.

Change Management is an important part of any project. Changes must be vetted and managed to ensure that they are within the scope of the project and are communicated to all stakeholders if they are approved. The process for submitting, reviewing, and approving changes must also be communicated to all stakeholders in order to properly set expectations. If changes are allowed to be submitted or are implemented in and unorganized way, any project is sure to fail. All projects must include a Change Management Plan as part of the overall Project Plan, it can either be included as a section in the Project Plan or as an appendix as a subsidiary management plan.

The Change Management Plan was created for the Inventory Services (IS) Project in order to set expectations on how the approach to changes will be managed, what defines a change, the purpose and role of the change control board, and the overall change management process. All stakeholders will be expected to submit or request changes to the IS Project in accordance with this Change Management Plan and all requests and submissions will follow the process detailed herein.

Change Management Approach

This section of the Change Management Plan describes the approach the organization will use for managing change throughout the project. Throughout a project’s lifecycle there may be very few or very many submitted changes. The approach taken to manage these changes must be consistent and repeatable in order to provide a quality change management plan and process.

The Change Management approach for the IS Project will ensure that all proposed changes are defined, reviewed, and agreed upon so they can be properly implemented and communicated to all stakeholders. This approach will also ensure that only changes within the scope of this project are approved and implemented.

The Change Management approach is not to be confused with the Change Management Process which will be detailed later in this plan. The Change Management approach consists of three areas:

• Ensure changes are within scope and beneficial to the project

• Determine how the change will be implemented

• Manage the change as it is implemented

The Change Management process has been designed to make sure this approach is followed for all changes. By using this approach methodology, the IS Project Team will prevent unnecessary change from occurring and focus its resources only on beneficial changes within the project scope.

Definitions of Change

This section of the Change Management Plan defines the different types of changes that may be requested and considered for the project. These changes may include schedule change, budget change, scope change, or project document changes. Most changes will impact at least one of these areas and it is important to consider these impacts and how they will affect the project.

There are several types of changes which may be requested and considered for the IS Project. Depending on the extent and type of proposed changes, changes project documentation and the communication of these changes will be required to include any approved changes into the project plan and ensure all stakeholders are notified. Types of changes include:

• Scheduling Changes: changes which will impact the approved project schedule. These changes may require fast tracking, crashing, or re-baselining the schedule depending on the significance of the impact.

• Budget Changes: changes which will impact the approved project budget. These changes may require requesting additional funding, releasing funding which would no longer be required, or adding to project or management reserves. May require changes to the cost baseline.

• Scope Changes: changes which are necessary and impact the project’s scope which may be the result of unforeseen requirements which were not initially planned for. These changes may also impact budget and schedule. These changes may require revision to WBS, project scope statement, and other project documentation as necessary.

The project manager must ensure that any approved changes are communicated to the project stakeholders. Additionally, as changes are approved, the project manager must ensure that the changes are captured in the project documentation where necessary. These document updates must then be communicated to the project team and stakeholders as well.

Change Control Board

Here the Change Management Plan describes the Change Control Board, the purpose of the board, and the members and their roles on the board. The change control board is the approval authority for all proposed project changes. If a change is not approved by the control board then it will not be implemented with the project. The size and function of change control boards may vary depending on the organization but their purpose and the roles and responsibilities are consistent.

The Change Control Board (CCB) is the approval authority for all proposed change requests pertaining to the IS Project. The purpose of the CCB is to review all change requests, determine their impacts on the project risk, scope, cost, and schedule, and to approve or deny each change request. The following chart provides a list of the CCB members for the IS Project:

As change requests are submitted to the IS Project Manager by the project team/stakeholders, the Project Manager will log the requests in the change log and the CCB will convene every other Friday to review all change requests. For a change request to be approved, all CCB members must vote in favor. In the event more information is needed for a particular change request, the request will be deferred and sent back to the requestor for more information or clarification. If a change is deemed critical, an ad hoc CCB meeting can be called in order to review the change prior to the next scheduled bi-weekly CCB meeting.

Roles and Responsibilities

This section of the Change Management Plan describes the roles and responsibilities of project team members in regards to the change management process. It is important that everyone understands these roles and responsibilities as they work through the change management process. These roles and responsibilities must be communicated as part of the change management plan to all project stakeholders.

The following are the roles and responsibilities for all change management efforts related to the IS Project:

Project Sponsor:

• Approve all changes to budget/funding allocations

• Approve all changes to schedule baseline

• Approve any changes in project scope

• Chair the CCB

Project Manager:

• Receive and log all change requests from project stakeholders

• Conduct preliminary risk, cost, schedule, scope analysis of change prior to CCB

• Seek clarification from change requestors on any open issues or concerns

• Make documentation revisions/edits as necessary for all approved changes

• Participate on CCB

Project Team / Stakeholders

• Submit all change requests on standard organizational change request forms

• Provide all applicable information and detail on change request forms

• Be prepared to address questions regarding any submitted change requests

• Provide feedback as necessary on impact of proposed changes

Change Control Process

This part of the Change Management Plan should describe the change control process from beginning to end. Typically, a change control process should be an organizational standard and repeatable. This process is the tool which is used to ensure adherence to the organization’s change management approach which was discussed in an earlier section. By following all of the steps, the project team can successfully incorporate approved changes, communicate the changes, and update project documentation.

The Change Control Process for the IS Project will follow the organizational standard change process for all projects. The project manager has overall responsibility for executing the change management process for each change request.

1. Identify the need for a change (Stakeholders) – Change requestor will submit a completed change request form to the project manager.

2. Log change in the change request register (Project Manager) – The project manager will keep a log of all submitted change requests throughout the project’s lifecycle.

3. Evaluate the change (Project Manager, Team, Requestor) – The project manager will conduct a preliminary analysis on the impact of the change to risk, cost, schedule, and scope and seek clarification from team members and the change requestor.

4. Submit change request to CCB (Project Manager) – The project manager will submit the change request, as well as the preliminary analysis, to the CCB for review.

5. Obtain Decision on change request (CCB) – The CCB will discuss the proposed change and decide whether or not it will be approved based on all submitted information.

6. Implement change (Project Manager) – If a change is approved by the CCB, the project manager will update and re-baseline project documentation as necessary.
   Read more: http://www.projectmanagementdocs.com/project-planning-templates/change-management-plan.html#ixzz4ZBMRuKLc

The Risk Management Plan template provided below can be downloaded by clicking on one of the icons above. This Risk Management Plan template is free for you to edit and use as you see fit. Project risk management is part science and part art, this template is a great tool to get you started in managing your project's risks. Be sure to sign up for our Newsletter to ensure you receive announcements about new project management templates.

This section explains why risks exist and highlights the purpose and importance of the risk management plan. It provides a general description of why risk management is essential to effectively managing a project and describes what is needed before risk management can begin.

As organizations begin new projects they begin operating in an area of uncertainty that comes along with developing new and unique products or services. By doing so, these organizations take chances which results in risk playing a significant part in any project. The purpose of the risk management plan is to establish the framework in which the project team will identify risks and develop strategies to mitigate or avoid those risks. However, before risks can be identified and managed, there are preliminary project elements which must be completed. These elements are outlined in the risk management approach.

This project is considered a medium risk project as it has an overall risk score of 24 on a scale from 0 to 100. The project risk score is the average of the risk scores of the most significant risks to this project. A risk score below 16 is low risk project, a score between 16 and 45 is a medium risk project and a score above 45 is a high risk project.

Before risk management begins it is imperative that a foundation is established for providing structured project information, thus, the following project elements were completed and defined prior to developing this Risk Management Plan:

• Define work scope, schedule, resources, and cost elements

  • Develop project WBS/WBS dictionary

  • Develop master schedule and detailed schedules

  • Estimate project cost and finalize budget

  • Identify required and available resources

  • Establish performance measurement metrics

• Define minimum and maximum baseline thresholds

  • Schedule

  • Resources

  • Cost

• Baseline reporting requirements

  • Format

  • Frequency of distribution

  • Distribution list

• Define Risk Management Roles and Responsibilities

  • Project Manager chairs the risk assessment meetings

  • Project team participates in risk assessment meetings and members serve as meeting recorder and timekeeper

  • Key stakeholders participate in risk assessment meetings

  • Project Sponsor may participate in risk assessment meetings

It is important to explicitly state the top three risks to the project in the Risk Management Plan. This will make management aware of the top risks for the project and the nature of the risks.

The top three high probability and high impact risks to this project are:

Delay in Server Equipment
Due to a manufacturer’s production backlog, the servers are not available for large scale application testing causing a delay in the project schedule. The project manager will mitigate this risk by using servers from the backup data center if needed.

Fiber Optics Connection Not Completed
Due to construction delays in installing the fiber optic cable between the data center and the headquarters facilities users will not have a high speed connection between their site and the datacenter resulting in slow responses from the application making it unusable. The Project Manager will implement a site to site broadband Ethernet radio network between the data center and headquarters facility.

Network Operations Center (NOC) Not Appropriately Staffed
Due to lead times associated with hiring and training additional staff, the NOC does not have the necessary staff to monitor the additional bandwidth associated with the project resulting in a delay to the project schedule. The project manager will mitigate this risk by working with the NOC to create an alternate work schedule to compensate for the staffing shortage until additional staff hiring and training is complete.

This section of the Risk Management Plan provides a general description for the approach taken to identify and manage the risks associated with the project. It should be a short paragraph or two summarizing the approach to risk management on this project.

The approach we have taken to manage risks for this project included a methodical process by which the project team identified, scored, and ranked the various risks. The most likely and highest impact risks were added to the project schedule to ensure that the assigned risk managers take the necessary steps to implement the mitigation response at the appropriate time during the schedule. Risk managers will provide status updates on their assigned risks in the bi-weekly project team meetings, but only when the meetings include their risk’s planned timeframe. Upon the completion of the project, during the closing process, the project manager will analyze each risk as well as the risk management process. Based on this analysis, the project manager will identify any improvements that can be made to the risk management process for future projects. These improvements will be captured as part of the lessons learned knowledge base.

Here the Risk Management Plan explains the process by which the risks associated with this project were identified. It should describe the method(s) for how the project team identified risks, the format in which risks are recorded, and the forum in which this process was conducted. Typical methods of identifying risks are expert interview, review historical information from similar projects and conducting a risk assessment meeting with the project team and key stakeholders.

For this project, risk identification was conducted in the initial project risk assessment meeting. The method used by the project team to identify risks was the Crawford Slip method. The project manager chaired the risk assessment meeting and distributed notepads to each member of the team and allowed 10 minutes for all team members to record as many risks as possible.

Expert Interview
Two Expert Interviews were held for this project. The interviews revealed several risks which were then mitigated by making changes to the project plan. The remaining risks are included in the Risk Register.

Risk Assessment Meeting
A risk assessment meeting was held with key team members and stakeholders. The risks identified during this meeting were added to the project plan and Risk Register.

Historical Review of Similar Projects
The project team reviewed the history of similar projects in order to determine the most common risks and the strategies used to mitigate those risks.

Once risks are identified it is important to determine the probability and impact of each risk in order to allow the project manager to prioritize the risk avoidance and mitigation strategy. Risks which are more likely to occur and have a significant impact on the project will be the highest priority risks while those which are more unlikely or have a low impact will be a much lower priority. This is usually done with a probability – impact matrix. This section explains risks were qualified and prioritized for this project. For more information on how to qualify and prioritize risks refer to our Risk Assessment Meeting Guide.

In order to determine the severity of the risks identified by the team, a probability and impact factor was assigned to each risk. This process allowed the project manager to prioritize risks based upon the effect they may have on the project. The project manager utilized a probability-impact matrix to facilitate the team in moving each risk to the appropriate place on the chart.

Once the risks were assigned a probability and impact and placed in the appropriate position on the chart, the recorder captured the finished product and the project manager moved the process on to the next step: risk mitigation/avoidance planning.

This section of the Risk Management Plan should discuss how the risks in the project will be actively monitored. One effective way to monitor project risks is to add those risks with the highest scores to the project schedule with an assigned risk manager. This allows the project manager to see when these risks need to be monitored more closely and when to expect the risk manager to provide status updates at the bi-weekly project team meetings. The key to risk monitoring is to ensure that it is continuous throughout the life of the project and includes the identification of trigger conditions for each risk and thorough documentation of the process.

The most likely and greatest impact risks have been added to the project plan to ensure that they are monitored during the time the project is exposed to each risk. At the appropriate time in the project schedule a Risk Manager is assigned to each risk. During the bi-weekly project team meeting the Risk Manager for each risk will discuss the status of that risk; however, only risks which fall in the current time period will be discussed. Risk monitoring will be a continuous process throughout the life of this project. As risks approach on the project schedule the project manager will ensure that the appropriate risk manager provides the necessary status updates which include the risk status, identification of trigger conditions, and the documentation of the results of the risk response.

Once risks have been qualified, the team must determine how to address those risks which have the greatest potential probability and impact on the project. This section of the Risk Management Plan explains the considerations which must be made and the options available to the project manager in managing these risks.

The project manager has led the project team in developing responses to each identified risk. As more risks are identified, they will be qualified and the team will develop avoidance and mitigation strategies. These risks will also be added to the Risk Register and the Project Plan to ensure they are monitored at the appropriate times and are responded to accordingly. If necessary, the Risk Management Plan will be updated.

The risks for this project will be managed and controlled within the constraints of time, scope, and cost. All identified risks will be evaluated in order to determine how they affect this triple constraint. The project manager, with the assistance of the project team, will determine the best way to respond to each risk to ensure compliance with these constraints.

In extreme cases it may be necessary to allow flexibility to one of the project’s constraints. Only one of the constraints for this project allows for flexibility as a last resort. If necessary, funding may be added to the project to allow for more resources in order to meet the time (schedule) and scope constraints. Time and scope are firm constraints and allow for no flexibility. Again, the cost constraint is flexible only in extreme cases where no other risk avoidance or mitigation strategy will work.

Risk Register Every project must maintain a risk register in order to track risks and associated mitigation strategies. This section describes the risk register criteria as well as where the risk register is maintained and how these risks are tracked in the project schedule.

The Risk Register for this project is a log of all identified risks, their probability and impact to the project, the category they belong to, mitigation strategy, and when the risk will occur. The register was created through the initial project risk management meeting led by the project manager. During this meeting, the project team identified and categorized each risk. Additionally, the team assigned each risk a score based on the probability of it occurring and the impact it could potentially have. The Risk Register also contains the mitigation strategy for each risk as well as when the risk is likely to occur.

Based on the identified risks and timeframes in the risk register, each risk has been added to the project plan. At the appropriate time in the plan—prior to when the risk is most likely to occur—the project manager will assign a risk manager to ensure adherence to the agreed upon mitigation strategy. Each risk manager will provide the status of their assigned risk at the bi-weekly project team meeting for their risk’s planned timeframe.

The Risk Register will be maintained as an appendix to this Risk Management Plan.

Read more: http://www.projectmanagementdocs.com/project-planning-templates/risk-management-plan.html#ixzz4ZBVRjhLp