Risk Management and Control

 

Key words: risk, risk management, risk assessment and risk control, risk identification, risk management planning, risk resolution, risk monitoring

 

Abstract

Any large scale projects involve certain risks and that is true of software projects.  Risk management is an emerging area that aims to address the problem of identifying and managing the risks associated with the software projects.

The basic motivation of having risk management is to avoid disasters of heavy losses.  The current interest in risk management is due to the fact that the history of software development projects is full of major and minor failures.  A large percentage of projects have run considerably over budget and behind schedule, and many of them have been abandoned midway.  It is now argued that many of these failures were due to the fact that the risks were not identified and managed properly.

Risk management is an important area, particularly for large projects.  Like any management activity, proper planning of that activity is central to success.

Risk Management Overview

Risk is defined as an exposure to the chance of injury or loss. That is, risk implies that there is a possibility that something negative may happen.  In the context of software projects, negative implies that there is an adverse effect on cost, quality, or schedule.  Risk management is the area that tries to ensure that the impact of risks on cost, quality, and schedule is minimal. 

Like configuration management which minimizes the impact of change, risk management minimizes the impact of risks.

Risk management can be considered as dealing with the possibility and actual occurrence of those events that are not “regular” or commonly expected.  The commonly expected events, such as people going on leave, resource unavailability or some requirement changing are handled by normal project management.  So, in a sense, risk management begins where normal project management ends. 

Most projects have risk.  The idea of risk management is to minimize the possibility of risks materializing, if possible, or to minimize the effect of risk actually materializing.

It should be clear that risk management has to deal with identifying the undesirable events that can occur, the probability of their occurring, and the loss if an undesirable event does occur.  Once this is known, strategies can be formulated for either reducing the probability of risk materializing or reducing the effect of risk materializing (risk mitigation).  So the risk management revolves around risk assessment and risk control.

 

Risk Assessment

Risk assessment is an activity that must be undertaken during project planning.  This involves identifying the risks, analyzing them, and prioritizing them on the basis of the analysis.  The major planning activity in risk management is assessment and consequent planning for risk control.  Due to the nature of a software project, uncertainties are most near the beginning of the project.  As the project nears its end, risks can be assessed more precisely.  Due to this, although risk assessment should be done throughout the project, it is most needed in the starting phases of the project.  In addition, early identifying risk provides the management with a lot of time to effectively handle the risks. 

At a very high level, the software risks can be broadly divided into three categories:

  • Cost risk
  • Performance risk
  • Schedule risk

Cost risk is the degree of uncertainty associated with budgets and outlays for the project and its impact on the project.  Performance risk is the possibility that the system will be unable to deliver all or some of the anticipated benefits or will not perform according to the requirements.  Here performance includes quality.  Schedule risk is the degree of uncertainty associated with the project schedule or the ability of the project to achieve the specified milestones.

The goal of risk assessment is to prioritize the risks so that risk management can focus attention and resources on the more risky items.  Risk identification is the first step in risk assessment, which identified all the different risks for a particular project.  These risks are project-dependent, and their identification is clearly necessary before any risk management can be done for the project.

Some list of risks specific to the projects and solutions:

  1. Personnel Shortfall: Staffing with top talent, Job matching, Teambuilding, Key-Personnel agreement, Training, Rescheduling Key People.
  2. Unrealistic Schedules and Budgets: Detailed multisource cost and schedule estimation, Design to cost, Incremental development, Software reuse, Requirements scrubbing.
  3. Developing the wrong software functions: Organization Analysis, Mission Analysis, User Surveys, Prototyping, early user manuals.
  4. Developing the wrong user interface: Prototyping, Scenarios, Task Analysis, and User characterization.
  5. Gold Plating: Requirements scrubbing, Prototyping, Cost-Benefit analysis, Design to cost.
  6. Continuing Stream of requirements changes: High change threshold, Information hiding, Incremental development
  7. Shortfalls in externally furnished components: Benchmarking, Inspections, Reference checking, Compatibility Analysis.
  8. Shortfalls in externally performed tasks: Reference checking, Pre-award audits, Award-fee contracts, Competitive design or Prototyping, Teambuilding.
  9. Real-Time performance shortfalls: Simulation, Benchmarking, Modeling, Prototyping, Instrumentation, Tuning.
  10. Straining Computer Science Capabilities: Technical Analysis, Cost-Benefit Analysis, Prototyping, Reference checking.

The top-ranked risk item is personnel shortfalls.  This involves just having fewer people than necessary or not having people with specific skills that a project might require.  Some of the ways to manage this risk is to get the top talent possible and to match the needs of the project with the skills of the available personnel.  Adequate trainings along with having some key personnel for critical areas of the project will also reduce this risk.

The next item, unrealistic schedules and budgets, happens very frequently due to business and other reasons.  It is very common that high-level management imposes a schedule for a software project that is not based on the characteristics of the project and is unrealistic.  This risk applies to all projects.  Project-specific risks in cost and schedule occur due to underestimating the value of some of the cost drivers.  Recall the cost models like COCOMO, Function Point estimates.   Even the size estimate is correct, by incorrectly estimating the value of the cost drivers; the project runs the risk of going over budget and falling behind schedule.  The cost and schedule risks can be approximated by estimating the maximum value of different cost drivers along with the probability of occurrence and then estimating the possible cost and schedule overruns.

The next few items are related to requirements.  Projects run the risk of developing the wrong software if the requirement analysis is not done properly and if development begins too early.  Similarly, often improper user interface may be developed.  This requires extensive rework of the user interface later or the software benefits are not obtained because users are reluctant to use it.  Gold plating refers to adding features in the software that are only marginally useful.  This adds unnecessary risk to the project because gold plating consumes resources and time with little return.  Some requirement changes are to be expected in any project, but some time frequent changes are requested, which is often a reflection of the fact that the client has not yet understood or settled on its own requirements.  The effect of requirement changes is substantial in terms of cost, especially if the changes occur when the project has progressed to later phases.  Performance shortfalls are critical in real-time systems and poor performance can mean the failure of the project.

If a project depends on externally available components – either to be provided by the client or to be procured as an off-the shelf component or dependency with other services – the project runs some risks.  The project might be delayed if the external component is not available on time.  The project would also suffer if the quality of the external component is poor or if the component turns out to be incompatible with the other project components or with the environment in which the software is developed or is to operate.  If a project relies on technology that is not well developed, it may fail.  This is a risk due to straining the computer science capabilities.

Using the checklist of the top-10 risk items is one way to identify risks.  This approach is likely to suffice in many projects.  The other methods are decision driver analysis, assumption analysis and decomposition.  Decision driver analysis involves questioning and analyzing all the major decisions taken for the project.  If a decision has been driven by factors other than technical and management reasons, it is likely to be a source of risk in the project.  Such decisions may driven by politics, marketing, or the desire for short-term gain.  Optimistic assumptions made about the project also are a source of risk.  Some such optimistic assumptions are that nothing will go wrong in the project, no personnel will quit during the project, people will put in extra hours if required, and all external components (hardware and software) will be delivered on time.  Identifying such assumptions will point out the source of risks.  An effective method for identifying these hidden assumptions is comparing them with past experience.  Decomposition implies breaking a large project into clearly defined parts and then analyzing them.  Many software systems have the phenomenon that 20% of the modules cause 80% of the project problems.  Decomposition will help identify these modules.

 

 

Risk Control

Whereas risk assessment is a passive activity identifying the risks and their impacts, risk control comprises active measures that are taken by project management to minimize the impact of risks.  Though risk assessment is primarily done during project planning as risk assessment in early stages is most important, like cost and schedule estimation, the assessment should be evaluated and changed, if needed, throughout the project.

Like any active task (e.g., configuration management, development), risk control starts with risk management planning.  Plans are developed for each identified risk that needs to be controlled.  Many risks might be combined together for the purposes of planning, if they require similar treatment.  This activity, like other planning activities, is done during the project initiation phase.  The risk management plan has five components. 

These are

i)              Why the risk is important and why it should be managed

ii)             What should be delivered regarding risk management and when

iii)            Who is responsible for performing the different risk management activities,

iv)           How will the risk be abated or the approach be taken, and

v)            How many resources are needed?

The main focus of risk management planning is to enumerate the risks to be controlled (based on the risk assessment) and specify how to deal with a risk.  One obvious strategy is risk avoidance, which entails taking actions that will avoid the risk altogether.

Another obvious strategy is risk reduction; if the risk cannot be avoided, perhaps the probability of the risk materializing can be reduced or the loss due to the risk materializing can be reduced.

The actual elimination or reduction is done in the risk resolution step.  Risk resolution is essentially implementation of the risk management plan.  For example, if the risk avoidance is to be user, the activities that will avoid the risk have to be implemented.  Similarly, in the plan it might have been decided that the risk can be reduced by prototyping.  Then prototyping is done in the risk resolution step and necessary information obtained to reduce the risk.  Incidentally, prototyping is very important technique for reducing risks associated with requirements or reducing risks of the type “perhaps this cannot be done?”

Risk monitoring is the activity of monitoring the status of various risks and their control activities.  Like project monitoring, it is performed through the entire duration of the project.  Like many monitoring activities, a checklist is useful for monitoring.  While monitoring risks, like with monitoring costs and schedules, reassessments might need to be performed, if the real situation differs substantially from the situation predicted earlier based on assessment and planning.

 

References

Continuous Risk Management Guidebook, Pittsburgh, PA:Software Engineering Institute

Barry W. Boehm. Tutorial: Software Risk Management, IEEE Computer Society Press

I am Vamsi Mohan, A certified rational architect and solution designer. I am having good experience in SDLC and Project Management.

You can reach me : vamsi.technology@yahoo.com for any information or cooperation in execution of projects.

Article Source:http://www.articlesbase.com/project-management-articles/risk-management-and-control-1296838.html