A riskis the possibility of a problem occurring on the project, thereby threatening the project's outcome in some way. However, not all risks are bad, and not all risks have negative impacts. Some risks are actually opportunities in disguise. For example, agreeing to take on and complete a new project is a risk. Since one of the definitions of a project is creating a unique product or service, the project itself is a risk that's taken on to exploit an opportunity.
An event that poses a potential threat or potential opportunity.
It doesn't matter whether the risk is a threat or an opportunity; if you don't take the time to identify it, you won't know that either exists. Failing to document risks and develop plans for those with the greatest probability for impact can cause your project to fail.
So why should you identify risks, and how do they cause projects to fail if you don't plan for them? Risk can cause rework, which means that you have to go back and repeat some activities you've already completed. Rework almost always means that there will be schedule delays or additional costs or both. If you've completed one of the deliverables of the project only to have a risk event wreak havoc with the results, you'll have to perform additional steps to correct the impact of the event, or perhaps you'll even need to scrap the work that's been done and start over. None of that will come without a cost. You'll likely need to retain resources longer than you had planned, which could jeopardize other projects as well as cost you more money. If all your resources are internal to the organization, you will still incur additional costs. The extra time they are spending on your project prevents them from doing work on other projects, thereby increasing the cost. Additional supplies and materials, extended lease times for equipment you're using on the project, and the replacement of resources that were scrapped all cost money as well.
Note:Risk management is a multistep process. First you identify the risks. Then you analyze the risks and make a determination about the impact of the risk event should it occur. Next, you determine the probability of the risk occurring. Finally, you combine the impact analysis with the probability analysis to determine which of the identified risks need a risk response plan.
Remember that your goal as the project manager is to complete the project to the satisfaction of the stakeholders. In order to do that, you'll need to know what obstacles can spring up along the way to prevent you from completing the deliverables on time and on budget. It isn't possible to know every risk in advance, but the more risks you identify and plan for, the less impact they'll have on the project outcomes. When you plan for risk events, the consequences of those risk events are reduced or perhaps avoided altogether. Take the time in the planning stage to identify risks and come up with action plans even for those risks you cannot avoid or reduce. You'll save yourself precious time figuring out what to do when they do occur if you've planned ahead of time.
Risk management is an activity that occurs throughout the life of the project. It begins in the Planning process and continues until the Closing process is completed. Good risk management practices helps you bring your project to a successful ending because you'll have plans in place to deal with potential threats before they occur and you'll have identified potential opportunities that may bring your organization more business, an increase in efficiency, or new ways of performing the work of the project. The advantages of practicing good risk management include:
Project risk is greatest at the beginning of the project because the potential for unsuccessful outcomes or incomplete projects is most likely to occur at the beginning of the project or in the early phases. At this point, so many aspects of the project are yet to be completed and thus have unknown outcomes. This risk decreases as the project nears completion. Careful attention to risk events during the Planning, Executing, and Controlling processes helps assure project success. Let's take a look at some of the risks all projects have in common.
Types of Project Risks
All projects have risk, and several risks are common to all projects no matter how easy or complicated the project appears.
Most risks fall into three categories: known risks, known risks with uncertain outcomes, and unknown risks. Obviously, there isn't much to say about the unknown risks category. By nature of the fact that they're unknown, you can't identify them up front or create specific plans in the event they'll occur. You can plan for them in nonspecific ways, however. We'll talk more about those plans in a later section.
Known risks are events that you or the project team knows have the potential to occur, and they have predictable outcomes. For example, let's say you've been asked to head up your company's annual all-employee meeting. Your company employs 500 people, and all employees plus one guest of their choice are invited to attend the meeting. The owner of your company is a generous person and believes in sharing the wealth because, after all, the employees helped her get to where she is today. The meeting is going to be held at a famous resort in the mountains near your city, and each employee and their guest are encouraged to stay at the resort for one evening (at the company's expense). The meeting itself will consist of a formal dinner and an awards ceremony. Every employee in the company will receive something. You've been sworn to secrecy regarding the awards and will have to handle these arrangements yourself with no help from the project team.
Known risks with predictable outcomes are fairly easy to spot. An example of a known risk for this project would be the weather—the meeting is being held in November, which means there's a potential for a snowstorm that will prevent folks from getting to the resort.
An example of a known risk with an uncertain result in this case is the number of attendees. Even though you're limiting the employees to one guest each, there's the potential that some may bring more than one guest or that employees say they will attend with a guest but won't show up. Now let's take this one step further and find out how to identify specific risks for your project.
Common Project Risks—Where Are They Hiding?
Risks can come from internal or external sources. Internal risks come about due to the nature of the project itself, organizational issues, employee or resource problems, and so on. External sources of risk include political issues, legal concerns, environmental issues, and social issues.
One of the first places to start identifying risks is with the project itself, looking at internal, known risks. Some of the planning processes you've already completed can help you with this task. The project constraints, WBS, task list, and critical success factors can help you uncover risks regarding the project itself.
Business risks are another area to consider when identifying risks. These include marketing concerns, timing of the product release, and public perception.
This section examines some of the common risks you may encounter on your projects. I'll conclude this section with a checklist that you can use as a template for identifying your project risks.
Project constraints limit the project team in some way, and you usually know about them at the start of the project. Risks, on the other hand, are generally unknown at the beginning of the project. However, looking closer at the constraints can help you identify project risks. Remember that the triple constraints of time, resources, and quality generally have the biggest risk impact on the project. Risks are usually lurking in each of these areas. If time is your primary constraint, risks associated with this constraint could include loss of key personnel, lack of training opportunities in time for critical project activities, vendor delays, equipment failure, and so on. Each of these potential risks has an impact on the project schedule. So the project schedule, or time, is not only a constraint, it's also a key area for us to examine in the risk-identification process.
We can examine resource and quality constraints in the same way. Remember that resources include money, such as the project budget or funding, as well as people. You should consider breaking this constraint into two parts—project budget and project personnel.
Tip:A risk that involves one of the triple constraints will more than likely involve at least one, if not both, of the other constraints. For example, the loss of a key employee during the project is not only a project schedule (or time) risk but a potential budget risk as well. If the employee leaves and you haven't devised a plan to deal with this risk, the project schedule will be impacted and it may cost you megabucks to bring in a contractor with the skills needed to finish the tasks, and that impacts the project budget.
For risk-identification purposes, it really doesn't matter which of the constraints is the primary constraint because each of them have associated risks. Exploring time, resources, and quality will almost always turn up risks on the project. Taking a closer look at each of the constraints is a good way to kick off the risk-identification process.
Identifying Risks in the WBS and Task List
Other great tools you can use to help in the risk-identification process are the WBS and task list. You can see how these planning tools begin to build on themselves and why it's important to document all the project plans. Not only can you use this information as a reference on future projects, you can use it now in the risk-identification process to help you identify potential threats and opportunities. (Here's a hint, you'll use all these documents again in the Executing and Controlling phases of the project.)
Using the WBS, examine the deliverables and the work package levels for risks. One of the deliverables for our employee meeting project is setting up the speaking area of the meeting room with a laptop, projector, and microphone. Some of the risks associated with this deliverable are equipment malfunction, lack of power, and delayed delivery of equipment.
Use the task list in the same manner. Examine each task from the perspective of what can go wrong. Add those risks, or things that could go wrong, to your risk-identification list. We'll talk more about the list shortly.
Critical Success Factors
We talked about critical success factors in Chapter , "Defining the Project Goals." They are usually deliverables or milestones that absolutely must be completed, and completed correctly, to consider the project a success. Again, look over your critical success factors to see what risks you can uncover that might be associated with them.
In Chapter "Defining the Project Goals", I gave you a list of some of the things I consider critical success factors for all projects. Let's look at a few of them again in light of the risks that could be associated with them.
Understanding of and consensus regarding the project goals by key stakeholders, project team, management team, and project manager Risk: If understanding and consensus are not reached, the project will not produce the results expected by the stakeholders, and therefore the project will be unsuccessful. This could result in the loss of business for your company or contractual issues that require legal intervention. Your own job or personal reputation could suffer as a result.
Well-defined scope statement Risk: Poorly defined scope will result in misdirection for the project team, leading to missed deadlines, continual scope changes, rework, inaccurate results, and/or increased costs.
Well-defined project plan Risk: The risks here are similar to what was outlined above in the scope statement risk, including rework, incorrect results, poor quality, increased cost, and missed deadlines.
The use of established project management practices Risk: Not using a standard project management process could result in a lack of communication and organization regarding the project activities, ultimately resulting in an unsuccessful project.
The theme is consistent regarding these critical success factors—if you don't take the time to adequately plan your project activities and communicate well with the project team and stakeholders, your entire project is likely in jeopardy. Planning is an important step in any established project management methodology. I can't emphasize enough the importance of planning, so don't skip these processes.
Depending on the type of project you're working on, business risks may not have as much probability of occurring as risks associated with the triple constraints or critical success factors, but you should be aware of them and identify them because their impacts pack a big punch. If you're caught by surprise and don't have a plan to respond to any of these risks that may affect your project, it could spell disaster. Let's look at some of the most common business risks.
Marketability: If your project is the launch of a new product, marketability is a business risk. One concern regarding marketability is the question, Will customers really pay for this product? This project may build a product or service that everyone inside the company thinks is the next greatest blockbuster hit, but if customers don't perceive the product to have the same value as the company does, they won't buy it.
Timing: Timing of the project is another business-related risk. For instance, maybe your project created the perfect holiday bakeware for home chefs, but due to schedule delays, the product didn't hit the retail shelves until January. Or, maybe your project was creating a documentary of the world's greatest ice cream parlors only to have the FDA issue a ban on all ice cream production for health reasons (heaven forbid!). Be aware of timing issues or impacts to timing issues like these as they could also cause an otherwise successful project to fall flat.
Management issues: Management risks are related to business risks. Management issues that may pose risks to your project include changes in corporate strategic direction, reorganization of the business units, layoffs and cutbacks, and budget restrictions (after budgets have been approved for your project). If you're aware of these issues lurking behind the scenes, you should take them into consideration and evaluate the impacts they could have on the project.
Note:Business and management risks have a small bark and a big bite, so don't overlook their potential impacts to your project.
Vendor delays: Vendor delays and contract issues are another type of business risk. If you're relying on a vendor to deliver critical components or equipment at specific times during the project, you should note the failure to deliver these items on time as a risk. Contract issues can also delay project schedules or impact the project budget. If the vendor does not live up to the terms of the contract, you'll either need to take action to force them to comply or find another vendor. Either way, it will likely cause schedule delays and impact the project budget.
External Project Risks
External project risks include things that are outside the control of the project team and the organization itself. Political issues, legal issues, environmental issues, and social issues are a few examples. Don't overlook obvious things such as the weather, earthquakes, fires, sunspots, alien invasions, and so on.
Technical concerns can also be an external project risk. If you're relying on new technology for a project you're working on, but the release of the new technology is delayed, your project will also be delayed—unless you have alternatives to deal with this risk event. The opposite of this situation can occur as well. Aging technology can be a risk to the project if you're relying on specific technology for your project, but that technology is outdated by the time you're ready to launch the product of the project. Your product may not have a long shelf life as a result or, more likely, it will be canceled before completion.
There are a couple of other issues to think about when identifying risk. One risk that you should be aware of is the complexity of the project itself. Ask the team or project sponsor whether the project team has ever taken on a project of this magnitude before. If the answer is no, then you should document this as a risk and be aware that the project team may require additional training or you may need consulting services to assist the project team, and so on.
Also examine your own skills and ability as a project manager. Are you prepared to take on a project of this size? Have you had sufficient experience with other similar projects to lead this project to a successful conclusion?
Along these same lines, be sure to examine the skills and abilities of the project team members. If the project involves writing a new software program in a language that project team members are not familiar with, document this as a risk. Keep in mind that senior or experienced team members can help identify and mitigate risks more easily than junior team members with less experience.
The process of identifying risks is something the project manager should do together with the project team, the stakeholders, the project sponsor, and so on. In this section, we'll look at a few techniques you can use to get the team's creative thinking processes going to uncover as many risks as possible.
The first attempt at risk identification is more easily accomplished with a small group consisting of key project team members and key stakeholders. Using some of the techniques outlined below, document the risks the team comes up with during this initial meeting in a spreadsheet or other word-processing document. List each risk, assign it a number for tracking purposes, and identify its impacts or characteristics.
After you've compiled an initial list, hold another meeting (or set of meetings depending on the size of the project), expanding the number of participants to include more of the project team members and stakeholders. Again, use some of the techniques outlined later in this section to identify more risks with this bigger group, and add those to the risk list.
Some of the participants you should consider including in your risk-identification meetings are listed below. The project manager should always attend these meetings.
One of the first places you should look for risks is past projects. Here's where those project notebooks you've been putting together and past project documentation come in handy. If you're working on a project that's similar in nature, scope, and complexity to past projects, you can review the previous project as a starting point for documenting risks in this project.
You are probably already familiar with this technique.Brainstorming is a process in which the project team members, subject-matter experts, stakeholders, and anyone else who might have information or knowledge about this project meet in a single location and name the risks they see for the project.
A method of discovering risk events, alternatives, requirements, or other project information with a group of people who have knowledge of the project, product, or processes used during the project. This process is intended to produce freeform ideas, and no restrictions are placed on the participants.
A facilitator documents the items on a list or a white board, while the participants keep calling out the risks as they occur to them. The dynamics at work here are interesting. The old saying that two heads are better than one applies to brainstorming. Each of the participants will come to the meeting thinking about the risks that may impact their particular function or area. When you bring all these folks together, one group of stakeholders or functional managers will hear the risks the other groups are naming, which will bring to light new risks they might not have thought about if they were doing this individually.
The rules for brainstorming are simple. The group should not look down on anyone's ideas; in other words, no one is allowed to pass judgment. List all the risks identified, using one or two words whenever possible. Try to manage the group so that only one person is speaking at a time, but I'll warn you, once they start rolling with the ideas, it will be hard to keep them from speaking over one another. Keep the enthusiasm going, but do try to maintain order at the same time. Don't assume that one of the risks someone mentions is the same as a risk that was identified earlier.
The Delphi technique uses a questionnaire method to identify potential risks. The questionnaire asks participants about risks associated with the project, the business process, the product of the project, and asks the readers to rank their answers in regards to the potential impacts of the risks. In this technique, people do not have to be located in the same room and, in fact, they don't even have to know each other.
A method of discovering risk events, alternatives, requirements, or other project information using a questionnaire format. This process uses a facilitator to solicit ideas, and participants are not collocated.
If you're acting as the facilitator, you can assemble your participants via e-mail or an Internet or intranet site. Experts from inside and outside the company are asked to identify potential risks for the project using a questionnaire that the facilitator wrote up ahead of time. The participants complete the questionnaire and send it back to you, the facilitator. You will then compile all the responses and organize them in some logical manner—by content or risk type, for example. After you've compiled the responses, you send this list back to each of the Delphi members and ask them for further input, additions, and comments. The participants send their comments and additions back to you, and then you compile a final list.
The Delphi technique removes bias from the process. Since the team members completing the questionnaire are not meeting together as a group, one member is not unduly influenced by others, and each one is free to state what they're really thinking.
Nominal Group Technique
The Nominzal Group technique is similar to brainstorming, but it's more like brain-storming by secret ballot.
Nominal Group technique
A method of discovering risk events, alternatives, requirements, or other project information. This process uses a facilitator to solicit ideas in writing from the participants.
This technique requires all the participants to be in the same room together. Everyone is given a marker and a pad of sticky notes. You, the facilitator, then ask everyone to write one risk, and only one risk, on a note. You might consider starting out each round by telling the group to think of the most important risk or the risk with the greatest impact to the project and write that risk on a note.
You then collect the notes, post them on a white board or flip chart, and ask the group to think of the risk with the next-greatest impact to the project and write it down. Continue asking them to write down risks in this manner until they can't think of anymore.
After all the risks have been identified and posted on the board, ask the group to rank them and prioritize them. They should perform this first ranking and prioritization in writing, and each of them should submit their rankings to the facilitator. You then assemble and prioritize the risks in order according to the consensus of the written rankings. At this point, you can ask for input or clarification from the group. When you've finished, you'll have a complete list of risks in their order of importance or impact.
The rules for the Nominal Group technique are also simple. Only one risk can be written per note. Once the notes are posted and all the participants can see them, risks should not be duplicated in subsequent rounds. And the participants should not pass judgment on the risks submitted by others. Keep the group size to a manageable number when using these techniques, or you might end up stalling the process.
Tip:The Nominal Group technique is also a great technique to use for determining project requirements.
An interview is a question-and-answer session held with key stakeholders, team members, functional managers, subject-matter experts, and others who have an interest in the project or who have previous experience on projects similar to yours. These folks can tell you what risks are likely to occur on the project based on their experiences with similar projects.
Ask them about risks they've experienced on previous projects or what they think may happen on this project. Ask them about their industry expertise or specialized knowledge regarding the product of the project and its outcomes. Show them the WBS, the task list, and the list of constraints and assumptions to help them think of risks that might occur on this project.
Checklist of Common Project Risks
As we saw earlier, the most common project risks are those risks associated with the triple constraints: time, resources, and quality. If you focus on these three areas, you'll probably discover a great many of the risks that could affect your project. In a later section, we'll discuss how to determine and weigh the impacts of these risks.
Below table is a checklist of risks that you can use to help you begin to identify risks for your projects. I've listed the risks we talked about in the preceding sections in the first column and added a few new ones. You can add new risks to this list that consistently apply to the types of projects you work on. The next column on the checklist is an area for you to briefly note the impact of the risk or to note its characteristics. The last column is a check-off area where you can indicate that you've examined this risk category and documented the risks associated with it. This checklist is intended to be a guideline to start you thinking about risks and their impacts. The risks and impacts you list for your projects should be more specific than what this example shows. When identifying risks for your project, it's important to be specific. For example, simply listing "weather" in your list may not be specific enough. In our annual conference project, snow is much more difficult to deal with than rain and requires different planning. Keep this in mind when identifying your risks.
Table checklist of common project risks
Checklists, like the one in Table, can be developed based on historical information or on the previous experience of the project team members. If you work on projects on a consistent basis that are similar in nature and scope, construct a checklist like the one in above table to help you identify risks on future projects. Don't use checklists as your only form of risk identification, however, as every project is different and you might miss an important risk. Combine the use of checklists with some of the other techniques outlined here to find all the risks for your project.
Risk is something that good project managers plan for ahead of time and monitor throughout the course of the project. All project risks should be identified and documented. This checklist is a way to get your thought processes charged up to start identifying risks on your project. You should also check with your organization or industry associations for checklists. Many industries have checklists that are very specific and will help offset inexperience in the risk identification process or help make certain you've identified all the risks for complex projects.
As with all the other project documents so far, you'll file your list of risks and risk response plans in the project notebook, but you don't want to file them there and then forget about them. As you get closer to the risk event, you'll want to reevaluate the risk and the plans for that risk and make any adjustments needed based on new information you have at the time. So, keep your risk list handy or make a mental note to yourself to check the list periodically.
Once you've identified and documented the risks and their potential impact, you're ready to perform some risk analysis and rank and prioritize the risks. You'll want to know which risks carry the greatest threat so that you can then develop response plans for those risks. First, let's take a look at some analysis techniques.
Project Management Related Tutorials
|Business Analyst Tutorial||Strategic Planning for Project Management Tutorial|
|Software Development Lifecycle (SDLC) Tutorial|
Project Management Related Interview Questions
|Business Analyst Interview Questions||Strategic Planning for Project Management Interview Questions|
|Network Monitoring Interview Questions||Software Development Lifecycle (SDLC) Interview Questions|
|Business process outsourcing (BPO) Interview Questions||Project Manager Interview Questions|
|PMP Interview Questions|
Project Management Tutorial
Building The Foundation
Developing Project Management Skills
Initiating The Project
Defining The Project Goals
Breaking Down The Project Activities
Planning And Acquiring Resources
Developing The Project Plan
Executing The Project
Controlling The Project Outcome
Closing The Books
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.