In today’s business arena there are many risks involved in creating high quality products on time and within budget. With ever-increasing product complexity, increasing demands for better products with more functionality and decreasing time to market windows, doing business is risky.
When teams don’t manage these risks, they leave their projects vulnerable to factors that can cause major rework, major cost or schedule over-runs, delivered product that don’t match their intended use (for example, product that have safety, security, usability or functionality gap) or other project failures.
In our global economy, the possibilities of reward are high, but so are the potential for disaster. Risks exist whether we acknowledge them or not. Sticking our heads in the sand and ignoring the risks can lead to “unpleasant surprises” when some of those risks turn into actual problems. The need for enterprise wide risk management is illustrated in Tom Gilb’s risk principle. “If you don’t actively attack the risks, they will actively attack you”. In order to successfully manage our projects and products, and reap the rewards, we must learn to identify, analyze, plan for, track and control our risks.
WHAT IS RISK?
That said, what do we mean when we are talking about a “risk”? A risk is simply the possibility of a problem occurring sometime in the future. If it is already a problem, put it on the problem list and deal with it — it is not a risk. If it has a 100% chance of happening, it is already a problem – a risk has some possibility of not turning into a problem.
WHEN DOES A RISK START?
As illustrated in Figure 1, a risk starts when a commitment is made. For example, every time I cross the street, I run the risk of being hit by a car. The risk does not start until I make the commitment, until I step in the street.
We don’t have the risks of ACME delivering a low reliability subcontracted component or of ACME being late in delivering that component until we make a commitment and select ACME as our subcontractor. If we choose instead to build the component in-house, different risks exist.
Figure 1 – A Risk is the Possibility of a Problem
We don’t have the risk of a requirement not being feasible until we commit to include that requirement in our product.
WHEN DOES A RISK END?
A risk ends when one of two things happen:
- Bang!! I get hit by the car in the middle of the street – now it’s a problem! It’s no longer a risk.
Other examples where the risk turns into a problem and stops being a risk include:
- We receive deliver of a low reliability component from ACME -> Problem
- ACME is late delivering the subcontracted component -> Problem
- We cannot figure out how to design and implement the committed to requirement -> Problem
- Or I safely step onto the sidewalk of the other side of the street. I accomplish my goal. The risk disappears because there is no longer the possibility of a future problem. My goal has been obtained.
Other examples where obtaining the goal removes the risk include:
- ACME delivers the subcontracted component on time with the required reliability -> Goal obtained
- We figure out an effective way to design and implement the committed to requirement -> Goal obtained
LESSONS LEARNED
Before it turns into an actual problem, “a risk is just an abstraction”. It’s something that may or may not become a future problem. There is a possibility that ignoring a risk won’t come back to bite us. I can ignore the risk and run into the street over and over again without looking both ways first and never have a problem — but then it only takes once.
What’s the old saying – “it’s better to be smart than lucky.” Risk management is all about being smart.
WHAT’S NEXT?
In this series of blogs, I intend discuss the principles, practices and tools of risk management. I will also talk about how to apply these risk management principles, practices and tools to our daily work.
Bio:
Linda Westfall is the president of Westfall Team, Inc. which provides software engineering, quality, and project management training and consulting services. She has more than 35 years of experience in real time software engineering, quality, project management and metrics.
Linda is the author of The Certified Software Quality Engineer Handbook from ASQ Quality Press. She is a past chair of the ASQ Software Division and has served as the Division’s Program Chair, Certification Chair and Marketing Chair, and on the ASQ National Certification Board. Linda is an ASQ Fellow and has a PE in Software Engineering from the state of Texas. Linda is also a Grand Master of the Pyrotechnic Guild International.