Risky Business (part 2)

When The Only Constant Is Change

In the first part of this article, I introduced you to the science of software risk management, explaining how an effective risk management plan can go a long way towards ensuring the success of your software project. I also intriduced you to the six phases of software risk management, and discussed the first three - risk identification, analysis and plan development - in detail.

In this second (and concluding) article, I will continue this discussion with a focus on the phases of plan implementation, monitoring and audit. And with the theoretical discussion done with, I’ll also bring all this into the real world, with a case study and a flowchart that you can use in your next project.

Plan B

Risk planning is all about penning down strategies to take corrective action against risks. The risk factors chart created in the previous phase serves as an input to this function.

When planning for risk, the following steps come in handy:

1. Prepare a containment plan and a contingency plan: A containment plan allows you to decide the right time of taking action against the risk to both reduce the probability of its occurrence, and the severity of its impact should it occur. A contingency plan specifies the action to be taken in the event that a problem occurs, and is initiated on the basis of specific events known as trigger values.

2. Devise clear security policies: It is essential to evaluate the organization’s security policies as they play a crucial role in disaster recovery. Audit the policies from time to time to ensure that they are clear of loopholes.

3. Deploy an Incident Response Team: Clearly assign roles and responsibilities to a team of able personnel who are calm in the face of emergencies. Evaluate their knowledge and confirm their ability to be flexible and respond efficiently to crises. It is essential that the entire team have a sound understanding of the potential risks and threats to the product under development.

4. Create a master risk assessment plan: This plan is an extension of the risk factors chart and contains, in addition to information on risks and their impact, the containment and contingency measures to be initiated for each. It enables the developers/managers to tackle the risk better, as they are now aware of the various risks in the project, and also how to deal with them. This plan also serves as a knowledge repository of risks for future reference.

Getting Down To Business

There are a few important things to be kept in mind while implementing the carefully devised risk plan:

• Keep a close vigil on all major milestones and deliverables during the course of the development process.

• Focus on reducing the risks early on in the development phases.

• Try to minimize the errors in estimation, especially in budget and time estimation.

• Explore more than one approach to solving problems.

• Eliminate repetitive risks.

• Identify dependencies between the risks.

• Protect classified information

• Allow only those personnel with specific security permissions to access the system.

In the implementation phase, the risk plan should be constantly assessed and steps taken to reduce or eliminate errors or oversights. This includes:

• Revisiting the project estimates in order to encompass the added effort required to carry out the risk reduction activities, should the risk turn into a serious problem.

• Making appropriate alterations in the budget so as to cover the expenses to be incurred in performing the risk reduction activities.

• Changing the scope of the project, team members and technology used if necessary.

Big Brother Is Watching

The monitoring phase involves tracking the progress of the implementation of the risk reduction plan, so as to identify and resolve potential problems before they assume serious proportions. In order to accomplish this, a manager needs to:

• watch out for indicators of a risk scenario;

• compare the indicators to the trigger values;

• alert all the people concerned and take corrective action;

• record the results of the corrective action taken against the risks (this includes accumulating information, compiling it in a suitable format, analyzing it, measuring the risk factors recorded, and keeping track of the trigger values);

• update the Master Risk Assessment Plan with this information for future references.

The tracking process could result in new risks being identified, which, in turn, should result in an update of the risk list and of the original software development plan.

Time After Time

The auditing phase involves taking measures to enhance the risk management process, on a periodic basis. This involves:

• ensuring that risk data is available to the project and business management teams;

• recognizing the fact that risk attributes - probability, impact and frequency - are subject to change over a period of time;

• responding promptly to trigger values;

• transferring risks to other groups;

• selecting what approach has the best return on investment;

• conducting regular project reviews;

• comparing results of current reviews with past risk records to ensure that timely corrective action has been taken;

• reassessing risks at key milestones;

• performing periodic review of the risk items;

It is imperative that the risk management system be updated on a constant basis in the face of emerging technologies. Additionally, a strict vigil should be maintained to ensure that the acceptable tolerance levels established for the various risk factors do not exceed their limits.

Banking On It

Now that you know a little bit more about risk management theory, let’s see how it plays out in the real world. Consider the following case study, which discusses real-life implementation of risk management in the context of an industry which constantly faces emerging technologies, changing market scenarios and technological advances in financial transactions: the banking sector.

Objective: To focus the bank’s resources on:

• Enhancing the supervisory risk management processes in a bank.
• Evaluating the security of the bank.

Ground work:

• Continuous assessment of the bank workflow.
• Detailed review of the information available about the bank.
• Comparison of surveillance reports with other banks to highlight the strengths and vulnerabilities of the bank.
• Understanding of the operational environment of the bank, the risks to which it is open, and the tools and techniques available to measure and mitigate them.
• Study of the infrastructure established to implement risk reduction activities. This could be either a specialist risk engine or a treasury and risk management system.
• Study of the most recent audit, loan review, and other compliance functions.

Identify loopholes:

• Investigate the efficiency of the studies performed.
• Perform test transactions to evaluate the quality of the bank’s methodologies and processes.
• Use tools like intrusion detection software to detect pitfalls in the bank network.
• Detect illegal entries into the system.
• Study the banking environment, the staff and its economic condition.

Establish the requirements for an appropriate Risk Management System:

• It should have all equipment necessary for reporting functions.
• It should facilitate communication of risk and return targets, and guidelines to marketing personnel.
• It should define benchmarks (internal or external) for the same and make available tools needed to maintain the benchmarks.
• It should ensure that good follow-up and feedback mechanisms are in place to enable management to compare the results before and after implementing the risk reduction activities.
• It should provide infrastructure to analyze risks and their position in the system, and to present this data in an understandable manner. It should include tools to measure risk factors and determine the causes of risk exposure.
• It should include components for monitoring, controlling and reporting limits that have been exceeded.

Classify and prioritize risks on the following basis:

• Probability of occurrence
• Severity of impact
• Frequency of occurrence

Take corrective action against each risk:

• Interest rate risk: Use duration-based measures to compare the relative risk of two different portfolios irrespective of their size and basis-point value to compare the impact of rate changes.
• Exchange rate risk: Monitor the changes taking place in foreign exchange repositories, and calculate currency exchange rates in a consistent manner.
• Liquidity risk: Impose controls on the foreign reserves in liquid assets and how are distributed between different sectors. Record the bank’s categorization of assets and make available this information to those concerned.
• Credit risk: Set limits on the various credit exposures.

Apply techniques such as:

• Monte Carlo simulation: This method combines historic data with assumptions made by the users and randomly generates values for uncertain variables over and over to simulate the behaviour of the model in different situations.
• Stress tests: Here, extreme cases are considered and applied to the existing portfolio to calculate the maximum loss to the bank.
• Historical simulations: Here, historical data is applied to determine the maximum loss to the bank.

Practical Magic

So that’s it for the theory - now, how about putting it in practice? The following flowchart should get you started with building a risk management plan for your next project.

Endgame

With its constantly changing user requirements and the need for quality deliverables at the speed of light, the software industry is living on the edge. The number of risks associated with a project increase with its complexity. Risk management techniques help to reduce the cost associated with a given software project.

In the absence of a sound risk management plan, the magnitude of loss to the organization could range from miniscule to monumental. Uncertainties are always present, and they take the form of risks that can delay or damage a software project. Uncertainties cannot be predicted, nor can they be avoided with infallibility; they can, however, be analyzed and quantified, and strategies devised to combat them.

The recommended approach, thus, is to consider a risk as an opportunity to avert perils. By adopting a positive approach, having a shared product vision, and working with the sole aim of combating the threats to the project, an organization can achieve success in its goal of minimal business disruption.

If you’d like to read more about risk management, you should consider visiting the following links:

A guide to risk management concepts and principles by the Software Engineering Institute at Carnegie Mellon University, at http://www.sei.cmu.edu/programs/sepm/risk/

An informative article on risk management processes by Barry Boehm, at http://www.itq.ch/pdf/RM__ITProjekteV211.pdf

A discussion of software cost estimation techniques, at http://www.sqmmagazine.com/issues/2003-01/costest.html

Risk management for IT, at http://www.itq.ch/pdf/RM__ITProjekteV211.pdf

See you soon!

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!