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 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.|
2.3.2 Change Management Plan
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
|Change Review Board||
Change Review Board
|Change Review Board leader|
|Technical Review Board members|
|Change Review Board members|
Change Control Documents
|Type of Change||Control Document|
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.
Completed and sent to the project manager:
|Requester Contact Information:|
|Change Request Date:|
|Summary of Change:|
|Description of Change:|
|Rational for Change:|
|Benefit of Change:|
|Date Required for Approval|
Completed by project manager and project sponsors:
|Change Request ID:|
|Change Request Assigned Date:|
|Implication for Project:|
|Resource Impact Statement:|
|Estimated Impact on Effort:|
|Estimated Impact on Cost:|
|Estimated Impact on Schedule:|
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.
This section defines where change management documentation will be stored and archived.
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
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
|Risk Management Lead||
|Risk Management Team||
Risk Management Methodology
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.
|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|
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.
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.
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.
The Project Sponsor must sign the risk plan, thereby agreeing to the project approach for managing project risks.