Five tips for handling project risks

Experienced project managers know that the sooner they've identified possible project landmines, the easier it will be to lessen their impact or avoid them altogether. Here are a few ways to uncover and manage potential risks.

For most projects, it is less a question of "if" they'll run into problems than a question of "when." The success of the project is therefore, to a large degree, dependent on a team's ability to manage the risks associated with that project. The following five tips will help you do just that.

1: Identify potential risks

The key to success in identifying potential risks to your project is to involve the right people. Everyone has a different perspective and interest in a project, and that unique view of the world can be used to uncover a robust collection of risks that you might not otherwise identify. Here are some of the roles to consider tapping into:

  • End users (from a variety of areas)
  • Management (different levels)
  • Developers (from all the affected system areas)
  • Quality assurance
  • Operations
  • Business/system analysts
  • System/data architects

2: Brainstorm

My favorite technique for uncovering risks is to have an open brainstorming session with all the interested parties involved. This is not for the faint of heart. The only way to do it effectively is to have a skilled facilitator running the session. Drill down into each suggested risk only as deep as needed to properly describe it and to determine whether it is valid for the scope of the project. Don't take the time during this session to evaluate the significance of each risk.

3: Analyze

All risks are not created equal. Each risk should be evaluated for the likelihood it will happen, as well as for how big an impact it will have if realized. You can do this over multiple sessions with smaller groups. This will allow you rank the risks and determine which ones will be worth further time and energy to address.

4: Mitigate

You should come up with a strategy to prevent each risk from being realized or for compensating in the event it does occur (create a "plan B"). Ideally, you want to do this for every identified risk. But if time and resources are limited, use the results from your analysis (tip #3) to determine which risks should make the short list for mitigation.

5: Review and revisit

Once you're "done," you're not done. Situations change over time. New risks arise, old ones disappear, and mitigations that seemed like a good idea at the time may need to be rethought. The risks that have been identified should be reviewed on a regular basis and updated accordingly. New perspectives on the project could have a profound effect on the risk profile of the project. Also, make sure that the mitigations that seemed like a good idea when you started the list are still viable and appropriate.

Risk management can be an involved undertaking, and there are already a number of best practices around to help guide the activity. The tips here are hardly a comprehensive review of the discipline, but they are great place to start for the beginner and an excellent reminder for the practitioner.

Related resources

Eddie R. Williams
Eddie R. Williams

Three Tips to Identify Project and Program Risks What you presented are not tips but are significant activities for risk identification and management. With the resulting information a risk management plan is created. A risk management plan is used and developed throughout the project or program and development life cycle. Risk identification and management must continue from the beginning, and throughout, the project or program. And yes, a number of identified roles must be involved. With the list of roles you provided, I include several other roles that, depending on the type of project or program, are involved or participate in the identification and management of risks: The Project/Program Manager Business Subject Matter Experts Subcontractor/vendor representative Configuration management Infrastructure/network Technical Writing Support (an overlooked role but technical writers have a relationship/perspective established by their interaction with, and interviewing, users while creating user manuals, etc.) The appropriate roles would participate, as required, in the particular activity /process to identify possible/potential risks. Three Tips to Identify Project and Program Risks Three tips (perspectives) to identify/uncover risks for IT projects and programs. Identify possible risks based on: 1. The technology being developed and introduced to the organization and user community, impact on the organization, other processes (or systems and their interfaces) and people 2. The project or program scope, its approved budget(s), the project plan and schedules, resources (manpower, money, equipment, etc), procurement and subcontractors/vendors 3. The System/Software Development Life Cycle (SDLC) i.e., requirements identification and analysis, Architecture/Detail Design, Development, System Test, Delivery/Deployment)


What's the authority of the author on htis subject?


Potential risk and analyze are most important and one should give more time for these points. Thanks.


Item 4 should have been Reduce, Avoid or Recover. Risk strategies can be any of the three. Mitigate (= Recover) is only one of the alternatives. (And yes, in the write up you mentioned two out of the three but still. Also these are not tips. They're the tasks involved in risk management -- and only a subset at that.


These tasks have to be completed for every project, you should strive to answer all three but one out of three is not bad. Lets say you have a part that you need to order from a supplier. If at all possible you should order before it is due for installation, you might want to consider more than one if price allows and it is a prototype, original design, high value component or risky component that this should reduce the risk. If it is a known component you could workout a guarranteed function agreement and this would reduce the damage to the project and allow for recovery and avoid having to wait for more parts to be manufactured. Naturally provisions like these should be part of any project part of any proposal and mentioning the three things that PMPsicle brought up are integral to any article on Project Management.

Editor's Picks