not mobile

Information Technology Handbook

Section 2. Project and Service Administration

Section 2 Introduction

Version date November 7, 2012

IT service can be defined as a set of related functions provided by IT systems in support of one or more business areas, which in turn may be made up of software, hardware, and communications facilities, perceived by the customer as a coherent and self-contained entity. An IT service may range from access to a single application, such as a general ledger system, to a complex set of facilities including many applications, as well as office automation that might be spread across a number of hardware and software platforms.

Effective communication between IT management and their customers regarding services required is enabled by a documented definition of, and agreement on, IT services and service levels. This process also includes monitoring and timely reporting to stakeholders on service level accomplishments. This process enables alignment between IT services and the related business requirements.

A project, by definition, is a temporary activity with a starting date, specific goals and conditions, defined responsibilities, a budget, a planning, a fixed end date, and multiple parties involved. Clear and accurate definition of a project is one of the most important actions you can take to ensure the project’s success. The clearer the target the more likely you are to hit it. Defining a project is a process of selection and reduction of the ideas and perspectives of those involved into a set of clearly defined objectives, key success criteria and evaluated risks.

A project management framework will help maintain the organization’s portfolio of projects that support its IT-enabled programs by identifying, defining, evaluating, prioritizing, selecting, initiating, managing, and controlling these projects in order to ensure that the projects support the organization’s objectives. The framework will help coordinate the activities and interdependencies of multiple projects, manage the contribution of all the projects within the organization to expected outcomes, and resolve resource requirements and conflicts.

A documented definition of, and agreement on, required IT services and service levels must be established between IT management and organization customers. A framework for the management of all IT projects must be established to ensure the correct prioritization and coordination of all projects.

Definitions

The following definitions of Program, Project, Scope, Risk, Issues, Schedule, and Business Case are used throughout this section.

  1. Program: A group of related projects (and services) managed in a coordinated way to obtain benefits and control not available from managing them individually.
  2. Project: A temporary endeavor undertaken to create a unique product, service, or result.
  3. Scope: The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions.
  4. Risk: An uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.
  5. Issues: A problem impacting the successful outcome of a project. Project issues should be tracked through resolution.
  6. Schedule: The planned dates for performing schedule activities and the planned dates for meeting the schedule milestones.
  7. Business Case: A description of a requested project or initiative that explains the goals, benefits, and cost of the request.

2.1 Service Administration

Version date November 8, 2012

A documented definition of, and agreement on, required IT services and service levels must be established between IT management and organization customers. This process should include monitoring and timely reporting to stakeholders on service level accomplishments, which enables alignment between IT services and the related business requirements.

Portfolio management includes the demand and resource allocation across all services, programs, and projects, including those to support your own internal services and projects. Programs and projects exist either to create a new service; to expand, enhance, improve (e.g., to reduce risk or cost per planning unit or to add features); or to retire a service, a phase that is often forgotten.

Service levels must be periodically re-evaluated to ensure alignment of IT and business objectives. All service level management processes should be subject to continuous improvement. Customer satisfaction levels should be regularly monitored and managed. Expected service levels must reflect strategic goals of the organization and be evaluated against industry norms. IT management must have the resources and accountability afforded by the institution to meet service level targets, and senior management should monitor performance metrics as part of a continuous improvement process.


2.1.1 Service Level Management Framework

A framework that provides a formalized service level management process between customers and the service provider must be defined. This framework should maintain continuous alignment with business requirements and priorities, and facilitate common understanding between customers and service providers. The framework should also define the organizational structure for service level management, covering the roles, tasks, and responsibilities of internal and external service providers and customers.

The framework should include processes for creating service requirements, service definitions, and funding sources, as well as documentation such as Service Level Agreements (SLAs) and Operating Level Agreements (OLAs).

Specified service level performance criteria should be continuously monitored, and reports on the achievements of service levels should be provided in a format that is meaningful to stakeholders. The monitoring statistics should be analyzed and acted upon to identify positive and negative trends for individual and overall services provided.

SLAs and their associated contracts, if applicable, with internal and external service providers should be regularly reviewed to ensure that they are effective and up-to-date, and that changes in requirements have been taken into account.


2.1.2 Definition of IT Services

Definitions of IT services should be based on service characteristics and business requirements. These definitions should be organized and stored centrally.


2.1.3 Service Support

Service Support must focus on the IT end user, ensuring that they have access to the appropriate IT services to perform their business functions. Effective service support management requires the identification and classification, root cause analysis, and resolution of issues. This process also includes the formulation of recommendations for improvement, maintenance of issue records, and review of the status of corrective actions.

An effective service support management process maximizes system availability, improves service levels, reduces costs, and improves customer convenience and satisfaction.

This process should include setting up a service desk/service request function with registration, issue escalation, trend and root cause analysis, and resolution, which leads to increased productivity through quick resolution of user issues. In addition, root causes of issues, such as poor user training, can be identified through effective reporting and addressed.

2.1.3.1 Service Desk/Service Request Function

A service desk or service request function, which is the end user interface with IT, should be established to register, communicate, analyze, and route all customer service requests, reported issues, service requests, and information requests. It should be the single point-of-contact for all end user issues. Its first function should be to create a “ticket” in an issue tracking system that will allow logging and tracking of service support requests.

Issues must be classified according to type and business and service priority. There must be monitoring and escalation procedures based on agreed-upon service levels relative to the appropriate SLA that allow classification and prioritization of any service support requests as an incident, problem, service request, information request, etc.

Once an issue has been logged, an attempt should be made to solve the issue at this level. If the issue cannot be resolved at this level, then it should be passed to a second or third level within the issue tracking system and routed to the appropriate personnel for analysis and resolution where necessary. The service desk or service request function should work closely with related processes such as change management, release management, and configuration management.

Customers must be kept informed of the status of their requests. The function must also include a way to measure the end user’s satisfaction with the quality of the service support and IT services.

As a goal, the service desk/service request function should be established and well organized, and take on a customer service orientation by being knowledgeable, customer-focused and helpful. Advice should be consistent, and incidents are resolved quickly within a structured escalation process. Extensive, comprehensive FAQs should be an integral part of the knowledge base, with tools in place to enable a user to self-diagnose and resolve issues.

Metrics must be systematically measured and reported. Management should use an integrated tool for performance statistics of the service desk/service request function. Processes should be refined to the level of best industry practices, based on the results of analyzing performance indicators, continuous improvement and benchmarking with other organizations.

2.1.3.2 Classification of Issues

Processes to classify issues that have been identified and reported by end users must be implemented in order to determine category, impact, urgency, and priority. Issues should be identified as incidents or problems, and be categorized into related groups, such as hardware, software, etc., as appropriate. These groups may match the organizational responsibilities of the end user/customer base, and should be the basis for allocating problems to the IT support staff.

Note that incident management differs from problem management. The purpose of incident management is to return the service to normal level as soon as possible with smallest possible business impact, while the principal purpose of problem management is to find and resolve the root cause of a problem and thus prevent further incidents.

Incident Management
An incident is any event that is not part of the standard operation of the service and causes, or may cause, an interruption or a reduction of the quality of the service. Incident Management aims to restore normal service operation as quickly as possible and minimize the adverse effect on business operations, thus ensuring that the best possible levels of service, quality and availability are maintained. Normal service operation is defined here as service operation within SLA limits.

The objective of incident management is to restore normal operations as quickly as possible with the least possible impact on either the business or the user, at a cost-effective price.

Problem Management
A problem is a condition often identified as a result of multiple incidents that exhibit common symptoms. Problems can also be identified from a single significant incident, indicative of a single error, for which the cause is unknown, but for which the impact is significant. Problem Management aims to resolve the root causes of incidents and thus to minimize the adverse impact of incidents and problems that are caused by errors within the IT infrastructure, and to prevent recurrence of incidents related to these errors.

The objective of problem management is to reduce the number and severity of incidents, and report findings in documentation that is available for the first-line and second-line of the service desk/service request function.

2.1.3.3 Tracking of Issues

The issue management process must provide for adequate audit trail capabilities that allow for tracking, analyzing, and determining the root cause of all reported issues considering:

  1. All outstanding issues;
  2. All associated configuration items;
  3. Known and suspected issues and errors; and,
  4. Tracking of issue trends.

The process should be able to identify and initiate sustainable solutions to reported issues that address the root cause, raising change requests via the established change management process where needed. Throughout the resolution process, regular reports should be received on the progress of resolving reported issues, and the continuing impact of reported issues on end user services and against established SLAs should be monitored.

In the event that this impact becomes severe or reaches established SLA thresholds, the issue management process must escalate the problem.

2.1.3.4 Escalation of Issues

Service desk/service request function procedures must be established so that issues that cannot be resolved immediately are appropriately escalated according to the guidelines established in the SLAs, and workarounds should be provided if appropriate. These procedures should ensure that issue ownership and life cycle monitoring remain with the service desk for all user issues, regardless of which IT group is working on the resolutions.

2.1.3.5 Resolution and Closure of Issues

Procedures must be put in place to close issues either after confirmation of successful resolution of the issue, or after agreement on how to alternatively handle the issue. When an issue has been resolved, these procedures should ensure that the service desk records the resolution steps and confirm that customer agrees with the action taken. Unresolved issues should be recorded and reported to provide information for the timely monitoring and clearance of such issues.

2.1.3.6 Reporting and Analysis

The issue management system must be able to produce reports of service desk activity so that management can measure service performance and service response times, as well as identify trends or recurring issues, so that service can be continually improved.

2.1.3.7 Assessment

Establishing an effective service support process requires well-defined monitoring procedures, including self-assessments and third-party reviews. These procedures should allow continuous monitoring and benchmarking to improve the customer service environment and framework to meet organizational objectives. Remedial actions arising from these assessments and reviews should be identified, initiated, implemented, and tracked.

Service Metrics
The need for metrics is driven by the desire to deliver and demonstrate high quality service. The type of metrics collected is driven by the business and IT requirements for service reporting and Key Performance Indicators (KPIs). Ultimately, metrics collection and aggregation provide input into key business decisions such as how to equitably allocate costs associated with IT.

Service metrics represent the KPIs of an IT service. They should be based on measurable attributes of the associated process, network, system, application, server, or storage components that support the service. For example, the availability of a service may be dependent on the combined availability of various underlying components as well as a minimum volume of transactions processed by an application. The basic requirement of any collected metric is that it be derived from performance and availability attributes of the specified target. Extended metrics will rely on more sophisticated attributes related to resource usage, transactions, and process efficiency. Still other metrics specify indicators that are more representative of business processes and operations.

The technical infrastructure required to measure and collect metric data varies widely depending on the characteristics of the metrics and the availability of supporting data. There are dependencies on how the measured resource is instrumented and how the information can be collected. The complexity, effort, and “cost of collection” required to maintain such an infrastructure in a dynamic environment is another important element.

Use of standards, best practices, and effective integration are important considerations for successful and maintainable IT service metering. To reduce the overhead associated with common data collection implementations that use proprietary agents, IT service metrics should be based on agents with mechanisms supplied by applications and operating systems vendors, or with agents based on standards.

This non-proprietary approach helps minimize support overhead as well as speed deployment since it reduces much of the upfront architectural planning and detailed configuration efforts.

Service Benchmarking
IT service benchmarking defines a strategic management method that compares the performance of one IT service provider with the IT services of other institutions or organizations. Performance means both efficiency and effectiveness criteria. The comparison can be carried out within one institution or organization, but also on a system-wide basis.

The objective of IT benchmarking is to identify optimization potentials and extrapolate recommendations on how performance could be improved. The benchmark is the so-called “best practice.” This means that the institution or its processes provided by the IT service in question largely meets the defined efficiency and effectiveness criteria is the best.

A typical benchmarking procedure may include, but is not limited to:

  1. Identifying efficiency and effectiveness criteria that serve as comparative factors and asking how IT services within an operative process should be changing;
  2. Finding (internal) benchmarking partners and (external) partners/donors, in order to set up a comparative platform, with each partner being prepared to share the necessary information;
  3. Setting up a key data system by taking the comparability into account, with a clear and definition-based boundary in order to ensure a fair comparative platform;
  4. Analyzing the database and identifying the best-practice participants and defining the target benchmark;
  5. Identifying optimization potentials and guidelines by comparison with the best practice;
  6. Calculating theoretical savings potentials (gap to benchmark);
  7. Extrapolating objectives in order to close the gap to best practice;
  8. Setting up an implementation plan; and,
  9. Controlling results and improvements.

2.2 Project Administration

Version date November 8, 2012

A framework for the management of all IT projects must be established to ensure the correct prioritization and coordination of all projects according to priorities established by the Board of Regents, the Chancellor, and institution presidents. This framework may include, but is not limited to, the following:

  1. Business case
  2. Project scope to include deliverables and requirements
  3. Sponsor engagement and appropriate sign off
  4. Schedule, preferably including resources
  5. Method for tracking issues, risks, and decisions
  6. Change management approach
  7. Risk management approach
  8. Testing and implementation
  9. Post-implementation review

The project management framework should define the scope and boundaries of managing projects, as well as the method to be adopted and applied to each project undertaken. This approach:

  1. Ensures project risk management and value-added delivery to the organization;
  2. Reduces the risk of unexpected costs and project cancellation;
  3. Improves communications to, and involvement of, stakeholders and end users;
  4. Ensures the value and quality of project deliverables; and,
  5. Maximizes their contribution to IT-enabled programs.

As a goal, a proven, full life cycle project administration methodology must be implemented, enforced, and integrated into the culture of the entire organization. An ongoing initiative to identify and institutionalize best project management practices should be implemented. An IT strategy for sourcing development and operational projects should also be defined and implemented. Organization-wide planning of programs and projects ensures that user and IT resources are best utilized to support strategic initiatives.

Reference: Institute, P.M. (2008). A guide to the project management body of knowledge. (4th ed.). Newton Square: Project Management Inst.


2.2.1 Initiation

A project management approach should be established commensurate with the size, complexity, and regulatory requirements of each project. The project governance structure should include the roles, responsibilities, and accountabilities of the various personnel involved in the project, and the mechanisms through which they can meet those responsibilities. These personnel may include, but are not limited to,

  1. Program or executive sponsor(s)
  2. Project sponsor(s)
  3. Project leads
  4. IT steering committee
  5. Project manager
  6. Project management organization
  7. Stakeholders
  8. End users

All IT projects must have sponsors with sufficient authority to own the execution of the project within the overall organization strategic plan. To the degree possible, these sponsors should exist outside of the IT department. Stakeholders and end users should be engaged in the work of the program, including projects, to ensure success and collaboration.

The project manager and project management organization should work with the appropriate personnel to develop the appropriate documentation for the project during initiation. This documentation may include several types of documents, such as a business case, a project scope, and other documents that define key aspects of the project such as goals, benefits, risks, resources required, sponsor, success criteria and metrics, etc. Templates for a business case, project scope, change management plan, and risk management plan are shown in Section 2.3.


2.2.2 Planning

A formal, approved integrated project plan should be established to guide project execution and control throughout the life of the project. The project plan should be maintained throughout the life of the project, and changes to it should be approved in line with the IT governance framework. Planning should include documentation of program and project interdependencies so as to minimize risk to all projects undertaken within a program or service.

Working with the project team, the organization should develop the project plan, including the project schedule, change management and communications plans, and the way in which risks, decisions, and issues will be tracked and managed during the project lifecycle. The change management plan should establish the mechanism by which all changes to the project baseline, including cost, schedule, scope, and quality, will be appropriately reviewed, approved, and incorporated into the project plan.

Project risks should be eliminated or minimized through a systematic process of planning, identifying, analyzing, monitoring, controlling, and responding to the areas or events that have the potential to cause unwanted change. Risks should be identified and centrally recorded. Refer to Section 6.0, Risk Management, of this Handbook for more information.


2.2.3 Execution

During the execution phase, the project team should execute the project plan in compliance with the project scope. Approval of the project should be based on IT governance decisions, while approval of subsequent phases should be based on review and acceptance of the deliverables from the previous phase. In the event of overlapping project phases, an approval point should be established by program and project sponsors to authorize project progression.


2.2.4 Monitoring and Controlling

The project timeline, scope, and budget must be monitored and controlled per the project and change management plans during the controlling phase of the project. Project performance should be measured against key project performance scope, schedule, quality, cost, and risk criteria. Deviations from the project plan should be identified and assessed for impact on the project, and results reported to key stakeholders. Remedial action should be recommended, implemented, and monitored, when required, in line with the program and project governance framework.


2.2.5 Closing

A project should be closed when the project sponsor agrees that the project scope has been satisfied. At the end of each project, the project stakeholders must ascertain whether the project has delivered the planned results and benefits. Any outstanding action items that are required to achieve the planned results of the project should be identified, communicated, and disposed of as needed. Project documentation should be archived, and lessons learned for use on future programs and projects should be identified and documented.


2.3 Project Documentation Templates

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.


Information Technology Services
© Board of Regents of the University System of Georgia