unit 4 university of sunderland comm80 risk assessment of systems change risk identification:...
Post on 22-Dec-2015
219 views
TRANSCRIPT
Unit 4University of Sunderland COMM80 Risk Assessment of Systems Change
Risk Identification: Concept Risk Identification: Concept and Generic Techniquesand Generic Techniques
COMM80: Risk Assessment of Systems Change
Unit 4.
Unit 4University of Sunderland COMM80 Risk Assessment of Systems Change
Objectives of Objectives of Session CoverageSession 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).
Unit 4University of Sunderland COMM80 Risk Assessment of Systems Change
Typical RisksTypical 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.
Unit 4University of Sunderland COMM80 Risk Assessment of Systems Change
Boehm’s Boehm’s “Top 10 risk items”“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.
Unit 4University of Sunderland COMM80 Risk Assessment of Systems Change
Common Risks Common Risks from Keil et alfrom Keil et al
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
6. changing scope/ objections
7. lack of required knowledge or skills in the project personnel
8. lack of frozen requirements
9. introduction of new technology
10. insufficient or inappropriate staffing
11. conflict between user departments.
Identified by experienced software project managers from the USA, Hong Kong and Finland.
In order of perceived importance, these factors are:
““Framework for identifying software project risks” Framework for identifying software project risks” Communications of the ACM, vol 41 (11)Communications of the ACM, vol 41 (11)
Unit 4University of Sunderland COMM80 Risk Assessment of Systems Change
Moynihan’s Moynihan’s risks/concernsrisks/concerns
1. Client’s 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. Developer’s familiarity with platform/environment/methods (7)
(From 14 experienced systems developer managers in Ireland: (From 14 experienced systems developer managers in Ireland: developing systems for other companies)developing systems for other companies)
Unit 4University of Sunderland COMM80 Risk Assessment of Systems Change
Moynihan’s risksMoynihan’s risks11. Developer’s previous experience with the application (6)
12. Level of enthusiasm/support/"energy" for the project in the client’s organization (5)
13. Logical complexity of the application (5)
14. Ease of solution validation (e.g. possibility of prototyping) (4)
15. Client’s 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. Developer’s knowledge of country/culture/language (2)
20. Stability of the client’s business environment (2)
21. Developer’s knowledge of client’s business sector (2)
IEEE Software 14(3) pp35-41
Unit 4University of Sunderland COMM80 Risk Assessment of Systems Change
Classic Problems Classic Problems –– Process-RelatedProcess-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/ProjPlanning
Unit 4University of Sunderland COMM80 Risk Assessment of Systems Change
Classic Problems Classic Problems –– People-RelatedPeople-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/ProjPlanning
Unit 4University of Sunderland COMM80 Risk Assessment of Systems Change
Classic Problems Classic Problems –– Product and Technology RelatedProduct 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/ProjPlanning
Unit 4University of Sunderland COMM80 Risk Assessment of Systems Change
Typical Risk Typical Risk IdentificationIdentification
•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/“I’ve seen that before”, or
•a formal risk repository
Risk Perspective
Risk Lifecycle
Generic
IdentifyBrainstorming,interviewing,existing lists
Techniques range from using common sense and experience through to formal “risk review” procedures.
Unit 4University of Sunderland COMM80 Risk Assessment of Systems Change
Risk ChecklistsRisk 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 .
Unit 4University of Sunderland COMM80 Risk Assessment of Systems Change
An Example of a An Example of a Risk Repository Risk Repository
Databases such as Risk RadarTM (www.iceinceUSA.com) allow risk lists to be developed
… within organisations.
… and reused / evolved
Unit 4University of Sunderland COMM80 Risk Assessment of Systems Change
Brainstorming: Brainstorming: RulesRules
• Seek Quantity not Quality
• Defer Judgement
• Record the ideas so that they are visible to all.
• Build on one another's ideas.
Unit 4University of Sunderland COMM80 Risk Assessment of Systems Change
Brainstorming: Brainstorming: ProcedureProcedure
• 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.
Unit 4University of Sunderland COMM80 Risk Assessment of Systems Change
Brainstorming: Brainstorming: Warm UpWarm 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”.
Unit 4University of Sunderland COMM80 Risk Assessment of Systems Change
Brainstorming: Brainstorming: Class ExerciseClass Exercise
• Your turn:
<<<<<<<<<<<>>>>>>>>>>>– we will now try the warm up exercise:
• List possible uses for a brick.• (permit 15 minutes)
<<<<<<<<<<<>>>>>>>>>>>– Now for real:
• List possible risks and opportunities in changing from a telephone mail ordering system to a web-based one.
Unit 4University of Sunderland COMM80 Risk Assessment of Systems Change
Moving OnMoving On
• We’re 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.