Risk Flashcards
(10 cards)
Name six ways to reduce the risk associated with not meeting a project schedule/end-date. (MSC BIBO)
Create a master project schedule and strive to adhere to it
Schedule the riskiest tasks as early as possible to allow time for failure recovery
Maintain close focus on critical and near-critical activities
Put the best workers on time-critical tasks
Provide incentives for overtime work
Shift high-risk activities in the project network from series to parallel
Organize the project early, and staff it adequately
Provide project and feeding buffers (contingency reserves)
Name four ways to reduce the risks associated with not meeting budget targets (CMILE)
Identify and monitor the key cost drivers
Use low-cost design alternative reviews and assessments
Verify the system design and performance through modelling and assessment
Maximize usage of proven technology and commercial off-the-shelf equipment
Provide contingency reserves in the project budgets
Perform early breadboarding, prototyping, and testing on risky components
One approach to expressing technical nsk is to rate the project end-item or primary 8
process as being high, medium or low according to the following features: maturity,
complexity, quality and concurrency. Briefly describe each of these sources of technical risk
In a project.
Maturity: low
How experienced or knowledgeable the project team is in the project technology. An end-item
or process that takes advantage of existing experience and knowledge is less risky than one that
is innovative, untried, or cutting edge
- Complexity: high
How many steps, elements, or components the product or process contains and how tightly are
they interrelated. Ceteris paribus, an end-item or process with numerous, interrelated steps or
components is riskier than one with fewer steps and simpler relationships
- Quality: low
How producible, reliable, and testable is the end-item or process? In general, an end-item or
process that has been produced and is reliable and/or testable is less risky than one that has yet
to be produced or has unknown reliability or testability.
- Concurrency or dependency: high
To what extent do multiple, dependent activities in the project overlap? Activities performed in
sequence with no overlap are less risky than activities that overlap (e.g. the discrete-staged
approach is less risky than fast-tracking)
Give seven (7) ways on how you could reduce/control the technical risk of
your project - that is: how could you reduce the likelihood or Impact (or both) associated
with technical unwanted events
- Employ best technical team
- Base decisions on models and simulations of key technical parameters
- Use Mature, computer-aided systems engineering tools
- Use parallel development on high-risk tasks
- Provide the technical team for incentives for success
- Hire outside specialists for critical review and assessment of work
- Perform extensive tests and evaluations
- (Minimize systems complexity)
Risk = f(likelihood, impact)
Briefly explain this statement to someone t hat is unfamiliar with the concept of project risk
management, and give an example of when a project would be considered ‘risky
what does RC or equivalent risk value = and what does it mean
risk consequence; f (likelihood, impact) = Product of likelihood and impact.
Discuss five high-level strategies that deal with risk
Risk avoidance: avoid the risk by changing the design
Risk transfer: passing on the risk during handover or sharing the risk with another
party
Risk reduction or control: take measures to reduce the risk and control it
Contingency plan: if the risk occurs, there is a plan in place to handle it
Accepting the risk: being aware of the risk, but doing nothing
“Risk management includes being prepared for the unexpected.” Briefly explain what
is meant by this statement
Having identified myriad risk hazards and consequences and prepared all kinds
of controls and safeguards, people can be led to believe that everything that
possibly could go wrong has been anticipated and covered; thus, when something
still goes wrong, it catches them completely off guard. Although it is true that risk
planning can cover many or most risks, it can never cover all of them. Thus, risk
planning should) (be tempered with the concept of “non-planning” or Napoleon’s approach, which
is to expect that something surely will go wrong and to be ready to find ways to
deal with it as it emerges. This is as important to coping with risk as is extensive
planning and believing that all risks have been covered.27
Can and should risk be eliminated from project?
Managing risk does not mean eliminating it, although some managers don’t
know that. The prime symptom of “trying to eliminate risk” is
micromanagement: excessive controls and documentation requirements, and
trivial demands for the authorization of everything. Projects inherently entail
uncertainty and risk. Micromanagement is seldom appropriate and for some
projects it can be disastrous, particularly when the projects involve the new,
untried, and untested. When management tries to eliminate risk, it stifles
innovation and, say Aronstein and Piccirillo, “forces a company into a plodding,
brute force approach to technology, which can be far more costly in the long run
than a more adventurous approach where some programs fail but others make
significant leaps forward.”29 The appropriate risk management strategy for most
projects is to try to accommodate and mitigate risk, not to avoid or eliminate it