Software Risk Management

Chapter 04: Risk Identification

Course Instructor: Amir Imam

 The Meaning of Risk Identification
• First, we have to pick up risks and locate where they are hidden.
• Then we have to recognize the risks, name them, define them, and assign
attributes from a risk classification system.
• Sometimes we see risks but they are disguised and dodge recognition.
• At other times we have seen risks, but they are vague, defying easy
definitions.
• Sometimes risks are buried in organizational noise; the symptoms of risk
are not visible.
• Vision is impair due to shortsightedness or is narrow and limited.
• Risk lie in wait in the less-traveled byways.
• In risk identification, we need to see all the avenues, search all processes,
and consider all factors.
• What we get to see is always a fraction of the truth and the much-
traveled roads are more visible.
 The Meaning of Risk Identification
• Once a risk is spotted, we should look at its attributes and the features,
and characterize it.
• We should position the risk in the global risk arrangement.
• We have to review the consequence of the risk and rank it.
• Risk identification results in the creation of a validated risk list.
• The risk identifier tries to give a minimum set of risk information.
• The identifier can find more attributes, and provide adequate inputs for
subsequent risk analysis.
• Risk identification telescopes into risk analysis; where one ends, the
other begins.
• Well-conducted risk identification involves preliminary analysis and adds
that much more value to risk data.
Risk identification is the process of searching the environment, detecting
risks, recognizing their attributes, and estimating their consequences
Risk Identification Methods
• There are two types of risk identification methods. Type I and Type II
• The first type (type I) is generic, open-ended, and constitutes a search in
internal and external environments.
• It includes intuitive methods that are necessary to discover risks unknown
up to now.
• The history-based methods put known taxonomies and risk lists to fresh
use.
• History, in the forms of taxonomies, serves as a broad guide, directing the
process of enquiry.

Intuitive methods History-based methods

a. Mind mapping a. Top ten risks
b. Brainstorming b. Risk checklist
c. Out-of-the box thinking c. Taxonomy-based questionnaire
d. Analogy
Risk Identification Methods
• The second type (type II) is a search for risk within a tightly held context
and focuses on risks related to delivery.
• Type II is a formal method with six phases.
▫ Phase I Context setting
▫ Phase II Data gathering
▫ Phase III Risk discovery
 Mapping
 Risk survey
 Risk models (Chapter 8)
 Risk intelligence (Chapter 9)
▫ Phase IV Attributes assignment
▫ Phase V Validation
▫ Phase VI List
Type I: Intuitive Methods
• Mind Mapping
▫ The mind recognizes risk symptoms by mapping
familiar symptoms to future trouble.
▫ Sometimes, the mapping is based on lessons
learned by the investigator.
▫ Sometimes the mapping is futuristic, derived from
complex extrapolations.
▫ How the mind creates a map is beyond
conventional linear logical methods.
Type I: Intuitive Methods
• Brainstorming
▫ Group thinking, with cross-fertilization of ideas, aided by brainstorming
and mind mapping, is most useful in identifying unknown and hidden
risks.
▫ Teams have found more risks than those found by any individual.
▫ To convert risk identification brainstorming into structured
brainstorming and thus increase the efficiency of the process, the team
can think around
 the project plan.
 a requirements list and capture engineering
 The brainstorming sessions can start with a well-defined theme and
strategy to identify risks.
▫ In general, all planning documents and standards can provide very
valuable help to a team so as not to miss the details and yet stay
focused on the project goals.
Type I: Intuitive Methods
• Out-of-the-Box Thinking
▫ We can see risks better if we stand out of the box and
take an external and holistic perspective of the
situation.
▫ Risks do not hide in beaten tracks; they lie in less-
traveled zones.
▫ Thinking in terms of alternatives requires creative
ability and a breaking away from habits and rituals.
▫ We get used to our process environment and gradually
become oblivious of the threats and risks.
▫ Convenience masks risks.
▫ Familiarity blurs our vision.
 Stay Hungry ….Stay Foolish – Steve Jobs
Type I: Intuitive Methods
• Analogy
▫ Experienced people, having managed several projects, develop intuitive skills to
detect risk. The known risks are logged somewhere in their brains.
▫ All they have to do is allow mapping between the new situation and the
analogous situation in the past.
▫ Practicing analogy helps us to detect risks by looking at triggers that are
disguised or transformed.
▫ When we relate our new process to a familiar but different process, we can
think of using risk types from the familiar process and look into the chances of
the same types repeating in the new process.
▫ If the two processes, the familiar and the new, are analogous, risk types may
repeat.
▫ We have the extra advantage that not only do the risk types repeat, we can
also reuse the risk identification methods.
▫ If the analogy works, not only risks, but also the tell-tale symptoms may be
similar.
▫ We can give it a try, instead of resorting to wild guesses.
Type I: History-Based Methods
• Risk lists published by authors and researchers can play a major supportive role in
risk identification.
• The risks seen by others may also be present in our lives too. We use those risks
lists as cross-reference documents.
• Each risk list could contain someone’s lifetime experience.
• Each risk list provides a perspective, a window, a standpoint, to reexamine our
projects.
• Most of the significant risks in software projects can be identified by reviewing the
project from the perspective of published risk lists:
1. Caper Jones’s software risks
2. Rex Black’s quality risks
3. SEI’s risk taxonomy
4. Popular top ten risks
History-Based Methods (Caper Jones’s list)
• Caper Jones approaches risk management like managing diseases.
• Caper Jones presents a set of risks — or symptoms — just as medical practitioners
identify health risks in patients and administer preventive medicine.
• The medical analogy is well chosen by him. Here is a selection of risks from his list:
1. Artificial maturity levels
2. Canceled projects
3. Corporate politics
4. Cost overruns
5. Creeping user requirements
6. Crowded office conditions
7. Error-prone modules
8. Excessive paperwork
9. Excessive schedule pressure
10. Excessive time to market
History-Based Methods (Caper Jones’s list)
• Jones present software metrics as a major risk in software projects.
• Many things can go wrong in metrics.
• We measure the wrong factors, and miss the right ones.
• When we decide to trust an ill-designed metrics system, we run risks.
• This caution is age-old. Deming had said: “Do not manage a company by visible
numbers alone.” But Jones puts it as a risk.
• A typical risk identifier may not connect risks to metrics, but after Jones’s proposal,
a new perspective has arisen.
• Cross-checking your project against this risk list could be a “life saver.”
• Part of Jones’ risk list is given in Appendix A.
History-Based Methods (Rex Black’s risk list)
• That “risk lists” can have multiple uses is beautifully demonstrated in Rex Black’s
“Critical Testing Processes.”
1. Functionality
2. Load, capacity, and volume
3. Reliability/stability
4. Stress, error handling, and recovery
5. Date and time handling
6. Operations and maintenance
7. Data quality
8. Performance
9. Localization
10. Compatibility
11. Security/privacy
12. Installation/migration
13. Documentation
14. Interfaces
• These are also quality attributes of the product, and play a role in managing
product quality from a standpoint not related to risk thinking.
• These are also “failure modes” of the product according to FMEA (failure modes
effects analysis) practice and become the anchor points for reliability analysis and
preventive actions.
History-Based Methods (SEI’s & Top N risk list)
• The risk list published by SEI, under the name of risk taxonomy, is a very useful
tool for risk identification.
• It covers three categories of risk: product engineering risks, development
environment risks, and program constraints risk.
• Risks identified by three researchers Brian A. Will, Will captures risks that seem to
be present in all development projects.
• From requirements to office space, some well-known, oft-repeated risks have
been identified by Will.
• Barry Boehm’s top ten risk list can help in quick risk identification.
• His “gold plating” risk has gained great popularity.
• Chester Summer’s top ten list also meets the same need.
• We find “communications” and “concurrent engineering” in the list.
• Such top ten risk lists define what we already know, but help us to remember
them during risk identification.
 Risk Checklist, Taxonomy-Based
Questionnaire
• Experience makes preparation of risk checklists possible. The checklist is
constructed with tell-tale symptoms, clues, or simply names of known risks.
• The organization’s collective experience in risk identification is used to design risk
checklists. We can have special risk check lists for each phase, and for each
process.
• SEI proposes a (TBQ) as a formal and structured way of identifying risks.
• Risks are viewed through windows of known risk types, making identification of
risks faster and more economical.
• Then TBQ method uses searching questions for each attribute. Say “Stability”

Requirement phase risk attributes Taxonomy-Based Questionnaire

a. Stability SEI TBQ for Requirement Stability
b. Completeness [1] Are the requirements stable? (No) (1a) What is the effect on the system?
c. Clarity Quality, Functionality, Schedule, Integration, Design, Testing
d. Validity [2] Are the external interfaces changing?
e. Feasibility SEI TBQ for Requirement Completeness
[3] Are there any TBDs in the specifications? [4] Are there requirements you
f. Precedent
know should be in the specification but are not present?
g. Scale
(Yes) (4a) Will you be able to get these requirements into the system?
[5] Does the customer have unwritten requirements/expectations?
(Yes) (5a) Is there a way to capture these requirements?
[6] Are the external interfaces completely defined?
Type II: Project-Specific Risk Identification
Phase I: Context Setting
• Project-specific risk identification is a context-based identification process.
• By setting a context, we might make the mistake of excluding some risks
that lie outside the set context, risks which might be significant.
• We rely on Type I risk identification to make a context-free, general scan
of risks.
• Project team may set themes for various risk identification exercises.
▫ Product risk identification
▫ Design risk identification
▫ Project risk identification
▫ Business risk identification
▫ Testing risk identification
▫ Bug fixing risk identification
• The scope of risk identification will be defined in such cases before the
meeting takes place.
 Type II: Project-Specific Risk Identification
Phase II: Data Gathering
• Risk identifier is aware of risks whose symptoms existed but were ignored.
• After the bad experience he becomes wiser and is willing to look for symptoms -
the risk indicators.
• Firstly he records the presence of risk indicators known to him which are a
fraction of the full list.
• Only the familiar are illuminated as his vision is narrow, limited and selective.
• The risk identifier looks for methods that will capture risks which are unfamiliar
and escaped earlier
• Then he realizes that what is unknown to him may be known to others. Each
person has a unique and different history.
• In a project environment, the identifier calls for a brainstorming session.
• The participants are the stakeholders and are motivated to look at risks.
• The session evokes multiple perspectives and illuminates hitherto untraced
areas. More risks are identified as a result.
 Type II: Project-Specific Risk Identification
• To improve the yield of the risk identification process, the team must go through
a preparatory phase before the actual meeting.
• The biggest input to risk identification is pertinent information. Here is an
example of a list that shows the range of inputs which may be of use in risk
identification.
1. Corporate goals 11. Management reviews 24. Competitor analysis
2. Project objectives 12. Inspection and test reports 25. Threat modeling
3. Assumptions 13. Risk checklist 26. Business intelligence
4. Constraints 14. List of known risks 27. Metrics data mining
5. Customer requirements 15. Risk taxonomy 28. Internal quality audit reports
6. Customer feedback 16. Risk classification system 29. Certification body audit reports
7. Benchmark studies 17. Risk attributes 30. Finance audit reports
8. Metrics data 18. Risk history 31. Management review findings
9. Process capability baselines 19. Risk database
10. Internal quality audit findings 20. Growth plans
21. Investor’s expectations
22. Market research
23. Customer behavior analysis
 Type II: Project-Specific Risk Identification
Phase III: Risk Discovery
• To succeed in risk discovery, the organization must become risk sensitive.
• Risk discovery needs the right environment. It requires vision and
empowerment.
• Uninterested and lethargic People without vision cannot discover risks.
• Without a risk management policy in place, there is no motivation to discover
risks.
• It encompasses the whole organization, from the individual level to the
corporate level.
• The manager supports risk identification; to detect vulnerabilities in the project
and set up defenses, and to ensure the longevity of project plans, the manager
initiates mitigation and contingency plans to manage risks.
• The mapping of indictor to risk events.
• Use of Risk Survey, Models, Metrics Data, Scenarios, etc. ..
 Type II: Project-Specific Risk Identification
Phase IV: Assigning Attributes
• Once the risk identifier has zeroed in on the risk event, he has to describe the
event in a concise manner.
• He also creates a unique identity and reference for the risk.

Referential Data Primary Evaluation Data Secondary data and risk attributes
1. Strategic business unit (SBU) name 8. Risk consequence description 12. Origin (internal or external)
2. Project name 9. Risk probability (p) (scale: 0 to 10) 13. Type (business or technical)
3. Risk identifier team members 10. Risk impact (i) (scale: 0 to 10) 14. Most affected process (Requirements, Data
4. Risk identification date 11. Risk exposure (p) x (i) Encryption Standard,
5. Risk ID Coding, Testing, Training, Quality Management,
6. Risk name Project Management,
7. Risk event description Financial Management)
15. Most affected result (EFF, SCH, Q, PERF)
16. Risk trigger
17. Expected time of occurrence (existing, next M,
Q, Yr)
18. Risk visibility (VL, L, N, H, VH)
19. Risk nature (hazard, constraint, nominal, trivial)
20. Risk owner
 Type II: Project-Specific Risk Identification
Phase V: Validation
• Validation of risks means removing the following defects from the risk list:
▫ Wrong description
▫ Wrong name
▫ Wrong classification
▫ Irrelevance (not relevant to the project)
▫ Ambiguity
▫ Repetition
▫ Blurred differences (lack of uniqueness)
• Validation should be done by the same team that identified risks. Others may not
be able to get the right context from wrong statements to cross-check the risk
statements.
• Burying Trivial Differences - The Funnel Model, risks be reduced
• Naming the Risks
• Risk Statements Are Problem Definitions
 Type II: Project-Specific Risk Identification
Phase V: Validation - The Trouble with Validation
• Validating risk statements calls for great self-discipline and motivation.
• It is not a “favorite” activity.
• Those who created risk statements do not like to see them perish.
• In some cases, once risks are entered into a risk-tracker tool, quick changes are
not possible and the tool ensures that risk statements survive for a long time.
• The statements are “records” that cannot be tampered with.
• Identification is seen as a value-adding process, whereas validation is seen as a
fault-finding process that diminishes hard-earned satisfaction.
Phase VI: List
• The output of risk identification is a list of validated risks.
• The risks will be tabulated along with identified attributes. This list is the basis for
further analysis.
 Levels in Identification
• Process-Level Risk Identification
 List all the requirements (or features or functions) and identify risks you may meet while
realizing the requirements as software products.
 Evaluate the risk exposure number for each requirement.
 To enhance your perception, estimate the FP count corresponding to each requirement.
• Project-Level Risk Identification
▫ Organization goals associated risks
▫ Performance targets associated risks
▫ Project objectives associated risks
• Enterprise-Level Risk Identification
▫ List your organizations strengths, weaknesses, opportunities, and threats.
▫ Define your growth goals and marketing strategies. Then fill in this data:
 SBU name
 Growth goal
 Marketing strategy
 Strengths
 Weaknesses
 Opportunities
 Threats
 Implementing Risk Identification Processes
• Risk identification is a complex process. We can search the entire risk
environment or look at chosen sections.
• The span and depth can vary between risk identification exercises.
• The dilemma faced by every project team is to choose between general risks
(most of which anyway will be escalated) and project-specific risks.
• However, a quick scan at all levels is recommended, followed by a detailed study
of the project-specific environment.
• The team must do type I risk identification first, rapidly, and then go in for type II
risk identification.
• The risk list must contain risks identified by both methods.