Docstoc

Slide 1 - facweb.cti.depaul.edu

Document Sample
Slide 1 - facweb.cti.depaul.edu Powered By Docstoc
					CSC 394
IS 376
Undergraduate
Capstone Course



Lecture 3
Risk Management

Spring 2004
Jane Huang
                                  Chaos Report
                                  Standish Research Group Report
"The Roman bridges of antiquity were very inefficient structures. By modern standards, they used too much stone, and as a
result, far too much labor to build. Over the years we have learned to build bridges more efficiently, using fewer materials and
less labor to perform the same task.“                                               Tom Clancy (The Sum of All Fears)

• Bridges are normally built on-time, on-budget, and do not fall down
• Software “never” comes in on-time or on-budget. It always breaks down.
• Bridge building did not always have such a stellar record – 3,000 years of
  experience, failures investigated & reported.
• Computer industry failures are covered up, ignored, and/or rationalized. – mistakes
  repeated over and over again.


  Project Success: Type 1. The project is completed on-
  time and on-budget, with all features and functions as
  initially specified. (2000: 28%)
  Project Challenged: Type 2. The project is completed
  and operational but over-budget, over the time
  estimate, and offers fewer features and functions than
  originally specified. (2000: 49%)
  Project Impaired: Type 3. The project is canceled at
  some point during the development cycle.
  (2000: 23%) (Are ALL impaired projects failures???)
One notable exception – Millenium Bridge in London.
                                                                       2000
                                                  Project Success Factors         % of Responses
                                                 1.    Executive Support                   18%
                                                 2.    User Involvement                    16%
                                                 3.    Experienced Project Manager         14%
                                                 4.    Clear business objectives           12%
                                                 5.    Minimized scope                     10%
                                                 6.    Standard software infrastructure     8%
                                                 7.    Firm basic requirements              6%
                                                 8.    Formal methodology                   6%
                                                 9.    Reliable estimates                   5%
                                                 10.   Other                                5%
                           1994
 Project Challenged Factors                % of Responses
1.    Lack of User Input                               12.8%        Project managers were
2.    Incomplete Requirements & Specifications         12.3%        asked to identify the
3.    Changing Requirements & Specifications           11.8%        most influential
4.    Lack of Executive Support                         7.5%
5.    Technology Incompetence                           7.0%        factors in both
6.    Lack of Resources                                 6.4%        successful and
7.    Unrealistic Expectations                          5.9%        challenged projects.
8.    Unclear Objectives                                5.3%
9.    Unrealistic Time Frames                           4.3%
                                                                    Materials taken from:
10.   New Technology                                    3.7%
                                                                    http://standishgroup.com
      Other                                            23.0%
Case-Studies – conducted by the Standish Research Group

               California DMV 1987-1993 project to revitalize their
               drivers license and registration application process. By
               1993, after $45 million the project was cancelled.
               (No monetary payback, no IT buy in)

               American Airlines        1994, a $165 million car rental and
               hotel reservation system (CONFIRM) involving American
               Airlines, Budget Rent-A-Car, Marriott Corp. and Hilton Hotels
               collapsed in chaos. (Too many cooks!)


               Hyatt Hotels       Confirmation System - dial from a cellular
               airplane telephone at 35,000 feet, check into your Hyatt hotel
               room, schedule the courtesy bus to pick you up, and have your
               keys waiting for you at the express desk – all for under $15 million.


               Banco Itamarati          A year after a strategic redirection, Banco
               Itamarati, a privately-held Brazilian bank, produced an annual net
               profit growth of 51% and moved from 47th to 15th place in the
               Brazilian banking industry. Technology was a key component of
               their business strategy.
                                      Materials taken from: http://standishgroup.com
Risk
Management
 “If you don’t actively attack
 the risks, they will attack
 you!”
 Tom Gilb

 “Today no one has the luxury
 of getting to know a task so
 well that it holds no surprises,
 and surprises mean risk”.
 Stephen Grey.
             A little risk
             management goes a
             long way…..




   Certain
 problems
       are
seemingly
 timeless.

              http://www.incose.org/orlando/
Software Risks
  Uncertainty
  The risk may or may not
  happen.
  Loss
  What is the impact of the
  risk if it does occur?


Risk Categories
Project risks budgetary, schedule, personnel staffing and organization, resource,
customer, and requirements problems.

Technical risks - risks that threaten the quality and timeliness of the software to
be built. (design, implementation, interfacing, verification, maintenance)

Business risks - risks that threaten the viability of the software to be built.
Calculating Risk Exposure
 Risk of not delivering on time:
 RE = Probability of Risk X Impact of Risk
 Example:
 Probability that only 70% of the software components
 scheduled for reuse will in fact be integrated into the
 application.
 Risk that this will mean that the software cannot be
 delivered on time = 30%
 RE = 70% X 30% = 21%



                    Don’t hide from project risk.
                                 Face it head on!
Goal:
Risk is managed in respect to a specific goal.
What is the risk in respect to the goal?
A clearly defined goal with measurable success criteria
bounds acceptable risk.
Uncertainty
That which we do not know.
We can only be certain that the probability of a risk
occurrence is > 0% and < 100%.
Loss
Unless there is a potential for loss there is no risk.
Loss can be a bad outcome or a lost opportunity.
Time:
Time is a consumable resource. As time goes by viable
options tend to decrease. By managing risk we reduce wasted
time by using it to our advantage.
Choice
Without choice there is no risk management.
Doing something or doing nothing should be a consciencious
choice.
Make intelligent decisions:
- based on awareness, insight, and understanding of risk. Risk
management provides a process to communicate risk
information and provide visibility into software risks at all
project levels.
Resolve Risk:
Develop & execute a risk action plan to resolve risk.
Key is to find risk when there is still time to take action, &
knowing when to accept a risk.
Prevent Problems
Resolution of software risk prevents problems and surprises.
Risk Mitigation Plan

 What are you going to do
 about the risk?
 Three strategies:
    Entirely remove the risk by
    early intervention.
    Reduce the probability of the
    risk occurring.
    Reduce the impact if it does
    occur.

 Deliverable
    A risk analysis
    Risk mitigation plan.
Sample Risk Table
RMMM = Risk Mitigation, Management, and Monitoring plan
                                Risk Table
Risk                Category       Prob.          Impact       Risk Exp.
Are the best
people            staff             55%         catastrophic
available?

Are enough
people            staff             63%           critical
available?

Have staff
received the
                  staff             25%           marginal
necessary
training?

Is a SW
management        environment       40%          negligible
tool available?

1-Catastrophic, 2-Critical, 3-Marginal, 4-Negligible
Risk averse people:                    Risk seeking people:
   I like being dependable and I’m         I like action, and I act
   usually punctual.                       impulsively at times.
   I am not likely to take chances.        I seek excitement for the thrill of
   I am responsible and prefer to          the experience.
   work efficiently.                       I am resourceful and prefer not
   I am more service oriented than         to plan or prepare.
   self oriented.                          I am more self oriented than
   I value institutions and observe        service oriented.
   traditions.                             I like to anticipate another
                                           person’s position.

Risk neutral people:
   I trust my intuition, and I am comfortable with unknown.
   I think about the future and have long-range objectives.
   I am naturally curious and often ask, “Why?”
   I enjoy generating new ideas.
   I work best when I am inspired.
Risk Deliverable
  Identify risks for your project.
  Rank each risk according to probability.
  Rank each risk according to impact.
  1-Catastrophic, 2-Critical, 3-Marginal, 4-Negligible
  Order risks according to Risk Exposure.
  Decide which risks you need to mitigate.
  Create risk mitigation action items for each of those
  risks.
  Track all identified risks on your website.
During class today you may sign up for a debate topic. Each
group will then pull numbers to decide who will argue on which
side of the debate (for and against).
Each group member must make at least one comment before
anyone is allowed to make more than one comment during the
debate; if you are shy, go first and make one of the obvious points.
Once everyone has spoken once, group members may contribute
at will during the group's turn.
The "floor" will alternate between teams in short intervals,
controlled by the clock.
A good strategy is to know BOTH sides of each question so you
can be prepared not only to carry your own argument, but also
prepared to refute the arguments THEY are likely to make.
Debate # 1: Agile vs. Planned
A. Requirements should be developed upfront so that you can manage
the design of the software product and taking all stakeholders needs into
account. Changes to requirements should then be carefully managed.
B. As change is inevitable, it is a waste of time to specify all the system’s
requirements up front. Agile development which proposes no big upfront
design is much more effective.


Debate # 2: Personable vs. skilled
You have two candidates for a position that is quite critical
technically, and at the heart of a somewhat extensive project. One
person is very knowledgeable, and an outstanding coder, but does not
get along with people, is arrogant, and is not communicative. The
other person is O.K. technically, but a really a super personality
that communicates well, and makes others around her better. In this
case you should just face facts and hire the monster coder.
Debate # 3: Prototyping
Even though you will lose some time, it is better to build a prototype
running system, which is then completely discarded, before building your
final system. This way you can get a feel for both the technology, and for
how the final version should be designed, thus doing a much better job.
This is in contrast with carefully designing, and then implementing, your
system right the first time.

Debate # 4: Value of communication
The idea that excellent communication in a group is necessary is
a myth: what really matters is people getting their job done without a
lot of focus on talking about it.


Debate # 5: Bunch of coders
To get a project completed all you need is a bunch of people who
know how to write code.
Debate # 6: Hackers
Hackers that just snoop around serve a useful purpose, because they
identify weaknesses in a system without doing any permanent harm.
They should not be prosecuted.

Debate # 7: Whistleblowing
As an IT professional, my job is to build whatever software system my
boss requests me to build. If I notice a weakness in the system that could
possibly harm people (such as weak security that might enable personal
information to be exposed), it is certainly not my responsibility to be a
whistleblower. The responsibility for these decisions lies with my boss.
Debate # 8: Outsourcing
As an IT professional in the U.S. I will do everything I can to protect future
IT jobs against being outsourced.
    1.   Agile vs. Planned
    2.   Personable vs. skilled
    3.   Prototyping
    4.   Value of communication
    5.   Bunch of coders
    6.   Hackers
    7.   Whistle blowers
    8.   Outsourcing

Each person gets 5 points to ‘vote’ for the debate they want to do. Use
   all the points together or spread over various topics.

Debate teams will be announced on Wednesday.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:3/21/2012
language:
pages:21
yaohongm yaohongm http://
About