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 • SSM’S (Soft System Methodology’s) rich pictures. • Typical personnel risks: • (re)training, • demotivation • loss of personnel, • resistance to change.

4. SSM’S 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 Fitzgerald’s 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 MacAulay’s “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. VCR’s 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. SSM’S 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: • SEI’s SRE’s comprehensive taxonomy based questionnaire. • The RAMESES systems specification matrix. • Typical systems development risks: • missed deadlines, • exceeded costs, • poor quality software, • skills shortages

12. SEI’s 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. Boehm’s “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 SEI’s 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 SEI’s TBQ The questions vary from A.1-a (No.1) to C.3-g (No. 193).