EDITING BOARD
RO
EN
×
▼ BROWSE ISSUES ▼
Issue 24

The Risk of Not Having Risks

Ramona Muntean
Measurements & Best Practices
@ISDC
MANAGEMENT

Risk Management is a very widely used term in today"s world of software engineering. Almost every project suffers from threats which can seriously affect its cost, schedule or quality in a negative way. According to an IBM study only 40% of projects meet schedule, budget and quality goals. Other analyses conclude that "between 65 and 85% of IT projects fail to meet their objectives, and also run significantly late or cost far more than planned."

In order to avoid critical deviations to project"s cost, schedules and quality it is important for every Project Manager and not only, to acknowledge that threats exist, that things could go wrong, and to be prepared to act either by reducing the probability of the potential threats or by reducing the loss if these will materialize.

What is a risk?

A risk represents a potential problem, an uncertain event that, if it occurs, will have an effect on the project objectives.

The effect of the event could be either beneficial or damaging. When approaching Risk Management, which covers both positive and negative effects of an uncertain event, the Project Manager has to differentiate between Threats and Opportunities. In the current article we will be focusing only on risks that are threatening project objectives (have a negative impact on the project"s success goals).

Any risk involves three attributes which need to be quantified:

  • Probability for the risk to happen: usually expressed in percentages or by categories: Low, Medium, High
  • Impact: the loss that will occur if the risk becomes a reality, can be expressed by categories: Low, Medium, High
  • Proximity is expressed in temporal terms (the most probably date the event can occur) or categories (e.g. imminent, short term, long term) considering the interval from the moment the risk is identified until the moment it is most likely to have an impact on the project"s objectives.

Difference between risk and issue

  • Risk is an event of the future; if it occurs it may impact project objectives in a negative manner. The key point is that the risk event has not yet happened and it might not happen.
  • An issue is a result of an event that is happening right now or has already happened. An issue has a negative impact on the project. An issue is not a risk but a risk becomes an issue when we no longer can avoid the impact.

There are 4 types of risks:

  • Project risks - the ones that are threatening the project plan; these are mostly linked to potential problems related to budgets, schedules, staffing, resources, requirements, customer;
  • Technical risks - the ones that are threatening the quality and timeliness of the software to be produced; these are mostly linked to potential problems related to design, implementation, interface, verification, maintenance. Specification ambiguity, technical uncertainty, technical obsolescence, and "leading-edge" technology are risk factors from this category.
  • Product risks - the ones that are related to the potential consequences of issues within the product (e.g. security risks). These risks may be related to misuse of the product or errors within the product which affect the outcome through calculation or logic errors.
  • Business risks - the ones that are threatening the viability / success of the project; these are mostly linked to potential problems related to market, company"s strategy, sales force, management.

If we go further on and put all these information together we dive in the Risk Management practices.

Risk Management activities are Project Manager"s accountability, everyone"s responsibility and should be performed in a proactive way. The objective of Risk Management is to give the Project Manager the necessary knowledge and instruments to be able to face any events that might have an impact on the project"s objectives. Many problems that arise in software development were first known as risks by someone in the project staff. Caught in time, risks can be avoided, negated or have their impacts reduced. Proactively managing risks implies determining a strategy that will prevent the risk from becoming a problem or will limit its impact if it does. The strategy to manage risks typically includes reducing the negative effect or probability of the threat, transferring the threat to another party, avoiding the threat or even accepting it.

Risk Management paradigm

During the Project Start-up phase and then continuously during the entire project"s lifecycle, risks need to be identified, analysed and furthermore adequate measures need to be planned, evaluated and implemented when it might be the case. In carrying out all of these steps the Project Manager is assisted by appropriate project stakeholders.

Identify

We start identifying risks with the acknowledgement of 3 categories of risks:

  • Known risks - can be uncovered after careful evaluation of the project plan, the business and technical environment in which the project is being developed, and other reliable information sources;
  • Predictable risks - extrapolated from past project experience (e.g. personnel attrition rate, communication with the customer);
  • Unpredictable risks - occur, but difficult to identify in advance.

Many of the known and predictable risks may be identified in the start-up phase of the project, some of them even in the bid phase. There are a number of tools and ways to help the Project Manager efficiently perform this activity. A sample risk checklist or a questionnaire where the answer will reveal risks can be used. Software Engineering Institute (SEI) developed a software risk taxonomy and a taxonomy based questionnaire (TBQ) which provide a basis for identifying, organizing and studying various aspects of software risks.

However, risks exist and emerge throughout the entire lifecycle of a project; that"s why risks must be identified continuously, not only in the start-up phase. Risk identification needs to be part of the project"s routine. It is every team member"s professional and moral responsibility to report risks as soon as they are identified, even if they seem to have a low importance or sound weird.

Once identified, the risks should be captured and communicated or shared through a risk log or other tool that allows risks registration.

Analyse

Once the risk has been identified, the Project Manager (or someone acting as risk manager for the project) will assess its probability, impact and proximity. In some cases this step might require an impact analysis which will consider all the objectives that might be affected by the possible occurrence of the risk. Ideally, the Project Manager should also determine the Risk value - the cost of the problem if the risk will occur. Risk value = probability x cost to the project if the risk occurs. In the absence of figures relative classification is still useful.

The Project Manager has to make sure that responsibility for all important risks is explicitly assigned to a Risk Owner. The risk owner is the person with the best profile to manage the specific risk during its lifecycle in the project, this may be someone who is not directly involved in the project, such as line manager, sales, infrastructure, etc.

Plan

Once the probability, impact and proximity for a risk have been assessed, the Project Manager will work with the relevant stakeholders to define and plan suitable measure(s) to manage the risk. The measures a Project Manager can consider when responding to a risk are:

  1. Reduce/Mitigate: Reduces the Impact and/or Probability of the Risk occurring. It is the primary strategy, a proactive one that handles the risks in a controlled and effective manner. It is most of the time achieved through a mitigation that includes also a contingency plan.
  2. Avoid: Eliminates the risk completely. This means not performing an activity that could carry risk. Avoiding risks also means losing the potential gain that would have been obtained if the risk was accepted.
  3. Transfer: Transfers or shares the impact of the risk with a third party (e.g. insurance company).
  4. Fall-back, also known as contingency: Provides an alternative for the situation when the risk will materialize.
  5. Accept: No response will be implemented.

When dealing with a set of related risks the Project Manager should consider the consequences of any action: eliminating or reducing a risk may introduce others.

The measures defined to respond to a risk bring additional costs to the project. Mitigations are effective when the gain obtained by mitigating the risk exceeds the potential loss that would be recorded if the risk was to materialize. When making this calculation, it is a good principle to consider the remaining risk, after mitigation.

Otherwise stated, Risk Management is about deciding how much time, money, effort you want to spend on solving a problem which might never occur. A wise practice in project management is to always consider a risk budget added to the project"s original budget.

Track

The risk must be monitored and reviewed regularly to ascertain the validity of the planned response and, if necessary, to plan new measure(s). There are hundreds of risks which can be identified during a project lifecycle. It is impossible to track all of them on a regular basis. That"s why the recommendation is that only the top 10 risks (considering the priorities established) are monitored regularly. An Impact/Probability matrix can help Project Manager decide which risks need his attention.

To successfully implement a project, the Project Manager must identify and focus his attention on moderate and extreme risks.

The risks towards the top right corner (high impact/high probability) are of critical importance and the ones that the Project Manager must pay close attention to. It can also be the case that at one moment a moderate risk needs more attention because it"s likely to occur soon.

Low-probability / low-impact risks can often be ignored.

Correct

Because the project context can change, already planned responses for a risk might no longer be suitable, therefore corrections need to be done on the risk mitigation plans, sometimes even the risk needs to be re-analysed.

The risk of not having risks

Identifying and managing risks is the very essence of business survival and growth. The practices of risk management are still not formalized in most of our Romanian IT companies and this becomes a risk by itself. Although Project Managers identify risks based on their former experience, lessons learnt or just a gut feeling, the risks are rarely properly managed or monitored. And when things can go wrong they will go wrong (if no action is taken). How many times did you hear the expression: "I knew this would happen" after something bad has happened? And this is just because a person in the team knew that something can go wrong but did not act to prevent it. Sharing is caring and sharing is acting. It is our own responsibility to share risks with the person who can do something about it. Each one of us has its own perspective, knowledge and understanding on what"s going on and sees things that others don"t or can"t. It is said that on average each one of us foresees about 5 risks per day, but usually forgets them soon after. 

Considering your company context and the aspects presented in this article do you foresee any risk of not having managed risks? Or otherwise stated: "Given that there is no Risk Management process in place is there a risk of losing business? Or failing projects? Or losing people?"

It is a challenge for each of us to identify and react on these risks. Some can rise these risks others can do something about them. Yet, an effective risk management starts from the top with clarity about risk strategy and governance, with proper understanding and accountability at the board and executive levels.

At ISDC, we had understood the importance of Risk Management as a process, as a mind-set and as an attitude towards risks and we are continuously working on eliminating "the risk of not having risk" by:

  • Implementing an effective Risk Management process and framework across the organization. This includes policies, procedures, tools and responsibilities involved in the Risk Management activities;
  • Having a system in place, developed in-house, which encourages and supports risk identification, tracking and analysis;
  • Encouraging open communication, non-judgmental, non-attribution when identifying risks;
  • Including risk management related trainings in the Project Managers, Team Leaders and QA Officers development program;
  • Analysing projects" risks (number of risks, risks categories and cumulative value of the risks). Thus, we are able to determine the categories that raise most risks, identify and understand the "risks that matter" and we have the possibility to quickly react and close the gaps.

In order to facilitate ISDC"s Risk Management process we developed our own Risk Manager tool - a web application that allows risk identification, tracking and analysis. The Probability / Impact matrix is a board presenting the risks and their proximity in a nice, visual way. Risk Manager can be accessed by any interested stakeholder based on previously granted permissions. Next step is to embed Business Intelligence and Analytics layer in order to have an efficient reporting, thorough analysis of data and dashboards displaying risks" key indicators.

All these have been and are successful due to our Continuous Improvement Program and to the valuable contribution of Peter Leeson (www.qpit.net). Peter has been inspiring us through his trainings, CMMI appraisals, consultancy and support.

We can conclude that risk management is an essential element of organizational success. The secret of successful projects is closely linked with the ability of taking risks, correctly managing them and communicating results. Also sharing the experience throughout the organization gives the future projects a library of best practices to call on.

Conference

Sponsors

  • comply advantage
  • ntt data
  • 3PillarGlobal
  • Betfair
  • Telenav
  • Accenture
  • Siemens
  • Bosch
  • FlowTraders
  • MHP
  • Connatix
  • UIPatj
  • MetroSystems
  • Globant
  • Colors in projects