ITEC 4010: Systems Analysis and Design II.

1
ITEC 4010 Systems Analysis and Design II.
Lecture 12 Risk Management

• Professor Peter Khaiter

2
Topics

• Elements of Risk management
• Risk identification
• Risk Analysis
• Risk Prioritization
• Risk Control

3
Risk Management

• Risk Assessment
• Risk Control
• Different Levels of Risk

4
Risk Management (cont.)
Figure 12-1. Risk management tree.
5
Risk Assessment

• Risk Identification
• Produces a list of risks that have the potential
  to disrupt the projects schedule
• Risk Analysis
• Assesses the likelihood and impact of each risk
  and the risk levels of alternative practices
• Risk Prioritization
• Produces a list of risks prioritized by impact.
  This list serves as a basis for risk control

6
Risk Control

• Risk-management planning
• Produces a plan for dealing with each significant
  risk. It also makes sure that the risk-management
  plans for each of the individual risks are
  consistent with each other and the overall
  project plan
• Risk resolution
• The execution of the plan for dealing with each
  significant risk
• Risk monitoring
• The activity of monitoring progress toward
  resolving each risk item. Can also include the
  ongoing activity of identifying new risks and
  feeding them back into the risk management process

7
Risk Identification

• First step in managing risk is to identify the
  factors that pose a risk to your schedule
• Three general risks to avoid
• Making one of the classic mistakes described in
  lecture 10
• Ignoring the development basics described in
  lecture 11
• Failing to actively manage risks described in
  this lecture
• In addition to these there are many other types
  of risks can be classified by where they occur
  in SDLC

8
Most Common Schedule Risks

1. Feature creep
2. Requirements or developer gold-plating
3. Shortchanged quality
4. Overly optimistic schedules
5. Inadequate design
6. Silver-bullet syndrome
7. Research-oriented development
8. Weak personnel
9. Contractor failure
10. Friction between developers and customers

9
Complete List of Schedule Risks

• Schedule Creation
• Schedule, resources, and product definition have
  all been dictated by the customer or upper
  management and are not in balance
• Schedule is optimistic, best case (rather than
  realistic, expected case)
• Schedule omits necessary tasks
• Schedule was based on the use of specific team
  members, but those team members are not available
• Cannot build a product of the size specified in
  the time allocated
• Product is larger than estimated
• Reestimation in response to schedule slips is
  overly optimistic
• Excessive schedule pressure reduces productivity
• Target date is moved up with no corresponding
  adjustment to the product scope or available
  resources
• A delay in one task causes cascading delays in
  dependent tasks
• Unfamiliar areas of the product take longer than
  expected

10
Complete List of Schedule Risks (cont.)

• Organization and Management
• Project lacks an effective top-management sponsor
• Project languishes too long in fuzzy front end
• Layoffs and cutbacks reduce teams capacity
• Management or marketing insists on technical
  decisions that lengthen the schedule
• Insufficient team structure reduces productivity
• Management review/decision cycle is slower than
  expected
• Budget cuts upset project plans
• Management makes decisions that reduce the
  development teams motivation
• Nontechnical third-part tasks take longer than
  expected (budget approval, equipment purchase
  approval, legal reviews, security clearances etc)
• Planning is too poor to support the desired
  development speed
• Project plans are abandoned under pressure
• Management places more emphasis on heroics than
  accurate status reporting

11
Complete List of Schedule Risks (cont.)

• Development Environment
• Facilities are not available on time
• Facilities are available but inadequate
• Facilities are crowded, noisy, or disruptive
• Development tools are not in place by the desired
  time
• Development tools do not work as expected
  developers need time to create workarounds or to
  switch to new tools
• Development tools are not chose based on their
  technical merits and do not provide the planned
  functionality
• Learning curve for new development tool is longer
  or steeper than expected

12
Complete List of Schedule Risks (cont.)

• End-users
• End-user insists on new requirements
• End-user ultimately finds products to be
  unsatisfactory, requiring redesigns and rework
• End-user does not buy into the project and
  consequently does not provide needed support
• End-user input is not solicited, so product
  ultimately fails to meet user expectations and
  must be reworked

13
Complete List of Schedule Risks (cont.)

• Customer
• Customer insists on new requirements
• Customer review/decision cycles for plans,
  prototypes, and specifications are slower than
  expected
• Customer will not participate in review cycles
  for plans, prototypes, and specifications or is
  incapable of doing so resulting in unstable
  requirements and time-consuming changes
• Customer communication time (e.g. time to answer
  requirements-clarification questions) is slower
  than expected
• Customer insists on technical decisions that
  lengthen the schedule
• Customer micro-manages the development process,
  resulting in slower progress than planned

14
Complete List of Schedule Risks (cont.)

• Customer (cont.)
• Customer-furnished components are a poor match
  for the product under development, resulting in
  extra design and integration work
• Customer-furnished components are poor quality,
  resulting in extra testing, design, and
  integration work
• Customer-mandated support tools and environments
  are incompatible, have poor performance or
  functionality
• Customers will not accept software as delivered
• Customers have unrealistic expectations about
  speed of development

15
Complete List of Schedule Risks (cont.)

• Contractors
• Contractor does not deliver components when
  promised
• Contractor delivers components of unacceptably
  low quality, and time must be added to improve
  quality
• Contractor does not buy into the project and
  consequently does not provide the level of
  performance needed

16
Complete List of Schedule Risks (cont.)

• Requirements
• Requirements have been baselined but continue to
  change
• Requirements are poorly defined, and further
  definition expands the scope of the project
• Additional requirements are added
• Vaguely specified areas of the product are
  time-consuming than expected

17
Complete List of Schedule Risks (cont.)

• Product
• Error-prone modules require more testing, design,
  and implementation work than expected
• Unacceptably low quality requires more testing,
  design and implementation work to correct than
  expected
• Pushing the computer science state-of-the-art in
  one or more areas lengthens implementation
• Development of the wrong user interface results
  in redesign and implementation
• Strict requirements for compatibility with
  existing system require more testing, design and
  implementation than expected

18
Complete List of Schedule Risks (cont.)

• Product (cont.)
• Requirements for interfacing with other systems
  that are not the teams control
• Requirements to operate under multiple operating
  systems takes longer than expected
• Operation in an unfamiliar software or hardware
  environment causes unforeseen problems
• Development of a kind of component that is brand
  new to the organization takes longer than
  expected
• Dependency on a technology that is still under
  development

19
Complete List of Schedule Risks (cont.)

• External environment
• Product depends on government regulations, which
  change unexpectedly
• Product depends on draft technical standards,
  which change unexpectedly

20
Complete List of Schedule Risks (cont.)

• Personnel
• Hiring takes longer than expected
• Task prerequisites (e.g. training, completion of
  other projects, acquisition of work permit)
  cannot be completed on time
• Poor relationships between developers and
  management slow decision making and follow
  through
• Team members do not buy into the project and
  consequently do not provide the level of
  performance needed
• Low motivation and morale reduce productivity
• Lack of needed specialization increases defects
  and rework
• Personnel need extra time to learn unfamiliar
  software tools or hardware environments
• Personnel need extra time to learn unfamiliar
  programming languages

21
Complete List of Schedule Risks (cont.)

• Personnel (cont.)
• Contract personnel leave before project is
  complete
• New development personnel are added late in the
  project, and additional training and
  communications overhead reduces existing team
  member effectiveness
• Team members do not work together efficiently
• Conflicts between team members are not removed
  from the team, damaging overall team motivation
• Problem team members are not removed from the
  team, damaging overall team motivation
• Personnel most qualified for the project are not
  available
• Personnel most qualified for the project are
  available but are not used for political or other
  reasons
• Personnel with critical skills needed for the
  project cannot be found

22
Complete List of Schedule Risks (cont.)

• Personnel (continued)
• Key personnel are available only part time
• Not enough personnel are available for the
  project
• Peoples assignments do not match their strengths
• Personnel work slower than expected
• Sabotage by project management results in
  inefficient scheduling and planning
• Sabotage by technical personnel results in lost
  work or poor quality and requires rework

23
Complete List of Schedule Risks (cont.)

• Design and Implementation
• Overly simple design fails to address major
  issues and leads to redesign and reimplementation
• Overly complicated design requires unnecessary
  and unproductive implementation overhead
• Poor design leads to redesign and
  reimplementation
• Use of unfamiliar methodology results in extra
  training time and in reworks to fix first-time
  misuses of the methodology
• Product is implemented in a low-level language
  (e.g., assembler) and productivity is lower than
  expected
• Necessary functionality cannot be implemented
  using the selected code or class libraries
  developers must switch to new libraries or
  custom-build the necessary functionality

24
Complete List of Schedule Risks (cont.)

• Design and Implementation (cont.)
• Code or class libraries have poor quality,
  causing extra testing, defect correction, and
  rework
• Schedule savings form productivity enhancing
  tools are overestimated
• Components developed separately cannot be
  integrated easily, requiring design and rework

25
Complete List of Schedule Risks (cont.)

• Process
• Amount of paperwork results in slower progress
  than expected
• Inaccurate progress tracking results in not
  knowing the project is behind schedule until late
  in the project
• Upstream quality-assurance activities are
  shortchanged, resulting in time-consuming rework
  downstream
• Inaccurate quality tracking results in not
  knowing about quality problems that affect the
  schedule until late in the project
• Too little formality (lack of adherence to
  software policies and standards) results in
  miscommunications, quality of problems, and
  rework
• Too much formality (bureaucratic adherence to
  software policies and standards) results in
  unnecessary, time-consuming overhead

26
Complete List of Schedule Risks (cont.)

• Process (cont.)
• Management-level programs reporting takes more
  developer time than expected
• Half-hearted risk management fails to detect
  major project risks
• Software project risk management takes more time
  than expected

27
Risk Analysis

• After identifying the risks the next step is to
  analyze each risk to determine its impact
• Can be used to choose among several development
  options
• Can be used to manage the risks associated with
  an option already chosen

28
Risk Exposure (RE)

• Risk unexpected loss
• Risk Exposure (RE)
• Equal to the probability of the unexpected loss
  multiplied by the size of the loss
• E.g. if you think theres about a 25 chance that
  it will take 4 weeks longer than expected to get
  your project approved, the risk exposure would be
  25 multiplied by 4 weeks which equals 1 week

29
Example of Risk-Assessment Table

• Risk Probability of Loss Size (weeks)
  Risk Exposure
• (weeks)
• Overly optimistic 50 5 2.5
• schedule
• Addition of requirement to 25 20
  5.0
• fully support automated
• updates from the mainframe
• Additional features added 35
  8 2.8
• by marketing
• New programming tools 30 5 1.5
• Do not produce the promised
• Savings

30
Estimating Size of Loss (in terms of time)

• You might be able to precisely pin down estimates
  of loss
• E.g. you might know a project will approved
  either Feb. 1 or might be a month later, on March
  1
• Or the loss may not be easy to estimate
• You might break down the loss into smaller
  losses, estimate these and then combine the
  estimates
• E.g. if you are using 3 new programming tools,
  you could estimate the loss resulting from each
  tool not producing its expected productivity gain

31
Estimating Probability of Loss

• Have the person most familiar with the system
  estimate the probability of each risk, and then
  hold a risk-estimate review
• Use Delphi or group-consensus practices
• You have each person estimate each risk
  individually and then discuss the rationale
  behind each estimate, especially the very high
  and low ones. Continue the process in successive
  rounds until the estimates converge
• Use betting analogies (to calibrate your guess
  estimation)
• E.g. Would you take this bet? If the facilities
  will be ready on time, you win 125. If theyre
  not ready on time I win 100 Refine the bet
  until youd be as happy being on either side of
  it. The risk probability is the dollar amount on
  the downside divided by the total dollar amount
  at stake e.g. the probability of the facilities
  not being ready on time would be 100 / (100
  125) 44

32
Estimating Probability of Loss (cont.)

• Use adjective calibration
• First have each person choose the risk level from
  a verbal scale of phrases like highly likely,
  very good chance, probable, likely, improbable,
  unlikely, and highly unlikely. Then convert the
  verbal assessments to quantitative assessments

33
Total Project Overrun and Buffers

• The expected overrun for a project is the sum of
  all the weeks in the Risk Exposure column on the
  previous slide
• If for example a 25 week project has an expected
  total overrun of 12 weeks you have a problem that
  calls for active risk management
• What you could do
• Try to reduce risk
• Adjust your schedule to include risk (i.e. add it
  to your schedule as a buffer)
• Publish a schedule with a plus-or-minus qualifier
  for each risk and adjust the schedule as risk
  materializes

34
Risk Prioritization

• Once youve created the list of schedule risks
  the next step is to prioritize the risk in order
  to focus your risk-management efforts
• Projects typically spend 80 percent of their
  money fixing 20 of their problems
• Can develop a table to help you focus on the most
  important 20 -- simply take the Risk Assessment
  table from slide 28 and put the risks in
  descending order of risk exposure (i.e. sort it
  so that risks that would cause the greatest delay
  in weeks are at the top)
• Sorting this way creates a list of risks that are
  ordered roughly by priority and you might want to
  address those at the top first
• There is little point in managing a low-loss risk
  that also has a low likelihood of becoming a
  problem
• The priority ordering is only approximate since
  the numbers we used are all estimates

35
Risk Control

• After youve identified your projects risks,
  analyzed their probabilities and magnitudes and
  prioritized them, you are ready to control them
  (i.e. risk-management planning, resolution and
  monitoring)
• Risk Management Planning
• Focus is to develop a plan to handle each of the
  high-priority risks you have identified
• Can be as simple as a paragraph for each risk
  that describes the who, when, where, why and how
  of each risks management
• Should also include provisions for monitoring the
  risks and identifying emerging risks

36
Risk Control (cont.)

• Risk Resolution
• Avoid the risk
• Dont do the risky activity, e.g. take
  responsibility for most of the system design but
  not for the unfamiliar part of the system (I.e.
  have the client design that part)
• Transfer the risk from one part of a system to
  another
• Sometimes a risk in one part of the project isnt
  as risky in another part of the project and you
  can move it
• E.g. have client review and approve your design,
  effectively transferring responsibility for some
  risk to them
• In general get the risk off the critical path, so
  that if the risk occurs the project as a whole
  isnt delayed
• Buy Information about the risk
• E.g. develop a design prototype to test the
  feasibility of your approach
• E.g. bring in an outside consultant

37
Risk Control (cont.)

• Risk Resolution (cont.)
• Eliminate the root cause of the risk
• If part of the design of the project is very
  challenging, then recast that part of the system
  as a research project (and eliminate it from the
  version you are building)
• Assume the risk
• Accept the risk might occur but decide not to do
  anything about it, especially if the consequences
  are small and effort to avoid is large
• Publicize the risk
• Let upper management, marketing, and customers
  know about the risk and its consequence I.e.
  minimize the surprise theyll feel if it occurs

38
Risk Control (cont.)

• Risk Resolution (cont.)
• Control the risk
• Accept that the risk might occur, and develop
  contingency plans to handle it if you cant
  resolve it. Allocate extra resources to test the
  part of the system whose design you are worried
  about and plan for extra time to fix defects
• Remember the risk
• Build up a collection of risk-management plans
  that you can use on future problems

39
Means of Controlling the Most Common Schedule
Risks

• Feature creep
• Use customer-oriented practices
• Use incremental development practices
• Control the feature set
• Design for change
• 2. Requirements gold-plating or developer
  gold-plating
• Scrub requirements
• Timebox development
• Control the feature set
• Use staged delivery
• Use throwaway prototyping
• Design to schedule

40
Means of Controlling the Most Common Schedule
Risks (cont.)

• 3. Shortchanged quality
• Allow time for QA activities and pay attention to
  quality-assurance fundamentals
• 4. Overly optimistic schedules
• Use multiple estimation practices, multiple
  estimators and automated estimation tools
• Use principled negotiation
• Design to schedule
• Use incremental development practices
• 5. Inadequate design
• Have an explicit design activity and schedule
  enough time for design
• Hold design inspections

41
Means of Controlling the Most Common Schedule
Risks (cont.)

• 6. Silver-bullet syndrome
• Be skeptical of productivity claims
• Set up a software measurement program
• Set up a software tools group
• 7. Research-oriented development
• Dont try to do research and maximize development
  speed at the same time
• Use a risk-oriented lifecycle
• Manage risks vigilantly
• 8. Weak personnel
• Staffing with top talent
• Recruiting and scheduling key team members long
  before project starts
• Training
• Team building

42
Means of Controlling the Most Common Schedule
Risks (cont.)

• 9. Contractor failure
• Check references
• Assess the contractors ability before hiring it
• Actively manage the relationships with the
  contractor
• 10. Friction between developers and customers
• Use customer-oriented practices

43
Risk Control (cont.)

• Risk Monitoring
• Risks come and go as the project progresses so
  you need to do risk management
• You can create a Top-10 list of risks for your
  project
• This list can contain each risks
• Current rank
• Its previous rank
• The number of times its been on the list
• A summary of steps taken to resolve the risk
• On a rapid-development project, the project
  manager should review the Top-10 list weekly

44
Example of a Top-10 Risks List

• This Last Weeks Risk
  Risk
  
• 
  
  Resolution
• Week Week on List
  Progress
• 1 1 5
  Feature creep Staged
• 
  delivery
  adopted
• 2 5 5 Inadequate
  design Identification and
• selection of expert
  reviewers
• 3 2 4 Test lead not on
  Top candidate has
• board yet been offered job

45
Risk Control (cont.)

• Interim Postmortems
• A fast track project should also include
  postmortems conducted throughout the project
• Many project managers wait until the end to do a
  postmortem, which helps with the next project but
  doesnt do much for your current project
• For maximum effectiveness conduct a small-scale
  postmortem after you complete each major milestone

46
Risk Control (cont.)

• Risk Officer
• Some organizations appoint a risk officer to be
  alert to risks to the project and keep managers
  and developers from ignoring them
• Helpful to have a person to play devils
  advocate to look for all of the reasons the
  project may fail
• May be a full time or part time position
• For psychological reasons shouldnt be the
  project manager

47
Risk, High Risk, and Gambling

• For purposes of rapid development, some projects
  are risks, some are high risks and some are
  gambles
• High risk and rapid development make a less
  compatible combination as risks tend to extend
  development schedules
• Many projects require you to commit to an
  ambitious development schedule even when the
  project involves many risks
• With two or three high-risk areas, even your best
  schedule projections will be nearly meaningless
• At the extreme end of the risk scale, some
  projects are scheduled so aggressively, they
  become out-and-out gambles they are more like
  the purchase of a lottery ticket than a
  calculated business decision!

48
Risks and Rapid Development

• About one-third of all projects have an
  impossible combination of schedules, feature sets
  and resources dictated to them before they even
  start
• Not much incentive for risk management in such
  cases when the project starts off with a 100
  chance of failure!
• With no chance of meeting their schedules it
  becomes rational to gamble on 1000-1 long shots
  such as the code-and-fix development strategy
• Such projects, which know they need maximum
  development speed, ironically become the projects
  that are most likely to throw effective, proven
  speed-oriented practices out of the window