Risky Business (part 1)

Life On The Edge

In the fast-paced world of software development, developers are constantly under stress to take their product to market at the fastest pace possible. This high-stress, high-speed approach to software development carries both rewards and risks: being early to market may give a software firm first-mover advantage and long-term domination of the arena, but it may also cause them to minimize or underestimate risks, and the consequent impact could do irreparable damage to the product and the business.

Underestimating the consequences of risks is the last thing any developer should do. Many firms invest in structured processes and state-of-the-art technologies to complete their projects within budget and time constraints. But successful developers know that the secret to the success of a project lies more in managing the risks that might unfold during the course of the project via a comprehensive risk management plan.

The impact of not managing risk can be disastrous: without a risk management plan, an organization will never have a clear picture of the risks inherent in a project, and can therefore never take corrective or preventive action to head them off. Left to themselves, these risks can become serious problems, snowballing into issues that can sometimes derail the entire project or cause significant cost and time explosions...something that's sure to make the customer (and the guy in the corner office) unhappy.

Over the course of this article, I'm going to discuss the basics of risk management, outlining the process by which project risks should be identified, analyzed, nullified and monitored. Much of this is extremely basic risk management theory, designed to give you a taste of the subject, and if you find it interesting or useful, I would strongly recommend investing in more detailed tomes on the subject.

Risking It All

Let's start with the basics. As Webster's Dictionary (http://www.webster.com/) simply puts it, a risk is "the possibility of suffering a loss".

As strange as this may sound, it's not difficult to ignore the latent causes of risks. Some of the many sources are:

• Changing user requirements
• Incomplete specifications
• Conflicting user participation
• Lack of, or incomplete, understanding between project participants
• Unsatisfactory testing of the product
• Unrepressed changes in the project scope
• Obsolescence
• Cost and schedule overruns

These causes produce uninvited and detrimental effects, such as:

• Dissatisfied team members.
• Budget and schedule explosions
• Slippages and miscommunication between project participants
• Damage to the firm's reputation

Based on this, it becomes possible to classify risks into the following categories:

• Conventional risks: These are risks encountered when an organization attempts to execute projects that are not best suited to their core competency - for example, a software development firm that specializes in banking software venturing into applications for the insurance sector.

• Erratic risks: These are risks that occur due to unexpected changes in the business situation, or in technology - for example, an application takes longer than expected to develop, and, in the interim, the technology used becomes obsolete.

• Project risks: These are risks associated with project management, and time and cost constraints - for example, a development team is halfway through a project when it discovers that some requirements have not been met, resulting in a sudden and rapid increase in expenses. Other examples of such risks involve unexpected departure of critical team members from the project, an absence of proper backup procedures, and an uncertain business environment.

• Commercial risks: These are risks related to the commercial environment - for example, improper evaluation of the target customer's requirements, which can result in a product that is too complex or expensive for consumers to handle.

Now, as cliched as it may sound, prevention is always better than cure...especially in the case of software application development, where the cure is never easy and almost always expensive. Luckily, help is at hand - software risk management now offers a structured, scientific approach to the problem of estimating risk so as to minimize its impact on your project.

The Silver Bullet

Risks vary from one project to another. A scientific and carefully planned approach towards identifying risks and making efforts to mitigate them would prove to be an asset to the organization. That's where risk management comes in.

According to SEI (http://www.sei.cmu.edu/), risk management is a practice with processes, methods, and tools for managing risks in a project. It provides a disciplined environment for proactive decision making to:

• assess continuously what could go wrong (risks);

• determine which risks are important to deal with;

• implement strategies to deal with those risks.

There are two approaches to mitigate risk:

1. The reactive approach: Here, the risk is identified once it translates into an undesirable consequence, and is only then acted upon.

2. The proactive or preventive approach: This approach adopts the "look before you leap" formula. Here, the probability of risk occurrence is analyzed and a plan defined to prevent it.

The approach that is best-suited for a particular organization depends on the complexity of the project. If the application is a small and simple one with a short life cycle, a reactive approach can be employed, as the risk of running into schedule slippage is less likely here. The proactive approach, on the other hand, suits complex or sophisticated applications with numerous inter-dependent components, as it not only helps in identifying the risks a priori but also plays an important role in the project staying within its prescribed time and budget limits.

A number of factors need to be taken into account before developing and implementing a fool-proof risk management plan: the severity of the risk, the possible damage it can cause, the time and duration of its occurrence, time required to mitigate the risk, the possibility of its recurrence, and so on. In order to identify these factors and successfully account for them, an organization should adopt the following six-step process:

• Risk identification

• Analysis

• Plan development

• Plan implementation

• Monitoring

• Audit

This process may be considered as a hierarchical series of actions, as in the following diagram:

The following sections examine each of these components in greater detail.

Surveying The Landscape

Risk identification is a primary and crucial step in risk management. Each and every weak spot of the equipment (both hardware and software) used in application development, the team, and the organization as a whole, should be scrutinized and evaluated. If this is done at the outset of the software life cycle, the possibility of mishaps leading to loss of time, financial resources and manpower can be averted.

Here are some golden rules to follow in this stage:

1. Work to a goal: Don't just design or implement a risk management plan as per textbook, make sure that there is a genuine rationale behind it. Consider the following examples:

   • If an application/product is targeted for bulk production, care should be taken to see that the organization does not fall short of resources, or else the delivery of the product might be delayed.

   • If the product is aimed at a low-income user base, measures should be taken such that the project development does not incur costs more than that allocated to it, else the end product could cost more than the targeted consumer could afford.

2. Maintain and update documents: Keep that pen rolling. Maintain documents of all the vulnerabilities and loopholes in the system, and update them as and when more risk scenarios are recorded.

3. Share information with your peers: If, in the course of planning, it is felt that a certain risk might prove to be a threat to the application, tell the people concerned about it. If nobody else has pointed it out, then seize the opportunity to share this information. Work with a broad perspective - you won't regret it.

The Number Game

Next, it's time for a little meditation. Study the risks that have been discovered so far, and evaluate them using the following steps:

1. Classify the risks: The risks that have been recorded should be categorized in terms of probability of occurrence, frequency of occurrence, impact and possibility of recurrence. Embrace a strategic method to dig into the wherewithal of the company and underscore endangered areas.

2. Formulate risk statements: Every risk has a reason for occurrence, and some impact that it would have after its occurrence. Try and devise "risk statements" that explain this relationship. For example,

   Cause: there is no backup power supply to support the system.
   Effect: there could be data loss in the event of sudden power failure.

   The above "cause and effect" risk statement suggests that the system might risk data loss if the power supply suddenly collapses. The precaution to be taken here is simple: keep a backup power supply on hand.

3. Prioritize the threats: Judge the impact of the risks, and prioritize those that are likely to cause more damage to the assets of the company. Deal with them in that order of precedence. A good approach here is to deploy a scale for acceptable levels of impact severity or occurrence frequency, such as the example below:

   Probability	Value	Description
   very low	1	1% or less
   low	2	1-5%
   medium	3	6-10%
   high	4	11-25%
   very high	5	26% and more

   The table above contains a "risk probability scale", where a numeric value is assigned to the probability of occurrence of a specific risk. By assigning values to each level of probability, it becomes possible to decide and state acceptable levels of risk occurrence. Risks with a larger value (say, 4) will be higher on the priority list than risks with a smaller value (say, 2).

   Along the same lines, you can also put together a "risk impact scale", as in the following table:

   Severity	Value	Description
   Minor	A	Partial or complete loss of information. Information is retrievable from other sources.
   Significant	B	Partial loss of information. Information can be reconstructed from other sources.
   Serious	C	Complete loss of information. Information irretrievable.
   Very Serious	D	Partial, irreversible, irretrievable loss of information.
   Catastrophic	E	Irreversible, irretrievable loss of information.

   In the above table, risks tagged as "Catastrophic" (value E) pose the highest level of danger, while risks tagged as "Minor" (value A) have the smallest impact.

4. Calculate risk factors: The probability of occurrence of a risk and its impact form the skeleton of a risk factor calculation. These factors can be estimated numerically using various formulae, as below:

   • Risk Exposure (RE) = Probability Of Occurrence x Impact

   Risk Exposure is defined as the product of the probability of occurrence of a risk and the severity of its impact on occurrence. In other words, the value of RE signifies the magnitude of loss that the organization suffers due to a risk, in terms of money or other valuable assets.

   • Risk Coverage (RC) = Total Assets x Number Of Risks x Vulnerabilities

   Risk Coverage is defined as a value that signifies the total risk associated with the vulnerable assets of a company.

   • Risk Reduction Leverage (RRL) = (RE before - RE after) / Risk Reduction Cost

   RRL is derived from RE and is defined as the amount of financial resources spent in risk reduction activities.

5. Analyze assumptions: Always probe the assumptions made concerning a project and the people associated with it. For example, if it is assumed that the developers required for the project will be hired in a week's time, make sure that they are, or else all dependent tasks will start falling behind schedule as well.

6. Perform a critical path analysis: A critical path is defined a key sequence of actions that must be taken for a project to be completed on time. Slippages in this critical path can harm the end product, by delaying associated tasks and events. For example, a budget explosion identified on the critical path must be considered a potentially serious risk, as it could lead to problems regarding the availability of funds in a later stage.

7. Scrutinize records of past projects: As history repeats itself, perform a thorough study of past projects with special attention to:

   • the risks encountered

   • the corrective action taken

   • the success rate

   • obstacles in implementing corrective action

   • the extent to which the risk management plan succeeded in achieving its goals

   This reduces work and also speeds it up, as you will quickly get an idea of what has to be done and what are the focus areas in the current project.

8. Create a risk factors chart: Sum up all the information gathered so far for each risk in a systematic and organized manner by preparing a risk factors chart. This chart should contain a tabular representation of the data you have gathered so far, with special attention to the source, priority, probability of occurrence and priority of each risk. Numerical estimates of risk exposure and coverage may also be added to this chart if available.

   This chart provides an organization with the information needed to better handle risk in future projects as well - if a similar risk scenario is detected, then it knows exactly what needs to be done to eliminate it.

   If information on all the risks discovered is maintained in this fashion, then a risk knowledge base may be created; this is helpful not only for the current project, but also for future undertakings.

That's about it for the first part of this article. In the next (and concluding) segment, I will continue this discussion with a focus on the remaining steps of the SRM process: implementation, monitoring and auditing. See you then!

Note: Examples are illustrative only, and are not meant for a production environment. Melonfire provides no warranties or support for the source code described in this article. YMMV!