Risk Identification and Assessment

You would not begin a project without knowledge and understanding of the risks involved, therefore you must identify and assess these risks and keep them on record for the project team.

In the following table, we show a basic risk identification template that will be useful for you in your initial risk assessment efforts. Note that this is not an all-inclusive list! You'll want to add to the list as you work through your projects and identify more commonly held risks.

Basic Risk Identification Template

Use this template to identify basic risk assessment characteristics. Note that this template can be modified as you go forward in your project management work to account for other elements that you may encounter in your work.

In this table, in column 1, we've identified project categories that are of interest to you. In column 2, you should identify the risk as you see it: L = Low, M = Medium, and H = High. In the notes section, make comments about the category to describe your thoughts about this particular category's risk to the project.

Category	Risk (L/M/H)	Notes
Business Benefit	L	The project's benefit is well established.
Project Scope	L	The scope of the project is understood and well defined.
Sponsor	L	The sponsor has been identified and has accepted the responsibility.
Customer Commitment	L	The customer is committed to the project and wants to see it completed.
Project Manager	L	The project manager has worked on similar projects and understands the nature of what needs to be done.
Project Team Location	L	The project team is centered in one location. (Geographic disparity adds risk to the project.)
Project Methodologies and Processes	L	Project techniques, methodologies, procedures and processes are identified, well understood, and currently in practice corporate-wide. (Note: This does not necessarily imply that there's a PMO.)
Business Requirements	L	The project's requirements have been firmly identified and defined and are well understood.
System Availability	L	This risk identifies the amount of uptime that the system will actually be held to. Note that high availability systems will naturally require more project planning and intervention. You should include system maintenance windows in your availability plans and note them in your risk assessment.
Technical Requirements	L	The requirements put forth in this project are similar to projects we've worked on before.
Data Requirements	L	The data needs are easily defined, built, and maintained .
Geography (deployment locations)	L	There is only one geographic location in which we'll be deploying this system.
Integrated System	L	There are no other systems with which this project will have to interface.
Business Units Affected	L	This project only affects one business unit.
Number of Person-Hours Required	L	This project will require less than 1,000 hours to complete. (Note: You should determine the number of person-hours that makes up a Low, Medium, or High risk.)
Subject Matter Expertise	L	The content of this project is well understood by the project team.
External Dependencies	L	There are no external dependencies (such as vendors ) on which this project relies.
Process Engineering	L	Business processes do not have to change-processes are well-identified and are correct.
Organizational Structure Modifications	L	No modifications to the organization's structure are required in order to enact this project.
Technology	L	Current technologies (e.g., hardware, software, database, internetworking, etc.) can be used to bring about this project.
Data Quality	L	The data in the current system has been properly normalized and lacks any integrity issues. Indexes, triggers, stored procedures, and other database elements have been well defined in the previous system.
Project Costs	L	The costs of the project are accepted and not a problem.
RFP/RFI/RFQ (also Feasibility Study)	L	The various Requests for Input, Requests for Proposal, Requests for Quote, and Feasibility Studies have returned favorable, cost-effective information about the project.
Bleeding-Edge Quotient	L	This project is well within bounds of currently understood technologies
IT Team Communication	L	All the IT teams that will be affected by or working on this project are on board and prepared for its inception.
Infrastructure	L	The infrastructure is in place for the new system

Risk Assessment

Perhaps another useful document for you will be a scorecard that you can use in determining the severity, in decimal form, that a given risk presents . The Risk Assessment and Mitigation Scorecard, shown below, requires that you key in a given risk (see examples already included in the form) along with a number from 0-10 (1-10 for the mitigation element) for various facets of the risk. Add the numbers up and you have your score. Work on making sure that the high scorers have a solid mitigation plan because they're the ones you're most likely to encounter. Remember that risk assessment and mitigation strategies are a team effort, so the form should be worked on at a team meeting.