CHAPTER 2 Identifying and Documenting Risks In this chapter, I'll discuss the how-tos of managing risks. The first step, of course, is to identify risks. I'll start by discussing a high-level overview of the identification process. This will include looking at categories of risks and describing the types of risks you may encounter on a typical project. Then I'll show you places to look to uncover risks, who to ask for assistance in the process, and some techniques for generating ideas. Next I'll discuss the importance of documenting risks. This will include a description of the difference between risk originators and risk owners. Finally, I'll wrap up with a checklist of the steps involved in the risk identification process that you can use on your next project.

Identifying Risks

Since project managers (PMs) primarily focus on the negative aspects of risk-okay, the really bad things that can happen and ultimately prevent us from completing the project-identifying risks is a little like playing the pessimist. The sky could fall in, a key team member could win the megajackpot, or the big boss could decide to switch gears on everyone and cancel the project altogether. But the purpose of this process isn't to play the pessimist. The purpose is to identify risks so that you can analyze them for their impact on the project and determine which ones need response plans. Additionally, risk identification involves identifying risk triggers, which are signs or symptoms that tell you a risk event is about to occur. It's important to have a plan that describes how you'll go about managing risks, as I discussed in the last chapter. Identifying risks is the first action step you'll perform in your overall risk management strategy. This step starts you on the way to effectively dealing with tangible risks that may affect your project. Identifying risks requires some prep work. So first, gather a few of your project planning documents including the following: Scope statement Resource requirements Work breakdown structure Risk management plan Cost estimates Project schedule Historical information The first place to start is with historical information. Historical information includes documentation, lessons learned, and project information from other projects similar in scope or size to the project on which you're working. NOTE It's always a good idea to review historical information from past projects before beginning risk planning on a new project. Make certain you're examining past projects that are similar in size and complexity to your current project. There's great value in learning from your predecessors and even greater value in not repeating their mistakes. Historical information will tell you the types of risks previous PMs experienced on similar projects, the responses they developed for the risks, and how effective those responses were. This is the first place I always begin when starting a new project and when identifying risks.

Categories

Several elements will help make your risk identification process go smoothly. The first is determining risk categories. Risk categories provide a way for you to organize the risks of your project into logical groupings. Ultimately, at the end of this process you want to end up with a list of risks, their descriptions, their impacts, their categories, and so on that you'll track in a database or spreadsheet program. You can download a Risk List template from www.sybex.com to help get you started with this process. According to A Guide to the PMBOK, at least four categories of risk exist, as follows: Technical, quality, and performance Project management Organizational External Table 2.1 describes each of these categories. I believe many more categories can and should be defined for your project. Limiting yourself to four doesn't provide you the breadth needed to cover all the potential risk events for every project. Your organization, typically, should define the risk categories so they reflect those risks applicable to their business and industry. But if your experience is like mine, you'll have to start from scratch and develop them yourself. I'll help you do that by listing the categories and describing each. Feel free to modify these categories and descriptions to best fit your organization and the project. Keep in mind that not all categories will apply to all projects or industries. That reminds me: some industries may have category lists already predefined. Check your local chapters or well-respected industry websites and use them in conjunction with those shown in Table 2.1. If your organization has a Project Management Office (PMO), check with them as well. TABLE 2.1: Risk Categories CATEGORY DESCRIPTION Internal Risks that come from within the project or organization. External Risks that come from outside the project or organization. Financial Risks associated with revenues, profits, return on investment calculations, project budgets, project costs, and the like. Technical and performance Risks associated with the technical aspects of the project. This could be information technology-related (as in hardware or software) or industry specific such as engineering diagrams, mechanical equipment, building support sys tems (such as HVAC and fire suppression), and so on. Performance risks may involve unproven or complex technology or may involve unrealistic performance goals or measures. Business Risks associated with marketing or timing of product releases, vendor delays, management issues, competitor information, and so on. Organizational Risks associated with the organization itself. Cultural Risks associated with cultural issues or differences (this especially applies to organizations that have an international presence). Security Risks associated with information security, security of personnel, security of assets, and security of intellectual property. Project management Risks associated with project management processes, organizational maturity, and ability. Legal Risks associated with legal issues that may impact the project or the organization. Environmental Risks associated with the project that may have environmental impacts. Scope Risks that impact the scope of the project. Quality Risks that impact the quality of the project or the product of the project. Schedule Risks associated with activity estimating and schedules. Process Risks associated with the business processes or other processes that impact the organization, the customer, or the project. Don't stop with just this list. Use some of the techniques I'll talk about in the "How to Look for Risk" section later in this chapter to engage your team members and stakeholders in defining the categories that apply to your project and organization. You can even define these categories into subcategories. Table 2.2 shows an example of the subcategories possible for the business and technical categories defined in Table 2.1. TABLE 2.2: Risk Subcategories BUSINESS RISK SUBCATEGORIES TECHNICAL RISK SUBCATEGORIES Marketing Hardware Management issues Software Cyclical risks Database Vendor issues Integration Timing Scalability Obviously, you could create subcategories for all the categories listed in Table 2.1. Depending on the complexity of the project and the propensity for risk events (that is, are there a lot of risk events associated with your project or only a few?), you may consider creating subcategories after your categories are established. Risk categories will come in handy later in the risk management process to help establish priorities. For example, your project may not have any legal risks, but technical and environmental risks are both possible. If you know ahead of time that your organization will not tolerate environmental risk, you'll be able to more easily assign risk priorities.

Risk Types

You could further categorize risks into risk types. By this I mean financial risks, human resource risks, technology risks, and so on. In my opinion, defining categories and types of risks for small-to-medium-sized projects can be overkill. I think you'll find categories are sufficient to describe your risks. When you get into larger projects, further classification of risks into risk types can be beneficial because it provides an efficient way to store and sort data. Once you've established your...