Identifying Risks

Being in the software industry, we are all aware of the semantics of the term "Risks.

What is risk?

Risk is the possibility that an organization will NOT:

• Achieve its goals
• Operate effectively and efficiently
• Protect itself from loss
• Provide reliable financial data (reports)
• Comply with applicable laws/regulations and defined policies/procedures

As managers we are accountable for highlighting any risk–possibilities of failure. And being part of the delivery organization, each of us is directly responsible for the first 2 points above.

Much has already been said about risk management, risk based project management et al. So in this article I will confine myself to the phase of "identification of risks".

Risk identification focuses not only on issues that could negatively affect the outcome of the project. The risk identification process focuses also on information that matches your resources and capabilities to the competitive environment in which you work.

A successful risk identification system includes education and communication to stakeholders involved in pivotal project roles. Teaching key members of your team how to identify risks is the first step in successful risk identification. Then, training your team how to communicate those issues to the right people enables you to focus your efforts where they are needed most.

In project management, risk identification begins at the earliest stages of a project and continues throughout the project life cycle. As a test manager, it is your job to anticipate project risks and to implement the necessary controls before risks become insurmountable.

The approach is simple:

• Understand the different types of risks
• Use past data and have discussions with stakeholders
• Ask lots of questions
• Risk assessment and Risk Register

Types of Risks
Internal risks
Internal risks are risks within the control of test managers.

Internal risks are those arising directly from the technology of the project or the work environment. These might include the lack of exposure to required technology, adherence to strategy, or execution plan of the test project or product. These risks can arise from scope creep, aggressive schedules, and product changes or from a failure to achieve the needed levels of performance.

These risks usually arise from a failure of the test organization or resources (human, material, or financial) to achieve their expected performance. Internal risks might result in schedule delays, cost overruns, or interruptions in resource flow. You can categorize these risks as threats or opportunities.

External risks
External, predictable risks are beyond the control of test managers. As a test manager, you must be ready to encounter these risks; however, more important is what you do to counteract them. External, predictable risks also include market activity (such as competitor activity); fiscal policies affecting currency, inflation, and taxation; environmental factors (such as weather); or social impacts. These risks also can be categorized as threats or opportunities.

External, unpredictable risks are beyond the control of test managers and are almost always categorized as threats.

Risks can be identified through

• SQA audit reports–Meet with an auditor to gain his/her insight in conjunction with knowledge of best practices in other areas
• brainstorming–helps to involve the entire team here
• examining offshore experience
• examining onsite experience
• expert judgment
• examining the requirements documents–BRD, screens, wire-frames, flowcharts
• systems analysis
• history, failure analysis
• incidents of complaints
• Interviews of focus groups including most stakeholders–Benchmark with others in similar situations. Are there risks in their areas that could occur in your area?
• system operational modelling–use flows, pictorial diagrams, screen shots and prototype
• organisational experience–network with peers and request them to share experiences
• personal experience
• scenario analysis
• using the risk checklists that are available in the net
• questionnaire
• work breakdown structure analysis
• schedules shared
• Analyse financial data (Where is the high volume or large dollars?)
• Review your assumptions

As a test manager, you need to plan for unknown issues as much as known issues. The above can be revisited on a periodic basis. Risks can prop up at anytime during the life of a project. Keeping this in mind, the managers should include revisits of the risk register in the project schedules.

Lots of questions
These key questions help to identify risks:

• When, where, why, how are the risks likely to occur?
• What is the source of each risk?
• Who might be involved?
• How often might these risks occur?
• How reliable is the information?
• What are the consequences of each risk?
• What is the potential cost in time, money and resources?
• What controls presently exist to mitigate the risk?
• What are the accountability mechanisms - internal and external?
• Is there a need to research specific risks or seek further information?
• What can go wrong?
• How could you fail?
• What must go right for us to succeed?
• Where are you most vulnerable?
• What assets to you need to protect?
• Where is your greatest exposure?
• What types of transactions this project provide the most risk?
• Do you have "liquid" assets or assets which have alternative uses–read "assets" as "resources"?
• How can someone bypass the internal controls?
• On what information do you most rely?
• On what do you spend the most money?
• How do you bill and collect your revenue?
• What decisions require the most judgment?
• What potential risk areas could cause adverse publicity?
• What activities are regulated?

Risk Assessment and Register
As an outcome of the above, document the answers. This can be done using tools like checklists, minutes of meeting, schedules, whiteboard, or on paper. What would evolve is the risk register.

Though you may not have answers to all the questions, start on the risk register

Document the following:

1. Identify high-risk tasks based on schedules, critical paths, resource availability, internal and external dependencies, constraints, leave plans, budget (if applicable)
2. State what would be the trigger for this risk to get into urgent/critical status? E.g. It could be people going on leave, turnaround, weak connectivity, non–availability of licences before a particular date.
3. 3State mitigation plans for each of the risks–where this is not available, highlight it and ask management for direction
4. State the name of the team/ erson responsible for this
5. Include the tentative date by which the mitigation plan would be put in action–this means after this date, the risk is mitigated and no longer a threat
6. Add a column for status–color code the same–e.g Red–open and critical, Amber–open and not urgent, Green–closed. Feel free to add more colors–and remember to update the legend.

A typical Risk Register would include:

1. Risk Description
2. Risk Category
3. Probability
4. Impact
5. Exposure
6. Mitigation Plan

I would prefer to add 2 more columns–one for the trigger and one for the status./p>

Conclusion
There is a lot of uncertainty in all our projects which translates to risks.

As managers, we are expected to manage risks as a part of our role and we have sufficient tools to help us in tracking and mitigating risks. If a risk is not identified it cannot be evaluated and managed which means that - identified risks form the inputs to the risk analysis and management process.

Senior management can use risk assessment data to make informed risk management decisions based on a full understanding of the risk-wise standing of the project. he focus then is on identifying all risks as early as possible with sufficient time to plan their mitigation and document the same.