Food for Thought-An e-newsletter published by Software Quality Consulting, Inc.
September 2008, Vol. 5 No. 6
Managing Software Risks - Part 2

Welcome to Food for Thought(TM), an e-newsletter from Software Quality
Consulting (http://www.swqual.com/index.html?Intro). I've created free
subscriptions for my valued business contacts. If you find this newsletter
informative, I encourage you to continue reading. Feel free to pass this
newsletter along to colleagues by clicking this Forward Email link
(http://ui.constantcontact.com/roving/sa/fp.jsp?plat=i&p=f&m=sctz69n6). If
you�ve received this newsletter from a colleague and would like to subscribe,
please click this Enter New Subscription link (http://www.swqual.com/newsletter/
Subscribe.htm?Newsletter). If you don't wish to receive this newsletter, click
the SafeUnSubscribe(TM) link at the bottom of this newsletter, and you won�t be 
bothered again.

Your continued feedback on this newsletter is most welcome. Please send 
your comments and suggestions to [email protected].

--------------------------------------------------------------------------------

*** In This Issue ***

In This Months� Topic, I continue the discussion on Software Risk 
Management...

Regular features to look for each month are:

- Monthly Morsels
  Hints, tips, techniques and reference info related to this month�s topic 

- Calendar
  Conferences, workshops, and meetings of interest to software engineers, 
  QA engineers and anyone interested in software development 

--------------------------------------------------------------------------------

*** This Month�s Topic ***

MANAGING SOFTWARE RISKS - PART 2 

  For a young project manager, starting work on a new project can be 
  exciting. It represents an opportunity to show them what you can do! The 
  euphoria associated with starting new projects often doesn�t last very 
  long (a week or two is about average). Soon, reality sets in and you 
  realize that the �aggressive schedule� you were handed is not even 
  remotely achievable, the 3rd party software the project team is 
  depending on is way behind schedule, and you don�t have the requirements 
  defined or the resources you�ll need. Talk about being bummed out... 
  
The software industry is known for many things - incredible technology, 
cowboys, ever-changing jargon, and what has been referred to as 
testosterone-driven decision-making. No matter how ridiculous the schedule 
is, no matter that there are several people on the project who all have 
the same initials (TBH - To Be Hired), no matter that product marketing 
hasn�t figured out what customers want..., we are expected to carry on as 
if everything will magically fall into place. When we are young and 
inexperienced, we naively believe that everything will fall into place. It 
is only through failure that we eventually learn that no amount of 
testosterone can change reality.

As we get older and hopefully wiser, we become more skeptical and more 
risk averse. This is why, in my opinion, the best project managers tend to 
be older and more mature. And, that�s why DeMarco and Lister [1] refer to 
Risk Management as �project management for grown-ups.� Only inexperienced, 
naive project managers act as if risks will not negatively affect their 
projects. Their more experienced peers know better. In fact:

  �Software has long been regarded as one of the most risk-prone of all 
  engineering activities. Risks such as schedule slips and cost overruns 
  tend to occur on more than 50% of all large systems. Even more severe 
  risks, such as cancellation of the project prior to completion or 
  serious quality deficiencies are not uncommon.� [2]

In my June newsletter (http://www.swqual.com/newsletter/vol5/no5/vol5no5.html),
I began a discussion on Managing Software Risks by identifying several different
types of risk and introducing the notion of proactive risk management. In this
month�s issue, we continue this discussion and look at some examples of
techniques to manage different types of software risks.

  Note to readers: For those of you who work in regulated industries such 
  as medical devices, NASA, nuclear power, avionics, etc., you are 
  probably very familiar with rigorous risk management processes. The 
  process described here is intended for unregulated industries and as a 
  result, is not as rigorous. However, it uses some of the same principles 
  routinely applied in regulated industries.

Risk is something we deal with every day. In fact, it�s been drilled into 
our heads that projects with little or no risk are not worth doing. What 
this means is that every project we undertake probably has a considerable 
amount of risk.

On some software projects, we may acknowledge that risks are present but 
we fail to deal with them in a proactive manner. As a result, many 
software projects are negatively affected by known risks that were simply 
ignored. On other software projects, we may not even acknowledge that 
there are risks and proceed under the naive assumption that somehow, 
things will work themselves out. What a way to run a business!

WHAT IS RISK MANAGEMENT?

- Risk is defined as a possible future event that will lead to an 
  undesirable outcome. [1] 

- Risk management is the process of thinking out corrective actions before 
  a problem occurs, while it�s still an abstraction. The opposite of risk 
  management is crisis management, trying to figure out what to do after 
  it happens. [1] 

Risk management is a proactive process that attempts to identify as many 
potential risks as possible, assess the potential impact of each of these 
risks, rank them in priority order, and then manage those that are the 
most critical.

Risk management is a set of planned actions that can effectively reduce 
the impact of risks on most software projects. Some training in basic risk 
management techniques is necessary in order for these techniques to be 
applied effectively.

  Learn more about risk management for embedded systems...
  (http://www.swqual.com/training/risk2.html)

  Learn more about risk management training for project managers...
  (http://www.construx.com/Page.aspx?nid=84&id=34)

Effective risk management has become increasingly important, given the 
exponential increase in software complexity as illustrated below. [3] The 
more complex your software is, the more critical it is that you have an 
effective risk management process. 
  
CULTURAL BARRIERS

In far too many organizations, Management makes it more difficult, if not 
impossible, to manage risk. DeMarco and Lister [1] identify cultural 
barriers to risk awareness present in these organizations. These barriers 
are often in the form of �unwritten rules� that make it difficult to even 
discuss potential risks. For example, have you ever heard your boss say:



- �Don�t be a negative thinker.� 
- �Don�t raise problems unless you have a solution.� 
- �Don�t raise a problem unless you can prove it is a problem!� 
- �Don�t raise a problem unless you are willing to take responsibility for
  the solution.� 

If you have heard these words, then it�s likely that risks are being swept 
under the proverbial rug. People in these organizations who try to 
identify risks may be accused of being a whiner, not being a team player, 
or of negative thinking. Ironically, it is precisely this negative 
thinking that can often prevent an organization from experiencing costly 
and embarrassing failures. In some organizations:

  �The very term, risk, often has negative connotations and the consequent 
  cultural pressure to deny its existence thus exposing the project to 
  unwanted surprises leading to difficulties and failures.� [4]

Clearly, a prerequisite for effective risk management is a culture where 
open and frank discussions of risk are encouraged.

DEALING WITH RISK

DeMarco and Lister [1] identify four ways to deal with risk:

- You can avoid risk 

  You avoid risk when you decide not to do a project or a part of a 
  project that has risk. You may decide to cancel a project or remove 
  risky features.

- You can contain risk 

  Containing risks means you plan to deal with them when they occur. You 
  may set aside additional time and resources to deal with an internal 
  risk, for example.

- You can mitigate risk 

  Mitigating risk means that you take proactive steps to minimize the 
  impact of a risk, should it occur.

- You can evade risk 

  Evading risk means you take no action at all - other than hoping that 
  the risk doesn�t materialize. Of all ways of dealing with risk, this is 
  clearly the least expensive, but also the least effective. 

A SIMPLE RISK MANAGEMENT PROCESS

For those of you who�ve never done this before, the most fundamental risk 
management process includes these activities:

- Identify risks 

- Assess and prioritize risks 

- Monitor and control risks 

In order to realize the most benefit, the best time to start worrying 
about risk is obviously at the beginning of a project. Like most things 
worth doing, it�s never too late to start, and you can apply this process 
to projects already underway.

  Identify Risks

  The effectiveness of any risk management process is based in large part 
  on how good a job you do at identifying risks. Being able to spot risks 
  is a skill that can be learned from experience. If you have never done 
  this before, the first place to look is the last project. Conduct a 
  project retrospective (http://www.swqual.com/newsletter/vol2/no6/vol2no6.html)   
  and gather information from problems identified during the retrospective. It�s 
  likely these problems were caused by risks that were ignored. To find out, use 
  root cause analysis (http://www.swqual.com/newsletter/vol2/no5/vol2no5.html) 
  to identify the real root cause of the problem.

    Training in Project Retrospectives...
    (http://www.swqual.com/training/retrospectives.html)

    Training in Root Cause Analysis...
    (http://www.swqual.com/training/root.html)

  The next place to look is the project team. Create an environment where 
  risks can be openly discussed and debated. Ensure that everyone on the 
  team has an opportunity to contribute in a manner that is safe and 
  non-threatening. The people doing the work usually know what the biggest 
  risks are since they are likely to be directly affected by them.

  Lastly, look at the taxonomy of software risks (http://www.swqual.com/
  newsletter/vol5/no6/Taxonomy.pdf) assembled by the Software 
  Engineering Institute. [4] This is a list of potential risks that you 
  can review and then determine if any of these risks apply to your 
  project.

  In the SEI taxonomy, risks are grouped into three categories: Product 
  Engineering, Development Environment, and Program Constraints. In each 
  category, there are several risk areas and for each risk area, there are 
  questions that you can ask about that area in order to assess whether or 
  not it is likely this risk is present on your project.

  For example, one of the areas of risk identified is Schedule. Here is a 
  sample of the questions you can ask in order to determine what risks, if 
  any, are present...

  Schedule - Is the schedule inadequate or unstable?

  - Has the schedule been stable? 

  - Is the schedule realistic? 
    - (If yes) Is the estimation method based on historical data? 
    - (If yes) Has the method worked well in the past? 

  - Is there anything for which adequate scheduling was not planned? 

    - Analysis and studies
    - QA 
    - Training 
    - Maintenance courses and training 
    - Capital equipment 
    - Deliverable development system

  - Are there external dependencies likely to impact the schedule? 

  Read more about the SEI Taxonomy of Software Risks...
  (http://www.swqual.com/newsletter/vol5/no6/SEIRiskReport.pdf)
  
  Once you have done a thorough job of identifying risks, the next task is 
  prioritizing them. 

  Assess and Prioritize Risks

  Assessing and prioritizing risks involves assessing the likelihood that 
  a risk will occur and understanding the potential impact to the project 
  if the risk does occur. The purpose of the assessment is to:

  - identify early warning signals - signs that give you time to act 
    proactively rather than reactively 

  - assess likelihood - how likely is it this risk will occur 

  - assess impact - to the project should the risk occur 

  - identify a Plan B - a mitigation strategy if the risk does occur 

  There have been many schemes for doing this assessment, and 
  if you are doing this for the first time, I recommend using a very 
  simple tool...

    An example of a simple risk assessment tool...
    (http://www.swqual.com/newsletter/vol5/no6/tool.pdf)

  Once the assessment is completed and the risks are prioritized, the next 
  task is to monitor and control those that do occur...

  Monitor and Control Risks

  Monitoring and controlling risks means that you are constantly watching 
  the Early Warning Signals for the highest priority risks. It also means 
  that you have a Plan B in place for each of these risks. Should you need 
  to use a Plan B, you have to make sure that it is effective in reducing 
  the impact to an acceptable level. If it�s not, you need to find a more 
  effective mitigation.

  It�s at this stage of the process where you will reap the fruits of your 
  hard work. Risks will occur, but if you have done your job, you will 
  have early warning and you will be prepared to deal with them. In many 
  cases, the Plan B you have will work and the project impact will be 
  minimal. Remember the Boy Scout motto: Be Prepared! That�s what risk 
  management is all about. - being prepared for the inevitable risks that 
  do occur.

SUMMARY

Proactive risk management is a critical skill for successful 
organizations. Being able to anticipate and deal with risk is essential to 
avoid disaster.

And the disasters are still happening. A very recent article [5] on IT 
software project failures identifies several reasons that IT software 
projects were cancelled. Each of the reasons in the list below could be a 
potential risk on your project.

Remember that the biggest risk on any software project is n ot knowing 
what the risks are!

�Til next time...

--------------------------------------------------------------------------------

*** Monthly Morsels ***

Every month in this space you�ll find additional information related to 
this month�s topic.

- References 

  1 Lister, T. and DeMarco, T., Waltzing With Bears: Managing Risk on 
    Software Projects, Dorset House, 2003. 

  2 Capers Jones, Assessment and Control of Software Risks, Prentice-Hall, 
    1994 

  3 Higuera, R. P. and Haimes, Y., �Software Risk Management�, Technical 
    Report CMU/SEI-96-TR-012, ESC-TR-96-012, June 1996 

  4 Carr, M., et. al., �Taxonomy-Based Risk Identification�, Technical 
    Report CMU/SEI-93-TR-6 ESC-TR-93-183, June 1993 

  5 El Emam, K. and Koru, A., �A Replicated Survey of IT Software Project 
    Failures�, IEEE Software, Sept-Oct 2008

- Additional Resources 

  Boehm, B, Software Risk Management, IEEE Computer Society Press, 1989

  Jones, C., Assessment and Control of Software Risks, Prentice-Hall, 1994 

  Grey, Practical Risk Assessment for Project Management, Wiley, 1995

  Charette, Robert N., Application Strategies for Risk Analysis & 
  Management, McGraw-Hill, 1990 

  Wiegers, K., �Know Your Enemy: Software Risk Management�, Software 
  Development , October 1998

  Fairley, R., �Software Risk Management Glossary�, IEEE Software, 
  May-June 2005.

--------------------------------------------------------------------------------

*** Calendar ***

Every month you�ll find news here about local and national events that 
are of interest to the software community...

- Software Quality Calendar 

  There are many organizations that sponsor monthly meetings, workshops, 
  and conferences of interest to software professionals. Find out what�s 
  happening...
  (http://www.swqual.com/links/upcoming.html)

- Workshops Offered by Software Quality Consulting 

  Software Quality Consulting offers workshops in many topics related to 
  software process improvement. Get more info...
  (http://www.swqual.com/seminars/courses.html)

--------------------------------------------------------------------------------

*** About SQC ***

Software Quality Consulting provides consulting, training, and auditing 
services tailored to meet the specific needs of clients. We help clients 
fine-tune their software development processes and improve the quality of 
their software products. The overall goal is to help clients achieve 
Predictable Software Development(TM) � so that organizations can consistently 
deliver quality software with promised features in the promised timeframe. 

To learn more about how we can help your organization, visit our web site
(http://www.swqual.com/index.html?AboutSQC) or send us an email
([email protected]).

--------------------------------------------------------------------------------

I hope this newsletter has been informative and helpful. Your comments and 
feedback are most welcome. Send me your feedback...

Thanks,

Steve Rakitin
[email protected]


Food for Thought, Predictable Software Development, Act Like a Customer,
and ALAC are trademarks of Software Quality Consulting, Inc.
Copyright 2008. Software Quality Consulting, Inc. All rights reserved.
Graphic design by Sage Studio