Risk & Opportunity
Identification:
Brainstorming (and Risk
Checklists)
CSEM04: Risk and Opportunities of
Systems Change in Organisations
Prof. Helen M Edwards & Dr Lynne
Humphries
University of
Sunderland
CSEM04 ROSCO
Unit 7
Typical Risk
Identification
• The most common ways of identifying risks are:
– Questionnaires, interviews, brainstorming and checklists.
– Historical information is also used as input to these
techniques. This comes from:
• Common sense/experience/“I’ve seen that before”, or
• a formal risk repository
• How would you identify opportunities?
• The risk approaches rely on past experience
(yours/someone else’s)
– Except brainstorming – which tries to “free” people from
current though patterns/expectations.
University of
Sunderland
CSEM04 ROSCO
Unit 7
Brainstorming:
Rules
• Seek Quantity not Quality
• Defer Judgement
• Record the ideas so that they are visible to
all.
• Build on one another's ideas.
University of
Sunderland
CSEM04 ROSCO
Unit 7
Brainstorming:
Standard 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.
University of
Sunderland
CSEM04 ROSCO
Unit 7
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”.
University of
Sunderland
CSEM04 ROSCO
Unit 7
Brainstorming:
Our Procedure
• For the specified topic:
– Put ideas on post-its (one per post-it)
•
•
•
•
Go round the group and call them out
Think again
Put any new ideas on post-its
Put the full set on the wall
– Evaluate
•
•
•
•
Examine your suggestions
Group together “like” suggestions
Identify emerging categories/concepts
Record concept.
– Propose
• Applications for emerging concepts
• Resources needed to support application.
University of
Sunderland
CSEM04 ROSCO
Unit 7
Brainstorming:
Class Exercise
• Think of a paperclip.
– Brainstorm uses for these
• (You have an unlimited number available)
• Process:
– Follow the defined process (post-its and
groups needed).
• Time
– 10 minutes (max)
University of
Sunderland
CSEM04 ROSCO
Unit 7
Brainstorming:
Class Exercise
• “The university has been given
funding to invest in “swipecard”
technology.
– Brainstorm uses for this
• Process:
– Follow the defined process (post-its and
groups needed).
• Time
– 10 minutes (max)
University of
Sunderland
CSEM04 ROSCO
Unit 7
Brainstorming:
Class Exercise
• “The university decided to change
from manual monitoring of student
attendance to using “swipecard”
technology”.
– Brainstorm risks and opportunities for
this.
• Process:
– Follow the defined process (post-its
and groups needed).
• Time
– 20 minutes (max)
University of
Sunderland
CSEM04 ROSCO
Unit 7
Risk Checklists
• Brainstorming brings out the ideas of
the group
• When this is not enough
– Add from others’ past experience:
• In risk identification this is often done using
risk checklists
University of
Sunderland
CSEM04 ROSCO
Unit 7
Risk Checklists
• Vary
– from the simple in-house lists
– to elaborate database repositories of risks.
• The idea is to assess current/proposed projects
against known risks.
– a two-way process
• Existing risk lists (repositories) are evaluated to see if likely to
affect current project
• risks identified by other means are entered into the evolving risk
list (repository).
– A Project-specific risk list is constructed
• During project consider whether any of the risks can be deleted
or retired .
University of
Sunderland
CSEM04 ROSCO
Unit 7
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.
• They are generic risks
University of
Sunderland
CSEM04 ROSCO
Unit 7
Boehm’s
“Top 10 risk items”
• People
• External risks
– Personnel shortfalls
• Resources
– Unrealistic schedules
and budgets
• Requirements
– Shortfalls in externally
produced components
– Shortfalls in externally
performed tasks
• Technology risks
– Real-time performance
– Developing wrong
inadequacies
functions
– Straining CS
– Developing wrong UI
capabilities
– Gold plating
– Changing
requirements
IEEE Software, January 1991.
University of
Sunderland
CSEM04 ROSCO
Unit 7
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
6.
changing scope/ objections
7.
lack of required knowledge or skills
in the project personnel
2.
failure to gain user commitment
3.
misunderstanding the requirements
8.
lack of frozen requirements
4.
lack of adequate user involvement
9.
introduction of new technology
5.
failure to manage end user
expectations
10. insufficient or inappropriate staffing
University of
Sunderland
11. conflict between user departments.
CSEM04 ROSCO
Unit 7
Moynihan’s
risks/concerns
(From 14 experienced systems developer managers in Ireland:
developing systems for other companies)
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)
University of
Sunderland
CSEM04 ROSCO
Unit 7
Moynihan’s risks
11. 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
University of
Sunderland
CSEM04 ROSCO
Unit 7
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/ProjPlanning
University of
Sunderland
CSEM04 ROSCO
Unit 7
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/ProjPlanning
University of
Sunderland
CSEM04 ROSCO
Unit 7
Classic Problems –
Product and Technology Related
Product-Related
• Requirements goldplating
• 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 midproject
• Lack of automated source
code control
www.cs.ualberta.ca/~sorenson/cmput401/lectures/ProjPlanning
University of
Sunderland
CSEM04 ROSCO
Unit 7