12.0 risk management agile+evm (v10.2)

+12.0 Risk Management and Agile Software Development

The naturally occurring uncertainties (Aleatory) in cost, schedule, and technical performance can be modeled in a Monte Carlo Simulation tool. The Event Based uncertainties (Epistemic) require capture, modeling of their impacts, defining handling strategies, modeling the effectiveness of these handling efforts, and the residual risks, and their impacts of both the original risk and the residual risk on the program.

Risk Management is how Adults Manage Projects– Tim Lister

Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 ― 2016 532

A

Uncertainties are things we can not be certain about.

Uncertainty is created by our incomplete knowledge ‒ not by our ignorance.

Making decisions in the presence of Uncertainty requires making estimates of the impact of our decisions.

12. Risk Management

All Risk Comes from Uncertainty


+ Risk Management is about Making Decisions in Presence of Uncertainty

n All project work is uncertain.

n Agile development can inform Risk Management, but it itself is not Risk Management.

n Rapid feedback, small increments of produced software, close knit teams of developers with customers, all help reduce risk – but risk produced by uncertainty.

n Those risks still have to be managed outside the development processes of Agile, since they impact other aspects of the project beyond the production of software.

12. Risk Management

Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 ― 2016

534

1. Hope is not a strategy2. No single point estimate of cost or schedule can be correct3. Cost, Schedule, and Technical Performance are inseparable4. Risk management requires adherence to a well defined

process5. Communication is the Number One success factor

Five Immutable Principles of Risk Management

12. Risk Management

535Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 ― 2016Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 ― 2016 535

+What is Risk Management?

Risk management is an endeavor that begins with requirements formulation and assessment, includes the planning and conducting of a technical risk reduction phase if needed, and strongly influences the structure of the development and test activities.

Active risk management requires investment based on identification of where to best deploy scarce resources for the greatest impact on the program’s risk profile.

Management and staff shape and control risk, not just observe progress and react to risks that are realized. Anticipating possible adverse events, evaluating probabilities of occurrence, understanding cost and schedule impacts, and deciding to take cost effective steps ahead of time to limit their impact if they occur is the essence of effective risk management.

Risk management should occur throughout the lifecycle of the program and strategies should be adjusted as the risk profile changes.

12. Risk Management


536

+Core Elements of Program Risk Management†

n The effectiveness of risk management depends on the people who set it up and coordinate the risk management process

n On many program risk management consists only of having a policy and oversight

n If we treat red flags as false alarms rather than early warnings of danger this incubates the threats to program success

n Group think of dominate leaders often inhibits good thinking about risks

† Towards a Contingency Theory of Enterprise Risk Management Anette Mikes Robert Kaplan, Working Paper 13-063 January 13, 2014

12. Risk Management


537

+ Risk Management is How Adults Manage Projects – Tim Lister

Ale

ator

yE

pis

tem

ic

12. Risk Management


538

+ Individual Risks

n Risk Statement ‒ A concise description of an individual risk that can be understood and acted upon. Risk statements have the following structure: “Given that [CONDITION], there is a possibility of [DEPARTURE] adversely impacting [ASSET], which can result in [CONSEQUENCE]. †

n The CONDITION is a single phrase that describes the current key fact-based situation or environment that is causing concern, doubt, anxiety, or uneasiness.

n The DEPARTURE describes a possible change from the (agency, program, project, or activity) baseline project plan. It is an undesired event that is made credible or more likely as a result of the CONDITION.

n The ASSET is an element of the organizational unit portfolio (OUP) (analogous to a WBS). It represents the primary resource that is affected by the individual risk.

n The CONSEQUENCE is a single phrase that describes the foreseeable, credible negative impact(s) on the organizational unit’s ability to meet its performance requirements.


539

† NASA/SP-2011-3422 Version 1.0 November 2011

+Quick View of How to Manage in the Presence of Uncertainty and Risk†

n Uncertainty creates the opportunity for risk

n Reducing uncertainty may reduce risk

n Two types of uncertainty†

n One that can be reduced

n One that cannot

n A risk informed PMB starts with the WBS

n 8 steps are needed to build a risk informed PMB

Risk informed program performance management is the goal

† Distinguishing Two Dimensions of Uncertainty, Craig Fox and Gülden Ülkumen, in Perspectives of Thinking, Judging, and Decision Making

12. Risk Management


540

+ Sources of Uncertainty

n Lack of precision about the underlying uncertainty.

n Lack of accuracy about the possible values in the uncertainty probability distributions.

n Undiscovered Biases used in defining the range of possible outcomes of project processes.

n Natural variability from uncontrolled processes.

n Undefined probability distributions for project processes and technology.

n Unknowability of the range of the probability distributions.

n Absence of information about the probability distributions.

12. Risk Management


541

+ Some Words About Uncertainty

n When we say uncertainty, we speak about a future state of an external system that is not fixed or determined

n Uncertainty is related to three aspects of our program management domain:n The external world – the activities of the program

n Our knowledge of this world – the planned and actual behaviors of the program

n Our perception of this world – the data and information we receive about these behaviors

12. Risk Management


542

+ Some More Words about the Riskthat Results from Uncertaintyn Risk has two dimensions

n The degree of possibility that an event will take place or occur sometime in the future

n The consequences of that event, once it has occurred

n The degree of possibility is qualified as the Probability of Occurrence (event based) or a Probability Distribution Function (a distribution of variability's of a random number)

n The consequences are usually taken to be undesirable and qualified as the magnitude of harm and the remaining probability of a recurrence of the same risk.

12. Risk Management


543

+ Relationship between Uncertainty and Riskn Uncertainty is present when probabilities cannot be quantified in a

rigorous or valid manner, but can described as intervals within a probability distribution function (PDF)

n Risk is present when the uncertainty of the outcome can be quantified in terms of probabilities or a range of possible values

n This distinction is important for modeling the future performance of cost, schedule, and technical outcomes of a program

12. Risk Management


544

+ Uncertainties created Risk on Software Development Programs

Uncertainty

Irreducible(Aleatory)

Reducible(Epistemic)

NaturalVariability

Ambiguity

OntologicalUncertainty

ProbabilisticEvents

ProbabilisticImpacts

PeriodsofExposure

12. Risk Management


545

+ Epistemic Uncertainty and Aleatory Variability are both risk drivers†

EpistemicUncertainty

§ Epistemicuncertaintyisthescientificuncertaintyduetolimiteddataandknowledgeinthemodeloftheprocess

§ Epistemicuncertaintycan,inprinciple,beeliminatedwithsufficientstudy

§ Epistemic(orinternal)uncertaintyreflectsthepossibilityoferrorsinourgeneralknowledge.

AleatoryVariability

§ AleatoryuncertaintiesarisefromtheinherentrandomnessofavariableandarecharacterizedbyaProbabilityDensityFunction

§ Theknowledgeofexpertscannotbeexpectedtoreducealeatoryuncertaintyalthoughtheirknowledgemaybeusefulinquantifyingtheuncertainty

RandomnessWithKnowableProbabilities RandomnessWithUnknowableProbabilities

Theprobabilityofoccurrencecanbedefinedthroughavarietyofmethods.Theoutcomeis

aprobabilityofoccurrenceoftheevent

AProbabilityDensityFunction(PDF)generatesacollectionofrandomvariablesusedto

modeldurationsandcosts

† Uncertainty in Probabilistic Risk Assessment: A Review, A.R. Daneshkhan

12. Risk Management


546

+ Risk Chains – Across The WBS12. Risk Management


547

+ Risk Management Processes for Program ManagementnAn approach to programmatic and technical risk

12. Risk Management


548

TechnicalRiskManagement

TrackingandControllingPerformanceDeviations

Deliberatingandrecommendingadecision

alternative

Riskanalysisofdecisionalternatives,performingtradestudiesandranking

Proposingand/oridentifyingdecisionalternatives

FormulationofobjectivesHierarchyandTechnicalPerformanceMeasures

Stakeholderexpectations,requirementsdefinitionandmanagement

Designsolutions,technicalplanning

Designsolution,technicalplanning,

anddecisionanalysis

Technicalplanninganddecisionanalysis

Decisionanalysis,lessonslearned,

knowledgemanagement

Identify

Analyze

Plan

Track

Control

Decideandimplementdecision

alternatives

Communicate

12. Risk Management


549

+Deterministic versus Probabilistic Planning at the Program Level

BaselinePlan

80%

Mean

MissedLaunchPeriod

LaunchPeriod

ReadyEarly

Oct 07

Nov 07

Dec 07

Jan 08

Feb 08

Mar 08

Apr 08

May 08

Jun 08

MarginRisk

Margin

Current Planwith risks is thestochastic schedule

CD

R

PD

R

SR

R

FRR

ATL

O

20%

Aug 05 Jan 06 Aug 06 Mar 07 Dec 07 Feb 08

Current Planwith risks is thedeterministic schedule

Plan

TitleProbabilitydistribution varies astime passes

12. Risk Management


550

12. Risk Management


+Core Elements of Risk Management†

n The effectiveness of risk management depends on the people who set it up and coordinate the risk management process

n On many program risk management consists only of having a policy and oversight

n If we treat red flags as false alarms rather than early warnings of danger this incubates the threats to program success

n Group think of dominate leaders often inhibits good thinking about risks

† Towards a Contingency Theory of Enterprise Risk Management, Anette Mikes Robert Kaplan, Working Paper 13–063 January 13, 2014

12. Risk Management


552

+How to Manage in the Presence of Uncertaintyn All project work is Uncertain

n Uncertainty creates risk

n Reducing uncertainty can reduce risk

n Two types of uncertainty†

n One that can be reducedn One that cannot

n A risk informed PMB starts with the WBS

n 8 steps are needed to build a risk informed PMB

Risk informed program performance management is the goal

† Distinguishing Two Dimensions of Uncertainty, Craig Fox and Gülden Ülkumen, in Perspectives of Thinking, Judging, and Decision Making

12. Risk Management


553

+ Relationship Between Uncertainty and Riskn Uncertainty is present when probabilities cannot be quantified in a

rigorous or valid manner, but can described as intervals within a probability distribution function (PDF).

n Risk is present when the uncertainty of the outcome can be quantified in terms of probabilities or a range of possible values

n This distinction is important for modeling the future performance of cost, schedule, and technical outcomes of a program.

n The work in the Backlog contains reducible and Irreducible uncertainty which creates reducible and irreducible risk.

n This is unavoidable and applying Agile does not make that uncertainty go away.

12. Risk Management


554

+

12.1 Managing Risk on Agile Development Projects

n Risks occurs at Every Stage of an Agile Project

n Product Vision

n Product Roadmap

n Product Backlog

n Release Planning

n Sprint Planning

n Sprint Backlog

n Daily Scrum

n Sprint Review

n Sprint Retrospective

n Risk Management needed at every stage as well

Agile methodologies, when implemented correctly, inherently reduce risk in product development.

But Agile methods are NOT Risk Management.

12. Risk Management


Risk is always present.Risk is

unavoidable. Risk is created by

Uncertainty.Risks are

applicable to all elements of an

Agile projects for all stages of the

project.

12. Risk Management


+ Product Vision

n The product vision statement helps unify the project team's definition of product goals, mitigating the risk of misunderstandings about what the product needs to accomplish.

n While creating the product vision, the project team may consider risk on a very high level, in conjunction with the marketplace, customers, and organizational strategy.

n At the Product Vision level, identify risks that will unfavorably impact the project from meetings this Vision.

n Put those risks in the Risk Register and connect them to Features and Capabilities to assure they are mitigated during development.

n Documenting the risks, developing actionable plans to manage the risks and measuring the reduction of risk is simply good project management

12. Risk Management


557

+ Product Roadmap

n The product roadmap provides a visual overview of the project's requirements and priorities.

n This visual overview allows the project team to quickly identify gaps in requirements and incorrectly prioritized requirements.

n For each element of the Product Roadmap, ask and answer what could possibly go wrong and what actions can be taken to reduce this probability of unfavorable impacts.

n For each delivered Capability, capture the risks in the Risk Register, the probability of occurrence, and the mitigation work at the development level

12. Risk Management


558

+ Product Backlog (PBL)

n The Product Backlog is a tool for accommodating change within the project.

n Being able to add changes to the Product Backlog and reprioritize requirements regularly helps turn the traditional risk associated with scope changes into a way to create a better product.

n Keeping the requirements and the priorities on the Product Backlog current helps ensure that the development team works on the most important requirements at the right time.

n Define work in the PBL to but down risks in the Risk Register.

12. Risk Management


559

+ Release Planning

n The Scrum team discusses risks to the release and how to mitigate those risks.

n Put these risk in the Risk Register

n Risk discussions in the release planning meeting should be high-level and relate to the release as a whole.

n Save risks to individual requirements for the sprint planning meetings.

12. Risk Management


560

+ Sprint Planning

n The Scrum team discusses risks to the specific requirements and tasks in the sprint and how to mitigate those risks.

n Risk discussions during sprint planning can be done in depth, but should only relate to the current sprint.

n Document the specific actions that will be performed during the Sprint to reduce the probability of occurrence of the risk or impact of the risk.

12. Risk Management


561

+ Sprint Backlog

n The burndown chart on the Sprint backlog provides a quick view of the sprint status.

n This quick view helps the Scrum team manage risks to the sprint as they arise and minimize impact by addressing problems immediately.

12. Risk Management


562

+Daily Scrum

n During each daily Scrum, development team members discuss roadblocks or impediments that may be or become risks to the project.

n Talking about roadblocks every day gives the development team and the Scrum master the chance to mitigate those risks immediately.

n Documenting these roadblocks, capturing actual risks in a risk register, and tracking the management of the risks increases the probability of success

12. Risk Management


563

+ Task Board

n The task board provides an unavoidable view of the sprint status, allowing the Scrum team to catch risks to the sprint and manage them right away.

n This visible chart also must have risks and their mitigations listed, just like the work that produces needed outcomes for the Features.

12. Risk Management


564

+ Sprint Review

n The Scrum team regularly ensures that the product meets stakeholders' expectations.

n The sprint review also provides opportunities for stakeholders to discuss changes to the product to accommodate changing business needs.

n Both features of the sprint review help manage the risk of getting to the end of a project with the wrong product.

12. Risk Management


565

+ Sprint Retrospectives

n The Scrum team discusses issues with the past sprint and identifies which of those issues may be risks in future sprints.

n The development team needs to determine ways to prevent those risks from becoming problems again.

n Revisiting the Risk Register during the retrospectives at assure nothing was missed, risk reduction occurred as planned, and no new risk have appeared during the Sprint.

12. Risk Management


566

+ Risk in Complex Programs†

n All risks are characterized by uncertainty, non-linearity and reclusiveness, best viewed as dynamic and evolving systems.

n So why do we pretend they are predictable, definable and fixed –and why do we use linear lifecycle models to manage them

† Complexity in Defence Projects How Did We Get Here?, Concept Symposium 2010, Oscarsborg Norway. Mary McKinlay

12. Risk Management


567

+

12.2 Mistakes Made During Risk Management

n Failure to Identify risk owners

n Failure to respond to several small, related risks

n Failure to identify and plan for secondary risks

n Failure to develop contingency plans

n Failure to develop fallback plans

n Failure to develop risk triggers

n Failure to respond to opportunities

n Failure to update project plans

n Failure to update the risk register

n Failure to create change requests

The failure modes of Risk Management are risk themselves.

Each risk must be identified, assessed, mitigated, tracked, and reported.

12. Risk Management


+ Failure to Identify risk owners

n A risk owner is the person who is responsible for monitoring their risks and executing risk responses when appropriate. Risk owners often aid in defining the risk response plans and in performing qualitative risk analysis and the quantitative risk analysis for their risks.

n When identifying risk owners, consider the following criteria:n Who best understands the causes, the risk, and the impact?

n Who will be willing to monitor the risk?

n Who will be responsive if the risk occurs?

n Who has risk management experience?

12. Risk Management


569

+ Failure to respond to several small, related risksn Fail to analyze the relationships between risks, is a failure to

understand how risks relate to one another.

n Individual small risks may appear impotent.

n However, several small, related risks can have a great impact (as threats and opportunities).

12. Risk Management


570

+

n When risk owners develop risk response plans, they may fail to consider secondary risks, risks that arise as a direct result of implementing a risk response.

n Good project managers educate and ask risk owners to identify and plan for significant secondary risks.

12. Risk Management

Failure to identify and plan for secondary risks


571

+ Failure to develop contingency plansn Some risk response plans are executed immediately.

n Other risk response plans are contingent. n These plans will only be executed under certain predefined conditions.

12. Risk Management


572

+ Failure to develop fallback plans

n What if the contingency plan fails?

n Risk owners should develop and be prepared to execute a fallback plan for significant risks.

n The fallback plan may be used to mitigate further a threat or enhance an opportunity.

n A fallback plan is defined for cases where a risk may occur.

12. Risk Management


573

+ Failure to develop risk triggers

n There can be good contingency plans but fail to define clearly the risk triggering events such as missing a milestone.

n Triggers may be used to provide the warning that the risk is about to occur, providing time to implement the risk response plan.

12. Risk Management


574

+ Failure to respond to opportunities

n Risks include positive events or conditions, that if they occur, cause a positive impact on the project goals.

n Therefore, many project managers fail to identify these positive events and miss the opportunities that could save the project or enhance the project’s value.

12. Risk Management


575

+ Failure to update project plans

n Schedule management plan, cost management plan, quality management plan, procurement management plan, human resource plan, scope baseline, schedule baseline, and cost baseline.

n Risk owners develop response plans, project managers should update the project management plans accordingly.

n The project manager adds new activities (or omitted activities) to the schedule and further define how contingency reserves will be consumed.

12. Risk Management


576

+ Failure to update the risk register

n Risk owners create response plans.

n Make sure that the register is updated with the plans.

12. Risk Management


577

+ Failure to update Assumptions Log

n Project managers and team members make assumptions, particularly in the early parts of a project, based on the information at hand.

n The project team discovers new information, previously identified assumptions may need updating, or new assumptions may need to be added.


578

12. Risk Management

+ Failure to create change requests

n Risk response planning triggers change requests that require changes to the project management plan or other project documents.

n Some changes may require new baselines.

12. Risk Management


579

+ The Final Notion of Risk12. Risk Management


580

The notion that the causes for risks clearly lie in our incomplete knowledge of the subject matter, and if a project establishes all

possible causes of risks, they can be managed away.

This puts the focus on discovering and dealing with Epistemic RisksAleatory Risks can be easily modeled with Reference Class

Forecasting using past performance

The reduction of Epistemic Risk is the primary beneficial outcome of Agile Software Development.

The Aleatory Risk cannot be reduced. Only margin will protect the delivery data and cost

And of course that is simply not possible

Rapid Feedback provides visibility to emerging risks

+ Beware The Black Swan12. Risk Management


581

+Risk Management

n All risk comes from uncertainty

n Uncertainty comes in two forms

n Aleatory Uncertainty, which is irreducible and can only be addressed with margin or reserves

n Epistemic Uncertainty, which comes from lack of knowledge (epistemology is the study of knowledge) and can be addressed with redundancy, experiments, prototypes, and other knowledge gaining processes

n Risk Management is How Adults Manage Projects ‒ Tim Lister

n Agile development process participate in risk management, but agile development processes are not Risk Management


582

Technology

12.0 risk management agile+evm (v10.2)