The Art of Project Management: Expert advice from experienced project managers in Silicon Valley, and around the world
TOPICS:

A Common Sense Approach to Managing Risk

This weekend I was teaching Project Risk and Opportunity Management at Santa Clara University in the graduate engineering school.  As I was watching the students work on their group projects I pondered that this might be a good topic for a blog.  How should risks and opportunities be managed from a system perspective especially for large and unprecedented projects?

Risk and opportunity are both composed of two elements; probability and consequences.  In the case of risk the consequences are perceived to be negative and with opportunity the consequences are believed to be positive.  Probabilities are the acknowledgement that there is a lot of uncertainty involved in projects and the likelihood that something will or won’t happen, can seldom be known for sure.  Projects are usually undertaken to either solve a problem or take advantage of an opportunity.  The probability that the project even if precisely executed will complete on time, on budget and on performance is typically small.  Project management is utilized to increase this probability.  So in a sense project management is risk management.

There are three primary phases in developing a  risk management plan 1) risk assessment, 2) risk evaluation and 3) risk reduction strategy development and implementation. 

 

The first step, risk assessment, is actually the most difficult because it involves identifying all of the potential risks.  This is typically done by reflecting on previous projects of this type that the organization has performed.  One useful tool for this is a risk checklist.  This checklist is developed by collecting the negative experiences that the organization has experienced during its various projects that it would like not to repeat.  This could include things like avoiding the use of some materials such as beryllium or having unproven technology development on the critical path or starting a project with negative slack.  Use the checklist by considering whether this type of risk is possible or likely on your project.  Risks should be documented in an if/then format.  If xyz happens then the result will be such and such.  For each if there may be several possible negative consequences that should each be listed.

            The second step is risk evaluation.  There are numerous ways that this can be accomplished.  Everything can be used from the very qualitative (high, medium, low) to the very qualitative (probabilistic risk assessment).  Remember the phrase garbage in garbage out when undertaking this step.  I tend to use the qualitative approach first especially in the early stages of a project.  If you have good statistical data then you can use that but just plucking numbers out of the air does no one any good and can give a very false sense of security or panic.  It is important to remember that there are really only two kinds of risks; those that are acceptable and those that are unacceptable.  The risk evaluation process in its simplest form involves separating all the risks into these two categories.

            The final step of developing and implementing a risk reduction strategy involves taking those risks that are evaluated as being too high and figuring out what can be done about it?  There are two basic types of risk reduction strategies; preventative and contingent.  In a preventative strategy we try to reduce the probability of the risk event happening such as doing a simulation to validate performance before committing to a design solution.  In a contingent strategy we focus on reducing the negative consequences if the risk event should happen.  One of the most often used contingent strategies is the use of insurance.  Remember that a contingent strategy requires a trigger that will activate it.  It also must be crystal clear who is going to take action when the strategy is triggered.

            In selecting a risk reduction strategy remember that it may require a combination of both types of strategies to get the risks down to a level where they are acceptable.  Also the question of whether the risk reduction strategy makes good economic sense must be answered.  Is the amount of risk reduction that we are buying worth the time, money are other resources that we will have to consume to implement it?  This is called risk reduction leveraging.  The ideal situation is to find a really big risk that can be turned into a small acceptable risk (or no risk at all) cheaply and easily.  Sometimes this can be done but other times the strategy may be more difficult to sell and creativity is needed.

            Some basic thoughts on risk management planning that I have learned over the years.  First, start addressing risk in the early conceptual phase of the project and make risk a key part of the study.  Default to the low risk paths when they are available (this is called risk avoidance).  Get the entire team involved in identifying and evaluating project risks.  Everyone looks at the project differently and sometimes the input from the student intern can be vital.  Finally re-evaluate the risks on a regular basis, at least every quarter and see what has changed.  Keeping the risk management plan up to date can transform it from a door stop into a vital project management tool.  Remember what you don’t know can kill your project.

            I haven’t spent much time talking about the opportunities but many of the same tools apply you are just looking for positive outcomes instead of negative.  The key here is that with planning you can take advantage of opportunities where without this planning you may just watch them pass you by.  Like knowing that a key potential customer may be at a conference and putting together a pitch just in case you run into them or being caught by surprise with nothing coherent to say.  Little things like this can make the difference between just getting by and hitting a home run.  There is a saying that luck is the conjunction of hard work and preparation.

Share

About the Author

Bruce Pittman has been involved in high technology product development, project management and system engineering for over 25 years. He spent 11 years working for NASA on planetary exploration and space based infrared astronomy projects. From 1985-1998 he was a consultant and educator for both industry and government in project management, system engineering, concurrent engineering, risk management and planning, both in the US and abroad. From 1999-2002 Bruce went back inside corporate America as a Director for two high technology firms, one in telecom hardware manufacturing and the other in enterprise software for new product development. He reactivated his consulting practice in 2003 with a 6 month consulting assignment in Costa Rica with a high tech medical device company. In 1993, Bruce co-founded Profit Engineering Technologies (PET), a high technology project management consulting and education firm. PET developed an integrated set of training courses and consulting services designed to improve organizational efficiency and product development process performance. Bruce also worked with both government and industry project teams as a facilitator, coach, and mentor to increase the speed and quality of the development process and reduce overall project risk. As a consultant, coach and trainer Bruce has worked with a wide variety of both Fortune 1000 companies and smaller companies in the US, Europe, Asia and Central America, including Align Technology, New Focus, Varian, Westinghouse, Lockheed Martin, Northrop Grumman, Cepheid, Behring Diagnostic, and government agencies such as NASA, and DoE. Bruce has also participated in a number of startups in such diverse areas as aerospace, energy, semiconductor manufacturing and medical devices. Bruce has a BS in Mechanical Engineering from UC Davis and a MS in Engineering Management from Santa Clara University. He is a Vice President and member of the Board of Directors of the Society of Concurrent Product Development. Bruce is also an Associate Fellow of the American Institute of Aeronautics and Astronautics. As a member of the International Council on System Engineering (INCOSE) Bruce co-authored the EIA 632 ANSI Standard “Engineering of Systems”. He has published over two dozen papers on technical and management topics and edited two NASA workshop volumes. Bruce has been an invited speaker at many professional society meetings and conferences. In addition to his consulting work Bruce is also a member of the adjunct faculty in the Graduate Engineering School at Santa Clara University. While working at NASA Bruce was awarded two Sustained Superior Achievement Awards and two Group Achievement Awards. He was also presented a Distinguished Leadership Award by the AIAA.
Creative Commons License
Note: This work and all associated comments are licensed under a Creative Commons Attribution-Noncommercial 3.0 United States License.

Leave a Reply

*