Professional Documents
Culture Documents
How can project managers assess todayʼs risks so that they wonʼt become
tomorrowʼs problems? Project managers are always on the lookout for risks
and donʼt sit back and wait for risk events to happen. We must take a
proactive approach to managing uncertainty, but it is always helpful if we
have a tool that helps us quickly identify, qualify, and quantify risk. Donʼt
reinvent the wheel! Create a reusable risk assessment that can be used
repeatedly and reliably.
During this process your team shouldnʼt be spending time deciding what
methods youʼll be using to identify, qualify, and quantify risks, since that
should have been defined previously in the risk management plan. Also, itʼs
important to remember that as you gather your risks, it is necessary to
document as many risks as possible within your risk register and quickly
determine their likelihood and impact on a common set of categories
included in your risk assessment. Once these risks are identified,
categorized, qualified and quantified, they will provide essential input into
the rest of the risk management process. It all begins with a robust and
flexible risk assessment tool!
Risks are commonly discussed in project team meetings when risks arise.
However, this process tends to be reactive, and in some cases it may prove
catastrophic if risks are addressed too late. Taking the time to proactively
identify, qualify, and quantify risks is a discipline that every project manager
should pull out from their skills toolbox in order to stave off negative
impacts to project scope, cost, time or quality. Having a scalable risk
assessment template and risk management plan template in your back
pocket will help you ease the pain associated with managing risks.
It is highly recommended that you use facilitated workshop sessions for this
process. Once a subject matter expert group is gathered, it is best to
explain to them that this process will require everyone to put on their
thinking caps and be prepared to think outside of the box during this and
any future sessions. Use the topics included in this section as the agenda
for your sessions. Once you are ready, ask all participants to do the
following:
Then ask participants to form into teams of two or three and compare
notes, and ask them to do the following:
Take an additional 20 minutes to brainstorm specific risk events
Write down each additional risk event on sticky notes and place them
on the board
Now, canvas the group and ask them if these risk events can be
categorized.
After this is done, you can then conduct a session to build consensus as to
whether or not risk categories could be combined or split into more
convenient groupings. Continue the review and revision until a general
consensus has been reached.
When you have completed this process, you should have a risk
categorization matrix (Exhibit 2) that will look something like this:
Each risk event identified above will require that thorough analysis be
conducted in order to identify the criteria and thresholds for the probability
and impact, as well as be well documented. Use the team process again to
do this. Ask team members to pair up and to take several risk events items.
Their job will be to establish the criteria for each and to document what they
think the thresholds should be. This process can happen in a group setting
or as an assignment outside of group meetings. You can then bring the
team together in order to refine the work to be done by the smaller groups.
Low =1
Medium = 2
High =3
The overall risk level should take into account the probability of the risk
arising and the impact to the project. These two scores may be multiplied to
give you the overall risk rating for each risk event. This may be referred to
as the Probability-to-Impact (PI) ratio. In general if the two scores are low
the overall risk would be low. Though it is great to have a single PI score to
identify the overall risk posed by each risk event, it is important to consider
the strength of both indicators and the overall plan you develop to manage
each risk. When you have completed this process, you should have a risk
assessment matrix (Exhibit 3) that will look something like this:
Exhibit 3: Risk Assessment Matrix
The final format of the risk assessment may be produced in Microsoft Word,
Excel, Access Database or an application within a Project Management
Information System (PMIS). The lowest common denominator will likely
dictate the format of the risk assessment in organizations that lack a PMIS.
If a PMIS does exist, it should be made available – either as a downloadable
template or a customized application. Excel worksheets prove to be the
easiest to work with for most organizations because of its ability to use
formulas in order to develop scores. Also, there are several “dashboard”
tools that take advantage of Excel data or databases and convert them into
professional-looking dashboards and project displays.
Not all projects are created equal. Since a key aspect of every project is its
uniqueness, the risk assessment should be made to accommodate
differences amongst projects. Some organizations have risk assessments
that are tailored to the types of projects being managed including
Information Technology, Marketing, Legal, and so forth.
Also, not every pre-identified risk event applies to every project within these
types of assessments. Risk assessment template users should be allowed
to bypass specific risk events that do not apply to their project.
Once the risk assessment has been completed by the project team it should
be reviewed regularly. For projects that face critical, time-constrained
deliverables and where quality is critical, weekly risk assessment reviews
may be considered standard operating procedure. On the other hand, other
“less-critical” projects may require only monthly or quarterly risk
assessment reviews.
The results of the risk assessment should be directly tied to the risk
management plan. Within this plan, each qualified risk will require that an
appropriate risk response be developed and assigned to appropriate team
members who are responsible for identifying these risk events should they
occur.
Communicating Risk
So, how do we manage risk once your risk assessment matrix is complete?
As stated earlier, the process of simply identifying, qualifying and
quantifying risks is the starting point, not the end. The degree that risks will
influence our project will determine our strategies for responding to risk
events when they occur. A solid risk Management Plan should be developed
that proactively addresses how we will avoid, mitigate, or transfer risk. Here
are some best business practices when developing and executing against
your risk management plan:
Make sure risks (no matter how large or small) are identified and
documented in your weekly project status reports. It is better to
provide appropriate advanced notice early on rather than waiting for a
risk event to occur.
Update your risk management plan and specific risk responses in
conjunction with your risk assessment. Be prepared to deal with new
risks in a proactive manner.
Develop project dashboards that are web enabled and available to all
project stakeholders. I have had a lot of success in developing
dashboards that are used primarily by executive management and
project management personnel. Providing up-to-date risk assessment
information via such mechanisms quickly provides a snapshot of the
health of a project in regards to risks. Though there are many PMIS
applications that provide this function, I have found it very beneficial to
create interactive dashboards from data contained in my standard risk
assessment template and publish these dashboards to the web. The
following dashboard component example (Exhibit 4) is a simple
mechanism that can be accessed by all project stakeholders.
(Interactive version of this file can be found at: http://pmi07.pcg-
global.com )
Responding to Risk
Again, this approach can be tailored appropriately to any project. The SWAT
team may consist of a few people including the project manager, an analyst
and an executive manager to provide approval, or it may include a large
team which includes very specific technical and business specialists who
are skilled at dealing with and responding to risks.
Conclusion