Risk Identification: Specific Techniques for Particular Perspectives'

1
Risk Identification Specific Techniques for
Particular Perspectives.

• COMM80 Risk Assessment of Systems Change
• Unit 5

2
Objectives of Unit

• To focus on specific techniques for risk
  identification that fit well with particular
  perspectives
• To practise their use.
• To evaluate the techniques.

3
Personnel Perspective.

• Possible approaches
• generic techniques of brainstorming and
  interviews.
• RAMESES questionnaires
• SSMS (Soft System Methodologys) rich pictures.

Typical personnel risks (re)training,
demotivation loss of personnel, resistance to
change.
4
SSMS rich pictures.

• Rich pictures were developed within SSM for
  understanding problem situations.
• They are not limited to use in a risk management
  approach
• and are more typically used to define systems
  requirements or examine problematic,
  unstructured, situations.
• A free form pictorial format is recommended
• this represents structures, processes and issues
  of the organisation. In the context of this
  module this would particularly be from a
  risk/conflict perspective.

5
Rich Picture Example (from Avison and
Fitzgeralds IS Developemnt Methodologies,
Techniques and Tools. McGraw-Hill, 2nd Edition,
1995.

• The Secretary of a growing Professional
  Association believed many of its operations could
  be computerised including membership,
  examination, and tuition administration. Before
  commissioning any new systems she wanted an
  overview of where potential benefits would be
  found and what problems might exist.
• A consultancy looked at what was going on in the
  organisation and created an initial rich picture
  of the situation. This is shown on the next slide.

6
Rich Picture for the Scenario

• This picture demonstrates a a fairly high level
  some personnel type risks, for instance
• conflict between the secretary and the education
  secretary about the how and what to computerise
• Worries of the education assistant about the
  thought of automation - should alert to the risk
  of poor usage, resistance, also need for training
  and support.

7
Rich Picture Example
(from Linda MacAulays Requirements
Engineering, Springer-Verlag London Ltd).

• A vehicle rental company (VCR) rents cars and
  vans to private and business users. They have
  had a significant rise in the level of business
  rentals and predict that this will be the fastest
  growing market sector over the next five years.
  VCR is trying to decide whether to establish a
  separate corporate service operation to target
  medium to large organizations. VCRs aim is to
  become a sole supplier of vehicle rentals to its
  corporate customers.

8
Rich Picture for the Scenario
9
Detail of Rich Picture
Area of agreement denoted by handshake
Area of conflict denoted by crossed swords
10
SSMS rich pictures.

• Typically a rich picture of a situation should
  contain
• main structures both formal and informal
• elements of process.
• Sets of rich pictures of a situation for
  different stakeholders can be created and
  compared.

11
Systems Development Perspective.
Possible approaches SEIs SREs comprehensive
taxonomy based questionnaire. The RAMESES systems
specification matrix.
Typical systems development risks missed
deadlines, exceeded costs, poor quality
software, skills shortages
12
SEIs Taxonomy Based Questionnaire (TBQ)

• Assumption project team members have a lot of
  tacit risk information.
• The TBQ provides an instrument for unearthing
  this.
• The taxonomy is based on
• risks identified in the literature on software
  development (e.g. Boehms top ten),
• SEI team members experience and
• Analysis of the field trials results of the
  method.
• It identifies characteristics of software
  development.

13
The SEI Taxonomy

• Risk Class Product Engineering
• Risk Element Requirements
• Attributes Stability, Completeness, Clarity,
  Validity, Feasibility, Precedent, Scale
• Risk Element Design
• Attributes Functionality, Difficulty,
  Interfaces, Performances, Testability, Hardware
  Constraints, Non-developmental software
• Risk Element Code and Unit Test
• Attributes Feasibility, Testing,
  Code/Implementation
• Risk Element Integration and Test
• Attributes Environment, Product,
• Risk Element System Engineering Specialities
• Attributes Maintainability, Reliability, Safety,
  Security, Human Factors

14
The SEI Taxonomy

• Risk Class Development Environment
• Risk Element Development Process
• Attributes Formality, Suitability, Process
  Control, Familiarity ,Product Control.
• Risk Element Development System
• Attributes Capacity, Suitability, Usability,
  Familiarity, Reliability, System Support,
  Deliverability.
• Risk Element Management Process
• Attributes Planning, Project Organisation,
  Management Experience, Program Interfaces.
• Risk Element Management Methods
• Attributes Monitoring, Personnel Management,
  Quality Assurance, Configuration Management.
• Risk Element Work Environment
• Attributes Quality Attitude, Co-operation,
  Communication, Morale.

15
The SEI Taxonomy

• Risk Class Programme Constraints
• Risk Element Resources
• Attributes Staff, Budget, Schedule,
  Facilities.
• Risk Element Contract
• Attributes Type of Contract, Restrictions,
  Dependencies.
• Risk Element Program Interfaces
• Attributes Customer, Associate Contractors,
  Subcontractors, Prime Contractor, Corporate
  Management, Vendors, Politics.

16
Using SEIs TBQ

• The questionnaire that has been developed
• presents a structured set of (193) questions
  concerning every attribute in the taxonomy.
• The questionnaire focuses on software development
• It is used in an interview conducted by
  independent assessors with small groups of
  project staff.
• Only peers are included in an interview group -
  the presence of a manager has been found to be
  inhibiting.

17
Using SEIs TBQ

• The questions vary
• from A.1-a (No.1) to C.3-g (No. 193).