1. Risk Management for Software Projects

2. The curve that is the life of your project…

3. Session Objectives Make sure risk identification leads to real action Ensure that teams are constantly and proactively identifying and mitigating risks Shift team culture so risk identification occurs as “Good News”

4. Most risk discussions do not cause any action Two typical ways to talk about risk: –… they don’t –Mention of risk is heard as a fear or complaint Most risk lists are “storage” –They do not result in action –Presented in project review slides that are referred back to after the project has failed.

5. A shift in paradigm and language is required to ensure that risk identification leads to action.

6. What you know has nothing to do with what you do.. Teams must have foundation conversations for integrity and commitment: –Integrity: do what you say. –Commitment: standing for the integrity of a decision and giving up the right to complaint.

7. Higher standard for commitment leads to the revelation of risks. Concern about dependencies gets voiced early. Saying “no” becomes constructive. Less wondering if they “really meant the date”

8. Projects fail because teams do not have a constructive way to discuss risk Culture is a network of conversations: what comes out of your mouth and how you listen.

9. What is a complaint? A few things to ask yourself.. –Am I talking to someone who can’t do anything about the issue? –Am I speaking to be “right” about the issue (human beings love to being right)? Use language that “forwards the action”.

10. Cause, Effect, Impact (CEI) Cause: Specific, existing condition; a “fact” Effect: Possible, specific bad outcome Impact: Measurable effect on the business. Complaint: The database will never work CEI: Lack of a frozen schema, may lead to late rework, which will slip the schedule.

11. A Context for discussion risk Pretend you’re looking back and asking, “Why did the project fail?” The only reason to “discuss” risk is to cause mitigation. Probability of failure is the meaningful differentiator and useful heuristic.

12. Risk Action Plan Name (Unique Identifier) Cause (Specific Concern) Effect (What will fail?) Impact (Why does this impact the business?) Owner (Who will own the status of the risk?) Prioritization (Sort field) Mitigation plan (At least 5 alternatives) Critical mitigation milestone (by when must this risk be mitigated). Description of Next Attack (with accountable individual) communicate status. Date of next attack.

13. How to prioritize risk The only goal of prioritization is to determine which risks will be acted on first. Past results are the best predicator of future results. –Super High: Never accomplished in a similar project anywhere. –High: Successfully mitigated occasionally. –Medium: Successfully mitigated often elsewhere or occasionally here. –Low: Core competency here. When in doubt or impact is huge, then promote priority.

14. How to mitigate? Get into cross-functional action immediately. Mitigations take time and resources: they must appear on your schedule. The teams should constantly ask “What are we doing today to mitigate our highest risk?” Prototype and test from day one. Contingency Vs Backup plans –Contingency plans are developed up front, and are executed when Plan A fails. –Back up plans are executed in parallel with Plan A.

15. Weekly accountability meeting Part 1: Acknowledge accomplishments for the week. What is your percent complete Part 2: Any changes to weekly deliverables for next 3 weeks? Part 3: Review mitigation of top 3 risks. Part 4: What are the two most likely reasons, the project might fail from your perspective, now.

16. Critical Points Make conversations on why the project could fail MANDATORY and frequent. Use Cause, Effect, Impact language and require specificity. Have clear, accountable, empowered, singular ownership of risks. Keep your sense of humor.