PLAYBOOKHQ.co@PLAYBOOKHQ

Project Risk: How

PLAYBOOK LEAN PRODUCT DEVELOPMENT SERIES

This work is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License.

PLAYBOOKHQ.co@PLAYBOOKHQ

PLAYBOOK LEAN PRODUCT DEVELOPMENT SERIES

This series is for anyone interested in Lean, Agile and team principles and how they can be applied in new product development scenarios to increase innovation, improve delivery times and create engaged,

happy, high-performing teams.

Risk Management Process:

1. Identify

a. Seek out risks before they materialize.

b. Do so frequently, in small batches, starting as early as possible.

c. Establish a Title, Description, and Owner for each risk and mitigation.

2. Analyze

a. Determine decision making information (risk drivers, probability, impact, etc.)

b. Determine if the potential impact and probabilities are high enough to move on to the Planning phase.

3. Plan

a. Determine and select mitigations.

b. Identify resources needed and develop the primary tasks.

c. Develop a risk reduction schedule (i.e. mitigation execution timeline).

d. Put the mitigations in the project schedule.

4. Implement

a. Execute the mitigations.

b. Review and update decision-making information (see Analyze above).

c. Update the risk reduction schedule and project schedule.

5. Track and Control

a. Review the effectiveness of the mitigations.

b. Reprioritize and re-plan as necessary.

6. Iterate the process (i.e. repeat steps 1-5 again, again and again)

Analyzing Project Risks:

1. There are many different levels of Risk Analysis.

a. Analyze the risks in greater detail, get a greater benefit (to a point).

b. These are not distinct levels – there are many variations of the process in between levels.

c. We will start you at Level 2 - Formally Manage Project Risk, Qualitative Exposure Estimates.

d. On occasion we may go to Levels 3 & 4.

2. There are four (4) different factors at play in Risk Analysis

a. The size of the potential Impact (i.e. Severity).

b. The Probability the risk event will occur.

c. The cost-effectiveness of the mitigation.

d. The timeframe in which the mitigation must be implemented.

3. Probability and Impact are terms and ideas similar to those in FMEAs.

a. For Level 2 we combine Probability and Impact using a gut-feel scoring model: High, Medium, Low.

b. Somewhere in the back of our minds, we calculate Probability x Impact.

c. Avoid the time-factor and cost-effectiveness to mitigate in this score.

i. The time-factor will be incorporated during planning activities.

ii. The cost-effectiveness of the mitigation will be determined via gut-feel as well.

iii. Based on the time-factor and cost-effectiveness of the mitigation, we will determine mitigations that seem worth it.

Analyzing Project Risks:

1. It helps to have a common understanding of the terms in the risk function even if you are not quantitatively analyzing risks.

2. Cost Now = Cost to identify and analyze the risks and to plan and execute the mitigation(s).

3. Cost Later = Potential impact of not doing the mitigations.

4. Costs apply to Schedule, Sales Volumes, Average Sales Price, Unit Cost, and Project Expenses.

5. When talking about risks, use Probability, not Maybe. It is too easy to miscommunicate Maybe – is it 10% or 90%?

6. On 75% or more of your Project Risks you are betting with time to save time.

a. This is a simple case where you can fully mitigate the risk.

b. The assumption we make when not doing quantitative analysis is that this is always the case.

c. Quantitative analysis can show when this is true and when it isn’t.

Analyzing Project Risks:

For each risk, using the Risk Register:

1. Determine the Risk Drivers:

a. Risk Drivers are the specific elements or unknowns which are the basis for the uncertainty.

b. Put the Risk Drivers in the form of a question.

i. This way you start in quick learning mode.

ii. How can you most quickly answer the question(s)?

c. Always try to get to the most fundamental (root) question.

i. What do you really need to know to eliminate the risk?

ii. Half of solving the problem is knowing what the problem really is (maybe more!).

d. Rate the importance/impact/value of each Risk Driver.

i. Use High, Medium, Low ratings

ii. Based on the value of the information to be gained by answering each Risk Driver.

2. Determine the Impacted Objects:

a. List all objects (parts , sub-systems, documents…) which may be affected (change) while answering the questions.

b. Some risks do not impact any objects. Leave the Impacted Objects field blank in these cases.

Analyzing Project Risks (continued):

3. Determine the Estimated Exposure

a. If you do nothing to mitigate the risk, what is the expected impact to the economic objectives?

b. Usually the key economic objective is the Schedule, but sometimes Sales, Unit Cost, and/or Project Expenses are important, too.

c. Develop common definitions for High, Medium, Low.

For example:

i. High: > 8 wks delay, > 10% sales loss, > $100 unit cost increase, > $20K project expense increase.

ii. Medium: 2-8 wk delay, 3-9% sales loss, etc.

iii. Low: < 2wk delay, <3% of sales loss, etc.

d. Base the Schedule Impact on the longest-lead time in list of Impacted Objects (usually).

e. Schedule Impact = time on the critical chain to…

1) identify the change (answer the questions)

2) + document the change (and release the doc if necessary before Order)

3) + Order/receive/inspect new parts

4) + Confirm that the change worked

f. Determine the Estimated Exposure using Schedule Impact x Probability.

Planning Project Risk Mitigations:

1. Prioritize risks

a. Filter the Risk Register by Estimated Exposure.

b. Rank the risks within each category (clear priorities are more important than correct priorities – see details in the Critical Chain Project Management class).

2. Starting with the High risks…

a. Identify potential mitigations

i. Better mitigations are often found through brainstorming sessions with a cross-functional team.

ii. Capture multiple mitigation options in the Risk Register

b. Select the best mitigation(s)

i. Mitigation speed is an important consideration.

ii. Determine how you can most quickly reduce the risk by answering the questions (i.e. Risk Drivers).

iii. This is the same as saying, how can you phase your learning to most quickly reduce the uncertainty

c. Try to address each Risk Driver independently, in small batches.

i. Don’t hold up learning resolving a high-value Risk Driver for the sake of a low-value one

d. When Impacted Objects includes many objects or those with long-lead times…

i. Determine what you can do with the Architecture to decouple them and therefore remove them from the list of Impacted Objects.

Mitigation Categories:

Mitigations fall into seven (7) general categories (not all are really mitigations in the strict use of the term)

1. Collect more Information (don’t plan mitigations yet)

a. When you don’t know how to mitigate the risk

b. Establish objectives, owners, due dates, & risk re-evaluation dates to make sure it happens

2. Avoid the Risk

a. Reverse the decision which created the risk in the first place.

b. For example, loosen the weight requirement to allow a heavier product.

3. Transfer the Risk to a 3rd Party

a. Find another party to share or take the risk.

b. For example, hire a vendor who specializes in the material proposed for lighter components X, Y & Z, and make their payment dependent upon the success of their weight reduction effort.

4. Provide Redundancy

a. Develop multiple solutions which may or may not work to reduce the risk.

b. For example, hire a second vendor who specializes in a different material which may be used to lighten components X, Y & Z.

Mitigations Categories (continued):

5. Prevention of the Risk

a. Reduce the probability of the risk by implementing actions which directly counter the Risk Driver(s).

b. For example, perform experiments early in development to determine how much additional heat sink area and therefore, weight is needed for the new function. By focusing effort on this requirement early in development, you are less likely to impact the schedule.

6. Contingencies

a. Reduce the impact of the risk (the potential total loss) by implementing actions which directly counter the Impact(s).

b. For example, put a limit of 2 weeks to be spent late in the project to reduce weight. Any additional weight reduction will need to occur after product release.

7. Architectural Changes

a. Reduce the impact of the risk by changing the product architecture to eliminate Impacted Objects especially those with long-lead times.

8. Buffers

a. Establish reserves of development budget and/or schedule to accommodate the risk.

b. For example, if we get halfway through the project and we are over our weight requirement, then hire contractors to help start the weight reduction studies. Keep $50K in the budget to do this and add 2 weeks to the project buffer in case it takes longer than we expect.

Planning Mitigations:

1. Assign a Risk Owner to each mitigation. A single owner establishes clear accountability.

2. Assign the Priority for each mitigation. Priority correlates with the information value of the Risk Drivers.

3. Develop the Risk Reduction plan for each risk.

a. Indicate the mitigations needed to reduce the risk from High to Medium to Low to Closed.

b. Determine how you will display and manage this risk within the top-project plan:

i. Each mitigation separately

ii. Or group mitigations into milestones, for example:

1) All High Value Drivers Addressed

2) Build 20 units without experiencing the issue

3) Pass test ‘X’.

c. Plan to execute the high-value mitigations as early as possible.

d. Capture the primary resources needed to execute the mitigations and reach the milestones.

e. Develop the major sub-tasks and their dependencies.

4. Put the risk reduction plan (mitigations or milestones) into the top-project schedule

a. Use critical chain project scheduling. Don’t overload the resources.

b. Plan to address the highest risks earliest. Move later only if there is little risk doing so.

Planning Mitigations (continued):

5. Indicate the Risk Status of each risk in the Risk Register.

I = Identified - Not analyzed yet

NA = Invalid - Analyzed and found to be zero risk

P = Planned - Analyzed, planned, but not yet started executing mitigations

A = Active - Analyzed, planned, and currently executing mitigations

W = Watched - Analyzed and determined that we can’t think of any mitigations easy enough for the level of risk that it is. Usually Low risks, or low probability-high impact risks, or risks that used to be High or Medium, which we did something on, and now it’s not worth doing any more.

N = Not Managed - Analyzed and it was determined that the mitigations aren’t cost effective enough. Maybe we added a little buffer and that was our only mitigation.

C = Closed - Mitigations executed and risk reduced effectively to zero

S = Superseded - We are managing this risk within another risk activity.

6. Repeat steps 1-4 for all of the top risks until the expected loss is less than the cost associated with mitigating the risk.

Implementing Risk Mitigations:

1. Implement the Risk Reduction plans.

2. Continually give priority to higher risks.

3. Regularly update the Risk Register, Risk Burndown chart, and top-project schedule.

Track and Control Risks:

1. Review the mitigation effectiveness

a. In regular, frequent Risk Management or Project Status meetings

b. If High risks are not being mitigated effectively, identify new mitigations or reprioritize to a risk where you can be effective.

2. Identify new risks

a. Always look for new risks - in and outside of Risk Management meetings.

b. Bring these to the attention of the Project Manager as soon as possible

3. Update the Risk Register

a. Whenever new information emerges that affects Active risks

b. Once a risk has been sufficiently mitigated, update its Risk Status.

4. Reprioritize as necessary

a. Always apply the resources to the highest risks until they are lowered.

5. Communicate decisions and priority changes

a. Publish meeting minutes with decisions, new risks, and significant priority changes highlighted.

b. Make sure people know that a non-reply is the same as acceptance of the decisions.

Notes:

1. Risk Scores are based on Estimated Exposure.

2. Risk Scores are determined by the average impact of the risks.

For example:

a. High = 8 wks or more (avg. 10 wks) receives a score of 10 points

b. Medium = 2-8 wks (avg. 5 wks) receives a score of 5 points

c. Low = 0-2 wks (avg. 1 wk) receives a score of 1 point

3. The total risk is the overall size of each stacked column.

a. Lowest bar (red) indicates the relative risk to the project from High risks

b. Middle bar (yellow) indicates the relative risk to the project from Medium risks

c. Highest bar (blue) indicates the relative risk to the project from Low risks

4. With a healthy, active Risk Management process…

a. High risks should burn down the fastest.

b. If your total risk score is in the yellow, start evaluating ideas to burn risk faster.

c. If your total risk score is in the red, implement those ideas or add more project buffer.

PLAYBOOKHQ.co@PLAYBOOKHQ

Key Takeaways

• Risk Management is a high return investment.

• When executed with a regular, frequent cadence.

• More accurately communicates project scope.

• Improves project outcomes.

• Mitigations should be included in the top-level project schedule.

PLAYBOOKHQ.co@PLAYBOOKHQ

PLAYBOOKHQ.co@PLAYBOOKHQ

THANK YOU!