E. Risk Management - General
• Part 3.3 of “3. Managerial process” of the software
development plan template presented earlier was headed
– “3.3 Risk management”
• We next present some more detail on “Risk Management”.
• First, we recall the content “3.3 Risk management” of the
software development plan template.
• To begin with, §3.3 suggested that to help
– A. Identify risks
• use following (not necessarily complete) checklist:
1
E. Risk Management - General
No.
Potential area of risk
1
Proven business case? Funding approved? Right type of contract
2
Areas of contract ill-defined or not agreed?
3
Customer: sufficient access? effective decision making procedures?
4
User committed? Quality & stability of user requirements
5
Acceptance criteria specified in contract?
6
Level of definition & stability of external interfaces
7
Adequacy & availability of resources including team members.
8
Availability & quality of tools.
9
Team member training & experience //// Definition of responsibilities
10
Short time scales. Rapid build-up of staff required. Over-optimistic planning.
11
Technical novelty of the project. Technical complexity of the system.
12
Demanding performance, reliability, availability, maintainability requirements
13
New development environment. Mis-match between development and target
14
Bought-in items
2
E. Risk Management - General
• Then, §3.3 suggests that one should provide
– B. An assessment of risk
• A useful approach to doing this, as a basis for comparing risks, is
to prepare a risk map of the following form. Each identified risk
is assigned to a cell of the map.
Likelihood
Of
Occurrence
Potential
High
Medium
Low
Large
Scale
Moderate
Of
Impact
Small
3
E. Risk Management - General
• Finally, §3.3 of the plan template indicates that one should
– C. Provide a plan for reducing any identified risks
We next expand on some of these ideas. The following
diagram (from Yeates & Cadle) is a useful framework for
the discussion:
4
E. Risk Management - General
Plan risk management
approach
Risk management
plan
Identify risks
Assess risks
Risk register
Plan risk responses
Carry out risk reduction
actions
Activities
Risk objectives
achieved
Outputs/Outcomes
5
E. Risk Management – Risk Identification
• The following points (Yeates & Cadle) give some more pointers on broad areas
to be considered for possible risks.
• Before getting into these, an important general point is that once a risk has
been identified then it is worth describing it precisely and clearly. For example
(Yeates & Cadle) a risk identified as “poor contractor performance” is rather
vague particularly in terms of what to do about it. Much better to be more
specific as, say,
– “Contract staff do not work at the pace assumed in the estimates
– Contract staff do not grasp and conform to the developer’s programming
standards
– Contract staff are difficult to manage with inexperienced team leaders”
6
E. Risk Management – Risk Identification
• The commercial background:
•
•
•
•
•
•
Unsound business case?
Funding not approved?
Several suppliers/contractors unclearly related
Inappropriate contract type (e.g. “fixed price” for a research project)
New business area where contractor has little experience
Immovable end-dates or price ceilings
– May be able to avoid such risks by a pre-project review of both commercial and
technical issues. Maybe can then structure project appropriately.
• The contract:
•
•
•
•
Scope of work is ill-defined or not agreed between parties?
Onerous penalties for delays or under-performance
Unclear payment schedule, not linked to tangible milestones
No signed contract so that work proceeds on an informal basis
– Mitigate such risks by documenting any assumptions and asking customer to
approve them.
7
E. Risk Management – Risk Identification
• The customer:
• Unclear customer management structure?
• Access to customer decision-makers difficult?
• More than one customer with different levels of commitment to the project
– Early on, seek to get to know the various parties involved …
• The users:
•
•
•
•
•
Not committed to the project or do not have enough time for it
Unfamiliar with technology and need training
Unwilling to change work practice to accommodate the new system
New system may threaten the jobs of existing workers
Very different views of customer senior management and end users
– Make every effort to involve the users in the project.
8
E. Risk Management – Risk Identification
• Acceptance:
• Acceptance criteria not defined, or only vaguely defined, in the contract?
• Has customer discretion to delay acceptance of the system unduly?
– Acceptance is best handled incrementally – have an agreed, “tight” enough
requirement specification and come to agreement with the customer on (for
example) the acceptance plan, then on the test specifications (design/cases), then
on the results of individual tests and finally on the whole system.
• Functional requirements (see previous point):
• Requirements may not have been formally “signed-off” before starting development
• Requirements may be incomplete or inconsistent or insufficiently detailed
• Mis-match between customer and developer’s understanding of the requirements.
– Review functional requirements rigorously, including by customer representatives
and experts outside the development team. Apply a formal configuration
management system to manage versions of the requirements and to control
changes.
9
E. Risk Management – Risk Identification
• Technical challenges:
•
•
•
•
Very complex technically?
Use of unfamiliar methods or tools or hardware?
Design may make testing difficult?
Need to interface to other systems & to test these interfaces by simulation?
– Obtain additional technical expertise. Establish a complete overall design
before doing detailed design of individual components.
• Performance, Reliability, Availability, Maintainability, Safety, Security:
• May be stringent requirements under some or all of the above headings. For example, might be
hard to test performance prior to system testing.
– Identify any challenging performance requirements and define precisely how
they will be verified. Possibly, implement critical functions early in the
project.
10
E. Risk Management – Risk Identification
• The project plan:
•
•
•
•
•
•
•
•
Project manager not involved in bid phase?
Very tight time-scales?
Rapid build-up of staff needed?
Does plan allow for re-visiting work from earlier phases (e.g. for revising design during coding)?
Estimates not based on solid metrics or methods?
Not enough contingency included?
Excessive reliance on a few key staff
Milestones too far apart or deliverables not clearly enough defined or work packages too large
– Project manager should review the plan rigorously especially if not involved in the
bid. Allow for things going wrong and therefore build in adequate contingency.
• Developer’s skills:
• Key staff may be new to their roles & inexperienced in business or technology terms, or both.
• Senior technical people may be pursuing interesting, but unproven, methods or technologies.
– Re-examine estimates if these risks exist. Possibly, seek additional expertise (e.g. consultant
support).
11
E. Risk Management – Risk Identification
• Project staffing:
• Staff not available when needed, or may have to join too early
• Staff may have other, diverting commitments
• Too many inexperience staff, leading to effort or elapsed time overruns, or too
many senior staff, leading to cost overruns
• Unproven customer or contract staff
• Coinciding with a high staff turnover rate?
– Aim to take on staff just when needed. If people are shared with
another project then negotiate.
• Development environment:
• New to the developer?
• Development may not match the “live” environment
• Is there adequate access to the development environment?
– Provide training if environment is new. Negotiate for access if necessary.
12
E. Risk Management – Risk Identification
• Tools and Methods:
• Unfamiliar programming language(s)?
• Unfamiliar methodologies (e.g. UML)
• Unfamiliar tools – e.g. often there are special SW systems used in testing
– Provide training and allow for familiarisation. Sometimes can be
useful to use a small area of the project as a “pilot”.
• Target hardware architecture:
•
•
•
•
New or unproven, not used before for such a purpose?
Some hardware may be custom built and not available until late in project.
Doubts about hardware capacity (e.g. in performance terms)
Hardware from different suppliers to be integrated?
– Test on target hardware as early as possible to allow time to rectify
problems. Do careful “sizing and timing” estimates.
13
E. Risk Management – Risk Identification
• Bought-in items:
• Third party software or software to be used – what experience of the suppliers?
• Suppliers may be in poor financial condition with a risk of going out of business
• May be difficulty in testing bought-in items (e.g. may not have access to source code
or development documentation or history).
– Examine technical and financial credibility of potential suppliers
carefully. Use of “open” rather than proprietary solutions makes it
possible to switch suppliers if need be. Include safeguards in the contract
in the event that a supplier goes out of business; in particular
• A contractual arrangement (with the supplier) that a copy of supplied software be
placed in “escrow” (i.e. held by a third party) and released in the event of bankruptcy
of the supplier.
• Having a “force majeure” clause in the contract with the customer whereby they are
released from their obligations if hit by events outside their control.
14
E. Risk Management – Risk Assessment
• After identifying and describing each risk, it is
then necessary to make an assessment of its
– Impact (if it occurs)
– Likelihood (of it occurring)
• Example (Yeates & Cadle) - we had previously the
risk description:
– “Contract staff do not work at the pace assumed in the estimates
– Contract staff do not grasp and conform to the developer’s
programming standards
– Contract staff are difficult to manage with inexperienced team
leaders”
15
E. Risk Management – Risk Assessment
(Example continued) The impacts of the first point
particularly (slowness) could include,
– Failure to produce unit-tested code by the planned date
– Inability to begin system test on time
– Need to re-schedule system test to work around modules not yet
available
– Switch of effort to other staff
• The scale of these impacts will depend on how much of the
work is done by contract staff. Often a rough classification
of scale of impact is enough e.g.
– Large impact - could extend project by > 10%
– Medium impact
- could extend project by 5%-10%
– Small impact - could extend project by < 5%
16
E. Risk Management – Risk Assessment
• (Example continued) The likelihood or probability of the
risk actually occurring depends on the circumstances. For
example,
– High probability if contractors with the right skills were rare,
company has no previous experience of these contractors or if their
CVs could not be checked independently)
– Low probability if plan is to use people who were previously hired
successfully or for whom there are favourable reports from
previous employers.
• Scale of probabilities might be, for example,
– High probability
> 30%
– Medium probability 10%-30%
– Small probability < 10%
17
E. Risk Management – Risk Assessment
• As previously mentioned, one can use a
“risk map” to compare risks once an impact
and its likelihood have been decided for
each risk. For example, if our “contract
staff” example has a large impact but a low
probability of occurring it would appear on
the risk map as follows (next slide). The
complete map would include an entry for
each identified risk.
18
E. Risk Management – Risk Assessment
Likelihood
Of
Occurrence
Potential
Large
High
Medium
Low
Contract Staff
Scale
Moderate
Of
Impact
Small
• One other aspect to assess is the urgency of a risk (when is it likely to
materialise, when is action needed). Might mean sometimes that a less
severe risk is addressed with more urgency than a more severe one.
19
E. Risk Management – Actions to deal with Risks
• Two possible types of action:
– Avoidance – try to prevent the risk occurring (i.e. deal with the
likelihood). May not always succeed.
– Mitigation – Reduce impact if a risk materialises (i.e. deal with
the impact).
• Example (continued):
– Avoidance – do not use contract staff (but may not have enough
staff i.e. creates a secondary risk!)
– Mitigation
• Use only contractors previously used
• Test contractors to check their work rate
• Conduct detailed, searching interviews.
20
E. Risk Management – Planning & Control
• The initial identification of risks and how to deal with
them is one aspect of risk management. However, as a
project proceeds the nature of risk changes:
– Some of the predicted risks materialise and have to be dealt with,
hopefully by the planned mitigations
– Some predicted risks disappear
– New risks appear, not foreseen initially.
• So, there needs to be a process of re-visiting and revising
the “risk register” (see below) regularly, and a forum for
“risk owners” (see below) to meet. The plan for “Risk
Management” throughout a project would normally be part
of the overall project plan.
21
E. Risk Management – Risk Register
• It is recommended that a risk register be maintained for a
project (in the form of a document or a spreadsheet or …)
containing, for each risk,
–
–
–
–
–
–
–
A reference (identifier)
Title & description
Current status (e.g. candidate, live, closed)
Potential impact(s) (describe, impact, likelihood)
Risk owner (person who will carry out the associated risk actions)
Actions (avoidance and/or mitigation)
Action log (record of progress made in carrying out the actions)
• The Risk Owner must be someone with sufficient
knowledge about the risk but also someone who has the
necessary resources and authority.
22
E. Risk Management – Further concepts
• It is possible, and may be necessary in very
large and complex projects, to address risk
in a much more detailed way than we have
described.
• For example, one could create simulation
models of a project to answer “What if”
questions. Probability and statistics would
typically be used as a basis for such models.
23