|
The Project Group, LLC
We specialize in assisting corporate and government clients in learning
to improve their productivity while planning and executing projects.
Our three-phase approach yields faster, more efficient project
initiation, planning and execution results.
|
|
|
Greetings,
Each
month our newsletter delves into a specific step in the phases of
Initiation, Planning and Execution of projects. Our methodology is
applicable to any project in any industry. Our systematic approach to
Project Management is designed to help your company's projects gain
traction quickly, communicate clearly to all parties and keep them on
track to reach a successful conclusion.
We facilitate workshops that jump-start your teams, making sure they
know what they are going to do and validating they have the time and
resources with which to do it.
This newsletter focuses on Process 10:
The processes of identifying,
quantifying and planning for risk.
|
|
|
|
|
|
|
|
· Risk Identification
|
|
|
The PMBOK (PMI's Project Management Body of Knowledge) states that as
part of the first step of Qualitative Risk identification you should
develop an overall risk rating for your project. While the PMBOK is
very clear about evaluating individual risks, it does not offer many
details about this overall plan.
Metrics is about measurement, the supposed dispassionate and
objective.
The concept of metrics,
Qualitative Risk analysis assumes you can measure the impact and
probability of any risk on a project. It also requires prioritizing
all risks based on a combination of that impact and probability. Then
you focus on developing responses to the top five or ten.
Developing an overall risk rating for the project however assumes you
can compare the gravity of the top five on one project and compare it
with the top five on several other projects to come up with a list of
entire projects in order of their riskiness.
This may be possible by using a consistent tool over time. And as with
any tool, users would have to employ the tool consistently.
An overall risk rating for a project can be developed based on the
following factors:
Project Duration -
longer projects are riskier than shorter projects. There's more
opportunity for something to go wrong or for the project to lose its
strategic importance to the company.
Project Cost -
Larger dollar value projects tend to be riskier than smaller ones. As
the dollar values go up everybody gets more nervous and wants to
inject their opinions of how not to lose the pennies.
Project Team Size -
The more people you have the more possibilities for mistakes. You
could make an argument for a small team project having more risks. If
one of three people gets sick, you've lost 33% of your resources!
Maturity of the Technology
- In Information Work projects newer, untried technology is riskier
than systems (hardware and software) that have been around long
enough to get the bugs out.
Team Experience -
Experienced team members know what to do. If somehow you get stuck
with team members who don't know what they are doing your risk
clearly starts to go through the roof.
Lack of Triple Constraint
Flexibility - It's a familiar saw that if time is
flexible on a project you may be able to accommodate fixed scope and
budget. And likewise for the other three constraints. But when each
of the constraints is fixed the risk of project failure increases and
stress goes up. The problems that arrive from stress are also a risk.
Here's an example of a risk-rating matrix with some scoring
possibilities.
|
|
Low
|
Medium
|
High
|
|
Project Duration
|
1 month
|
6 months
|
> 12 months
|
|
Project Cost
|
$10K
|
$100K
|
$1,000K
|
|
Project Team Size
|
5
|
25
|
100
|
|
Maturity of the Technology
|
Five-ten year old, familiar systems
|
One to five year old systems
|
Less than one year old system
|
|
Team Experience
|
Worked with project content for years
|
Worked with project content on last projects
|
Never worked with project content
|
|
Lack of Triple Constraint Flexibility
|
All three constraints somewhat flexible
|
One constraint flexible
|
No constraints flexible.
|
|
Organizational Process Maturity
|
Organization has management process and content methodology
firmly in place
|
Organization is making some effort towards repeatable
processes.
|
What is a repeatable process?
|
Assign a 1 for each risk area if its low, 2 for medium and 3 if it's
high. You can see then, that, for a long project, over a million
dollars with a huge inexperienced team, implementing new technology
on a limited budget and strict schedule scores an eighteen. As a Project
Manager you are going to be stressed.
A high overall risk number is an objective way to bring a project to
the attention of Senior Management that you will probably need extra
resources and support to make the project happen according to
expectations.
|
|
|
|
· Risk Response Planning
|
|
|
Once you have identified and prioritized your project
risks you need to develop plans for dealing with those most likely to
impact the project significantly. The PMBOK (Project Management Body
of Knowledge) calls this Risk Response Planning and includes four
different strategies.
Prevention
Transference --
This means shifting the consequence of a risk to a third party. Find
a vendor who will take over the area of the project you and your team
deem too tricky. Put together a contract that will pay them a premium
to successfully deal with this area. Another approach is to buy
insurance to adequately cover your losses if the risk event occurs.
Unfortunately transference strategies do not make the risk go away.
You still proceed with caution but have a shield.
Mitigation -- This
strategy involves lowering the impact and/or the probability of the
risk event. You might decide not to implement the latest version of a
technology or lengthen the testing cycle. Mitigation may add cost and
scope to the project as you add activities to your WBS. Mitigation
does not seek to avoid the risk entirely. You still have a reasonable
expectation that it will happen. You are just ready for it when it
comes.
Acceptance -- When
you practice this strategy you are simply making a conscious decision
not to alter your project plan in the course of impending risks.
Acceptance does not mean blind acceptance. You are willing to accept
the consequences of the risk event and deal with them as they come.
If you choose this strategy, it's important to notify key
stakeholders of your decision. You may want to include them in your
contingency planning.
Contingency Planning
-- So what if the risk you couldn't prevent or transfer takes place?
Prepare a contingency plan in advance to deal with the risks you
choose to mitigate or accept. It is your "Plan B" and may
include activities such as preparing a tarpaulin to throw over your
roof in case it rains on the day your take off your shingles.
Contingency activities need not be elaborate but they need to be
thoroughly thought out in advance and communicated to all relevant
stakeholders.
As the recent hurricane on the East Coast or forest fires in the West
have shown us, we may not be able to prevent the force of nature from
devastating us but we can have response and recovery plans when there
is enough advance warning.
|
|
|
|
· Next Month In The Newsletter
|
|
|
The October newsletter will feature articles on tracking
and managing projects.
To see previous newsletters
|
|
|
|
