Risk & Opportunity Identification: Brainstorming (and Risk Checklists)

Unit 7University of Sunderland CSEM04 ROSCO

Risk & Opportunity Risk & Opportunity Identification: Identification:

Brainstorming (and Risk Brainstorming (and Risk Checklists)Checklists)

CSEM04: Risk and Opportunities of Systems Change in OrganisationsProf. Helen M Edwards & Dr Lynne

Humphries


Typical Risk Typical Risk IdentificationIdentification

• 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.


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.


Brainstorming: Brainstorming: Standard ProcedureStandard 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.


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”.


Brainstorming: Brainstorming: Our ProcedureOur 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.


Brainstorming: Brainstorming: Class ExerciseClass 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)



• “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).




• “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).



Risk ChecklistsRisk 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


Risk ChecklistsRisk 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 .


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.

• They are generic risks


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.


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)


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)


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


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


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



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


Risk & Opportunity Identification: Brainstorming (and Risk Checklists)

Documents

Transcript of Risk & Opportunity Identification: Brainstorming (and Risk Checklists)