Risk Management in an Agile Lifecycle

1
 Agenda

• The goals and practices of traditional risk management

• The goals and practices of Agile risk management

• Pros and cons of both approaches

• Can the two risk management methods be used together?

2
2
A Review of Traditional Risk Management

3
3
Risk Defined

4
4
 Frequent Risks

• The stakeholder requirements could be in conflict with each other.

• The estimate is not based on historical throughput.
• Team members are allocated to multiple projects.
• The project was approved without team buy-in.
• A 3rd party may not deliver their part.

5
 Frequent Risks

• The stakeholder requirements could be in conflict with each other.

• The estimate is not based on historical throughput.
• Team members are allocated to multiple projects.
• The project was approved without team buy-in.
• A 3rd party may not deliver their part.
• Example - Hardware – bad weather in Asia could delay equipment

6
 Traditional Risk Management Steps

1. Identify
2. Quantify Impact
3. Quantify Probability
4. Create contingencies for high impact - high probability risks
5. Manage highest scoring risks

7
 When do we identify risks?

In our PMLC - usually once to Initiate the project,

then revisit and update the risks after Planning.

8
 When do we identify risks?

In our PMLC - usually once to Initiate the project,

then revisit and update the risks after Planning.

We can call this BURP – Big Upfront Risk Planning.

9
 What Do We Identify?

Project Name: Online Auction System Target Start Date: 06/30/11

Project Number: 22880 Target End Date: 08/30/11
Program Name: 0 Company Number: 1
Sponsor: Jim Traylor Cost Center: 3573
Business Owner: Anne Archy Created Date: 03/08/11
Project Manager: Greg Smith Revision: 39492

Risk Assessment
Severity Likelihood
Contingency
Risk ID Risk of of Risk Risk Response Risk
Risk Description Plan Required Risk Approach
Number Categories Impact Occurring Rating Summary Owner
(Yes/No)
(1-5) (in %)
Project Insufficient resources to successfully On Technology side, resources Nathan or
B5 5 0.75 3.75 Yes Risk Avoidance
Execution complete the project. are involved with Core platform. Greg:

10
 What Do We Identify?

Project Name: Online Auction System T

Project Number: 22880 T
Program Name: 0 Co
Sponsor: Jim Traylor
Business Owner: Anne Archy
Project Manager: Greg Smith

Risk Assessment
Severity Likelihood
Risk ID Risk of of Risk
Risk Description
Number Categories Impact Occurring Rating
(1-5) (in %)
Project Insufficient resources to successfully
B5 5 0.75 3.75
Execution complete the project.

1. The potential risk

11
 What Do We Identify?

Project Name: Online Auction System Target Start Date: 06/30/11

Project Number: 22880 Target End Date: 08/30/11
Program Name: 0 Company Number: 1
Sponsor: Jim Traylor Cost Center: 3573
Business Owner: Anne Archy Created Date: 03/08/11
Project Manager: Greg Smith Revision: 39492

Risk Assessment
Severity Likelihood
Contingency
Risk ID Risk of of Risk
Risk Description Plan Required Risk Approach
Number Categories Impact Occurring Rating
(Yes/No)
(1-5) (in %)
Project Insufficient resources to successfully
B5 5 0.75 3.75 Yes Risk Avoidance
Execution complete the project.

2. The impact if the risk happens

3. The likelihood the risk will occur
4. Ultimately a Risk Rating

12
 We Usually Have Risk Categories
RISK CATEGORIES
RISK CATEGORY DEFINITION SAMPLE QUESTIONS
Business Continuity Includes risk associated with the duration, or impact, of  Will the introduction of a new product or service cause an
an interruption of critical business processes and their interruption to existing business processes?
associated people, vendors, systems, technology,  Is there a Business Continuity Plan?
 Has the Business Continuity Plan been updated to reflect
changes?
Compliance Includes risks introduced to the company either during  Is this a new process, product or business model that
the project, or as a result of the project, associated with the Company has not had significant experience in
failure to meet regulatory requirements. implementing?
 Has this project, product or process resulted in a
customer impact resolution in the past?·
 Is this project in response to a new statute, regulation or
comment from a regulator?

E-Commerce Risk Risks associated with Internet interfaces  Is web site privacy adequately protected?

 Is the website and session security appropriately handled?

 Is the access to data via web site adequately protected?
 Is there protection in place to prevent hackers, denial of
service attacks, website defacement, etc.?
 Is the web site privacy adequately protected?
Financial Includes operational risks associated with theft or misuse  Is the forecast of the financial performance of the project
of Company or customer assets or information, adequate?
 Describe the assumptions used in this forecast and the
risks to achieving them.
 Are financial tracking requirements clearly documented?
Are there changes to accounting practices?

Fraud/Theft Includes risks introduced to the company either during
the project, or as a result of the project, associated with
theft or misuse of Company or customer assets or
information,

13
13
 …and we have Risk Response categories

RISK RESPONSE APPROACHES

Risk Avoidance Eliminating the threat of a risk by eliminating the cause.

Mitigation (Controlling) Reducing the consequences of a risk by reducing its severity of impact or
likelihood of occurring.
Acceptance Accepting the risk if it occurs.
Share or Transfer Assigning the risk to another party by purchasing insurance or subcontracting.
(Allocation)

14
 When Done We Have a Scored List.

We create Contingency Plans for Risks with a High Rating

15
 Traditional Risk Management – Pros and Cons

Pros Cons
Risks identified before major investment Usually done at the start but not
throughout a project
Early analysis can help with a go/ no May be performed on projects where there
decision is no value add
Contingency planning that avoids waste Often done without examination of specific
requirements
Risks exposed to the team at large Often done by a small group – not the
entire team
Lessens chance of mid-project surprises No correlation to project specific processes
to identify and minimize risk

16
How is Agile different?

As we mentioned,
traditional planning does
risk management upfront.

17
 How is Agile different?

As we mentioned,
traditional planning does
risk management upfront.

Look
Look for
for Risk
Risk
Look Look
Look for Look for
for Risk for Risk
Risk Risk

Look
Whereas Agile looks for
for risk throughout the
Risk
lifecycle.

18
How Does Agile Address Risk?

19
 Agile Principles Address Risk

• Transparency – Expose everything we are doing so we can see risks early

• Collaborative planning – Harness the knowledge of the entire team and

see more risks

• Customer involvement – Mitigate customer risk by involving them

throughout the lifecycle

20
 Project Envisioning Practices

Envisioning the product with the customer

• The team and customer are synchronized on the need
• Less risk of delivering the wrong product

Quantifying the value with the customer

• Less risk of the team not supporting the project

PROJECT ELEVATOR STATEMENT

For: Internet Retailers

Who: Would like to sell their items locally within an auction

framework

The: Acme Auctionator

Is a: Local Online auction system

That: Allows the selling of goods without a commission

And Unlike: Craigslist

Our: Product allows the seller to put an item up for bid, as

opposed to selling at a fixed price 21
 Project Planning Practices

Estimation based on history

• Risk of estimate inaccuracy reduced since constants are involved in estimation

Work reviewed at the feature level for more

detailed risk evaluation:
• Less chance of missing a risk since features are examined
separately for technical risk

22
 Development/Implementation Practices

Daily Standup Meetings

• Agile teams meet every 24 hours
• Which mean risks are exposed every 24 hours

Product Demos Every 2 to 4 weeks

• Constant exposure to the customer
• Minimizes the risk of building to the spec but not to the need

23
 Project Tracking Risk Practices

Don’t Manage Based on % of Plan Complete

• Percentages are misleading
• There is a risk that 1% takes as long as 99%

24
 Project Tracking Risk Practices
Production
Functional Code Unit System Functional Customer DR Code Code
STORIES Requirements Written Tested Integration Testing Approval Load Test Release Release
Iteration 1
Ability to register on
the site

      N/A

Ability to place an item

up for bid

   
Ability to bid on an
item

    
Auction Engine Logic

    
Instead manage by binary attributes
• Complete or not complete
• Less risk of overrun on construction tasks

25
Can I use Traditional Risk Management on My Agile Project?

Yes – Please Do!

26
 But – Make the Call on Each Project

Do Traditional Risk Management Probably Skip, or do lightly,

when Project: when Project:

Has technology never used by the team Is a simple release on existing platform

Is expensive Only runs a few days

Has many touch points Schedule is tight and extended risk

planning could jeopardize delivery
Longer than a few weeks We have a lot of experience with this
type of project
Is required to be compliant We can leverage an existing risk plan

27
 Summary

• Traditional Risk Management and an Agile lifecycle are complimentary

• Traditional Risk Management is done up front and tries to envision what could
go wrong all the way to the end of the project

• Agile Risk Management is done more by practices then envisioning. Many

Agile practices look to identify and mitigate risk throughout the project.

• The level of traditional risk management performed should correlate to

complexity, duration, and experience with the type of project being pursued.

28
 Contact Info

Greg Smith
greg@gssolutionsgroup.com

29