not mobile

Information Technology Handbook

2.3 Project Documentation Templates

Print friendly Version date November 8, 2012

The following templates are provided as examples that could be used as a starting point for developing project documentation. Templates already in place at your institution are acceptable as well.

2.3.1 Project Scope

The project scope document must include project goals and deliverables.

Project Name   Date  
Project Sponsor   IT Project Sponsor  
Program Manager   Project Manager  
Executive Summary High level description of the project, linkages to strategic goals, and justification.
Project Description Who, what, when and why of the project.
Project Goals and Objectives These may come from the business case, but should be refined if additional information is available.
Project Scope Specific features, functions, and regulations that must be complied with for the project to be deemed a success. Specify those features and functions that are out of scope for this project.
Project Deliverables What will be produced as a result of this project.
Assumptions and Constraints/Boundaries Assumptions are conditions that are assumed to be true or to exist and will impact the success of the project. Constraints and boundaries are limits to the project deliverables and sphere of influence.
Project Dependencies Conditions that must exist or be met in order for the project to move forward and successfully meet its objectives.

Signature

___________________________________
Project Sponsor
______________________
Date

2.3.2 Change Management Plan

Purpose

The purpose of a Change Management Plan is to set out the methods and procedures to handle all changes affecting this project’s:

  • Resources, costs, and timing as set out in the project plan
  • Deliverable, product and process quality

A change management plan exists to provide a formal process for:

  • Submission and receipt of change requests
  • Review and logging of change requests
  • Determination of the feasibility of change requests
  • Approval of change requests
  • Implementation and closure of change requests

All project changes should enter the Change Management cycle in the format of a Change Request. Legitimate changes to the product/project may stem from:

  • Responses to problems internal to the project
  • Externally imposed requirements
  • Change in business requirements or strategy
  • Proactive changes to improve performance or benefit

A Change Management Plan should employ an industry standard cyclical approach to:

  • Ensure standardized methods, processes and procedures are used for all project changes;
  • Facilitate efficient and prompt handling of all changes; and,
  • Maintain a proper balance between the benefits of change and the detrimental impact of change on the Project Plan.

Change Management Roles and Responsibilities

Role Responsibilities
Project manager
  • Develop change management plan
  • Take change requests to change review board
  • Monitor change requests
  • Log change requests
Project team
  • Evaluate change requests and estimate impact to scope, schedule, and budget
Change Review Board
  • Evaluate change requests and making decisions as to whether they are accepted, rejected, or deferred
Sponsors (Project/IT)
  • Approve change management plan

Change Review Board

Role Name
Project manager  
Change Review Board leader  
Technical Review Board members  
Change Review Board members  

Change Control Documents

Document Function
Change request
  • Documents desired changes as requested or discovered
  • Documents what the change is
  • Documents the rationale and benefit of the change
  • Documents the risk of not changing
Change/Decision log
  • Summarizes change requests received
  • Tracks status of change requests submitted
  • Documents change decisions made, when, and by whom
Type of Change Control Document
Scope
  • Scope statement
  • WBS (work breakdown structure)
  • Product requirements
  • Scope management plan
Time
  • Schedule baseline
  • Schedule
  • Milestones
  • Schedule management plan
Costs
  • Cost baseline
  • Budget
  • Cost management plan
Risk
  • Risk management matrix
  • Risk management plan
Communications
  • Communication plan
  • Stakeholder analysis
Resources
  • Roles and responsibilities
  • Resources/staffing allocations

Change Management Procedures

A Change Management Cycle may be comprised of the following events:

  • Raise and record Change Request (CR)
  • Assess impact and value of change
  • Present assessment results and obtain approval
  • Implement change and re-baseline plan
  • Close CR

Raise and Record Change Request

The change initiator prepares a Change Request and communicates the details of the change to the Project Manager. The change initiator should complete and store the Request Section. Information below reflects information typically requested on a change request form.

Request Section

Completed and sent to the project manager:

Requester Name:  
Requester Contact Information:  
Change Request Date:  
Priority  
Summary of Change:  
Description of Change:  
Rational for Change:  
Benefit of Change:  
Date Required for Approval  

Evaluation Section

Completed by project manager and project sponsors:

Change Request ID:  
Change Request Assigned Date:  
Implication for Project:  
Risk:  
Resource Impact Statement:  
Estimated Impact on Effort:  
Estimated Impact on Cost:  
Estimated Impact on Schedule:  
Decision:  
Decision Detail:  
Decision Maker:  
Decision Date:  

Details of each change request should be recorded in the Change Log.

Assess Impact and Value of Change

The Change Request is escalated to the project core team for technical evaluation. All change requests will be reviewed at team meetings or on an as needed basis. The CR is assessed for its impact on the project plan (resources, costs and schedule) by the Project Manager and the project core team. A brief Business Case is completed with the assistance of the project core team.

Present Assessment Results and Obtain Approval

The results of the CR assessment are presented to the Change Control Review Board – Steering Committee, project sponsor, or other authority. Based on the value judgment passed on the CR, it is accepted or rejected. If accepted, sign-off represents a new agreement on the updated Project Plan. The new timeline, scope, costs, and schedule should be baselined.

Implement Change and Re-baseline Plan

Work should not begin on the Change Request until an approval has been given. At that time, the new work required by the change is undertaken and completed according to the new Project Plan.

Close Change Request

Following successful implementation and testing of the CR work, a closing entry is made in the Change Management Log.

Project Archives

This section defines where change management documentation will be stored and archived.

Signatures

The Project Sponsor signs off on the change management plan, giving authority to the team members to record, assess, track, and approve or reject change requests.


2.3.3 Risk Management Plan

Purpose

A Project Risk Management Plan is a controlling document that incorporates the goals, strategies, and methods for performing risk management on a project. The Project Risk Management Plan describes all aspects of the risk identification, impact analysis and control processes. The purpose of developing such a plan is to determine the approach for performing risk management on the project.

Roles and Responsibilities

Role Responsibilities
Project Manager
  • Leads the development of a project Risk Management Plan
  • Leads the project team through identification of risks
  • Facilitates risk analysis with Risk Management Team
  • Monitors and escalates risks to the Risk Management Lead
Project Sponsor
  • Approves the Risk Management Plan
Risk Management Lead
  • Chairs the Risk Management Team
  • Approves Risk Scoring
  • Approves risk disposition strategy
Risk Management Team
  • Identifies risks
  • Conducts risk impact analysis
  • Develops disposition strategy recommendations
Project Team
  • Identifies risks

Risk Management Methodology

Risk Identification

Methods to be used to identify risks for a project may include, but are not limited to, brainstorming sessions, historical review of similar projects and expert interviews. Risks may be identified during daily project activities, in risk assessment meetings or in critical issues sessions. Identified risks should be added to a project risk register.

Risk Qualification/ Quantification

In order to determine the severity of the risks identified by the team, a probability and impact factor may be assigned to each risk. This process allows the risk management team to prioritize risks based upon the effect they may have on the project. In this template, the project manager utilizes a probability-impact matrix to give each risk a score. The chart below defines the criteria used to calculate the Risk Score. There is an assigned numeric value to each risk factor choice. The risk factor values are multiplied together to calculate the Risk Score.

Probability Impact Timeline
75% - 100% Critical: Project stops or fails  
51% - 74% Elevated: Major impact to project timeline, costs, or scope  
26% - 50% Moderate: May have impact to project timeline, costs, or scope  
0% - 25% Minor: No impact to project timeline, costs, or scope  

Risk Prioritization

Once the risks are assigned a Risk Score they may be prioritized with the highest Risk Score being given the highest priority.

Risk Response Planning

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

The project manager may lead the Risk Management Team to assign a Risk Disposition for each identified risk. Risk Disposition options include:

  • Mitigate - Action will be taken to manage the risk so as to minimize the likelihood that it will become a project issue.
  • Transfer - The risk will be managed outside of the project. The transfer recipient must be identified and accept transfer.
  • Accept - Risk Management Lead approves no action will be taken for this risk.

Risk Monitoring and Control

It is recommended that risks are monitored during the time the project is exposed to each risk. Risk monitoring must be a continuous process throughout the life of a project. As risk mitigation tasks approach on the project schedule, the project manager should provide the necessary status updates that include the risk status, identification of trigger conditions, and the documentation of the results of the risk response.

Risk Register

The Risk Register 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. An example of a Project Risk Register is shown below.

Risk Register chart

See Risk Identification, above, for recommended approaches to identify risks to be entered into the Risk Register.

Based on the identified risks and timeframes in the risk register, each risk may be 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 may assign a risk manager to ensure adherence to the agreed upon mitigation strategy.

The Risk Register should be maintained in a central location available to the entire project team.

Signature

The Project Sponsor must sign the risk plan, thereby agreeing to the project approach for managing project risks.


Return to Top