Risk Identification: Concept and Generic Techniques

1
Risk Identification Concept and Generic
Techniques

• COMM80 Risk Assessment of Systems Change
• Unit 4.

2
Objectives of Session Coverage

• To consider specific examples of risks that
  affect projects.
• To identify generic techniques that are widely
  used for risk identification.
• To practise the use of one (brainstorming).

3
Typical Risks

• The next few slides show typical risks that have
  been identified and published in the literature
• These are often the basis for formal repository
  lists.
• These are all from a systems development
  perspective
• but it should be noted that very few of the risks
  are specific to that environment.

4
Boehms Top 10 risk items

• People
• Personnel shortfalls
• Resources
• Unrealistic schedules and budgets
• Requirements
• Developing wrong functions
• Developing wrong UI
• Gold plating
• Changing requirements

• External risks
• Shortfalls in externally produced components
• Shortfalls in externally performed tasks
• Technology risks
• Real-time performance inadequacies
• Straining CS capabilities

IEEE Software, January 1991.
5
Common Risks from Keil et al
Framework for identifying software project
risks Communications of the ACM, vol 41 (11)
Identified by experienced software project
managers from the USA, Hong Kong and Finland. In
order of perceived importance, these factors are

1. lack of top management commitment to the project
2. failure to gain user commitment
3. misunderstanding the requirements
4. lack of adequate user involvement
5. failure to manage end user expectations

1. changing scope/ objections
2. lack of required knowledge or skills in the
   project personnel
3. lack of frozen requirements
4. introduction of new technology
5. insufficient or inappropriate staffing
6. conflict between user departments.

6
Moynihans risks/concerns
(From 14 experienced systems developer managers
in Ireland developing systems for other
companies)

• 1. Clients understanding of the
  requirements/problem to be solved (12)
• 2. Seniority commitment of the project
  patron/owner (9)
• 3. Level of IT competence, experience of the
  customers (9)
• 4. Need to integrate/interface with other systems
  (9)
• 5. Scale/coordination complexity of the project
  (need to share resources,
  subcontract, etc) (8)
• 6. Where project control resides (developer v
  client v third parties) (8)
• 7. Level of change to be experienced by the
  client (to procedures, workflow,
  structures, etc) (7)
• 8. The need to satisfy multiple groups of
  disparate users versus the
  need to satisfy one group of similar users (7)
• 9. Who we will be working through users versus
  the IT department, individuals
  versus committees (7)
• 10. Developers familiarity with
  platform/environment/methods (7)

7
Moynihans risks

• 11. Developers previous experience with the
  application (6)
• 12. Level of enthusiasm/support/"energy" for the
  project in the clients organization (5)
• 13. Logical complexity of the application (5)
• 14. Ease of solution validation (e.g. possibility
  of prototyping) (4)
• 15. Clients willingness/capability to handle
  implementation (3)
• 16. Freedom of choice of platform/development
  environment (3)
• 17. Criticality/reversibility of the new system
  roll-out (2)
• 18. Maturity of the technology to be used (2)
• 19. Developers knowledge of country/culture/langu
  age (2)
• 20. Stability of the clients business
  environment (2)
• 21. Developers knowledge of clients business
  sector (2)

IEEE Software 14(3) pp35-41
8
Classic Problems Process-Related

• Overly optimistic schedules
• Insufficient risk management
• Contractor failure
• Insufficient planning
• Stop planning under pressure
• Wasted time during fuzzy front end
• Short-changed upstream activities
• Inadequate design

• Short-changed quality assurance
• Insufficient management controls Premature or
  overly frequent convergence
• Omitting necessary tasks from estimates
• Planning to catch up later
• Code-like-hell programming

www.cs.ualberta.ca/sorenson/cmput401/lectures/Pro
jPlanning
9
Classic Problems People-Related

• Undermined motivation
• Weak personnel
• Uncontrolled problem employees
• Heroics
• Adding people to a late project
• Noisy, crowded offices
• Friction between developers and clients

• Unrealistic expectations
• Lack of effective project sponsorship
• Lack of stakeholder buy-in
• Lack of user input
• Politics placed over substance
• Wishful thinking

www.cs.ualberta.ca/sorenson/cmput401/lectures/Pro
jPlanning
10
Classic Problems Product and Technology
Related

• Product-Related
• Requirements gold-plating
• Feature creep
• Developer gold-plating
• Push-me, pull-me negotiations
• Research-oriented development

• Technology-Related
• Silver-bullet syndrome
• Over-estimated savings from new tools or methods
• Switching tools in mid-project
• Lack of automated source code control

www.cs.ualberta.ca/sorenson/cmput401/lectures/Pro
jPlanning
11
Typical Risk Identification

• The most common ways of identifying risks are
• Questionnaires, interviews, brainstorming and
  checklists.
• Historical information is also as input to these
  techniques. This comes from
• Common sense/experience/Ive seen that before,
  or
• a formal risk repository

Techniques range from using common sense and
experience through to formal risk review
procedures.
12
Risk Checklists

• These vary from the simple in-house lists to
  elaborate database repositories of risks.
• In using checklists the idea is to assess current
  projects against known risks.
• It should be a two-way process, as new risks are
  identified by other means they should be entered
  into the evolving repository.
• Users should also consider whether any of the
  risks can be deleted or retired .

13
An Example of a Risk Repository
Databases such as Risk RadarTM (www.iceinceUSA.com
) allow risk lists to be developed
within organisations.
14
Brainstorming Rules

• Seek Quantity not Quality
• Defer Judgement
• Record the ideas so that they are visible to all.
• Build on one another's ideas.

15
Brainstorming Procedure

• Select one member of the group as the recorder
• Put the topic to be considered on a flip
  chart/white board. (It may help to underline the
  key words).
• Ask for possible solutions/ideas to be called
  out.
• Record these, without allowing any opinion on
  value or relevance to be expressed at this stage.
• Continue until ideas cease.
• THEN evaluate the ideas, and refine the proposals.

16
Brainstorming Warm Up

• In a group where this is a new approach have a
  warm up exercise
• chose a trivial topic - such as List possible
  uses for a brick.
• If an explanation is asked for when a suggestion
  is made give it in this exercise
• but explain that this stops the flow of ideas.
• To use the technique correctly there should be no
  interruption.
• Once the group is comfortable with the technique
  it can be applied for real.

17
Brainstorming Class Exercise

• Your turn
• ltltltltltltltltltltltgtgtgtgtgtgtgtgtgtgtgt
• we will now try the warm up exercise
• List possible uses for a brick.
• (permit 15 minutes)
• ltltltltltltltltltltltgtgtgtgtgtgtgtgtgtgtgt
• Now for real
• List possible risks and opportunities in changing
  from a telephone mail ordering system to a
  web-based one.

18
Moving On

• Were now in a position to move on to a systems
  change case study
• we will use some of the techniques we study on
  this
• we will initially identify risks associated with
  systems change in the case study.