Subject: The Project Group, LLC September 2003 Newsletter

The Project Group, LLC

The Project Group, LLC Newsletter

  Advancing Project Management

September 2003  


in this issue


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.



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.





Project Duration

1 month

6 months

> 12 months

Project Cost




Project Team Size




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.

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


 ::  email us
 ::  visit our site

phone: 415-572-3084