Process: Identify → Analyze → Plan → Monitor. This chapter covers threats only; opportunities appear briefly on slide 72.

Memory trick “I Am Planning More”: Identify, Analyze, Plan, Monitor.

The outline follows the process order.

A risk is something that might happen and would change a project goal if it did. The word positive matters: a chance to finish early is also a risk, called an opportunity. A negative one is a threat.

These four questions are the whole of risk management in one line. They move from noticing a possibility, to sizing it, to deciding what to do, and skipping any of them leaves you unprepared.

Seen again Ch 1.2, slide 100: Risk in the Uncertainty domain

Seen again Ch 1, slide 68: Risk principle

Once it has happened, it’s no longer uncertain: it’s an issue, and you deal with it right away. That’s why 0 < probability < 1: 0 means it can’t happen, and 1 means it already has.

Mature teams talk about risks openly and early. Teams that stay silent, fearing they’ll seem negative, simply meet those same problems later, when they cost more.

Trap Something that has already happened is an issue, not a risk.

Grouping threats makes them easier to spot, because each class suggests its own questions. Requirements problems are often the most damaging, since everything is built on them. Operational risks are easy to overlook: a poor hand-off between teams can undo good work.

Assessment asks “what could go wrong, and how bad is it?”, and control asks “what do we do about it?”. Doing only the first gives you a list of worries and no protection.

Each step has an output: list of risks → prioritized list → response plans → assessment. Monitoring loops back to identification.

A plan looks fine until someone asks what could break it. Testing it this way before you start shows whether it’s resilient, not just optimistic. It’s also easier to win support when you can show you’ve thought about what may go wrong.

Instructor Arabic gloss for advocacy: “مناصرة”.

None of these are unusual, and that’s the point. A key person leaving or a late vendor happens all the time, so plan for it, rather than treating it as bad luck.

New risks appear as you learn more, and old ones stop mattering. A list made once and never updated gives false comfort, so identification has to be iterative.

“Known” doesn’t mean certain to happen. It means you could find it by carefully looking at your plan, such as noticing an unrealistic date. Since you can see it coming, you can write a response in advance.

You know roughly how often staff leave, but not what it would do to this project. Since you can’t pin down its impact, predictable risks are handled by keeping something in reserve.

No plan covers a natural disaster striking your office. These sit outside risk management, so companies handle them by way of crisis or disaster management.

Memory trick Known → plan · Predictable → contingency · Unknowable → crisis management.

One person only sees their part. A tester and a developer notice different dangers, so involve the team, and a checklist or SWOT stops you relying only on memory.

These aren’t competing lists but different ways of sorting the same risks. Sorting helps because risks in one group often share a response or an owner.

The test is what the risk would hurt. If it mainly makes you late or over budget, it’s a project risk. A departing team member fits here, because the plan is what suffers.

Here the danger is to the software itself. A technical risk may leave the schedule intact, while the product doesn’t work properly, such as a design that can’t handle the load.

You could finish on time with no bugs and still fail, if nobody wants what you built. That’s what viability means. These are the easiest risks for a technical team to miss.

Memory trick Project → plan · Technical → software quality · Business → product viability.

Just as a WBS breaks work into parts, an RBS breaks risks into groups. This makes gaps easy to see: if a whole branch is empty, you probably haven’t looked there yet.

Seen again Ch 6.2, slide 8: WBS

Everyone’s ideas trigger more ideas, so brainstorming is quick and generates many. But louder people can dominate, which is what the next technique tries to avoid.

Anonymity is the key: an expert can’t be swayed by a senior colleague’s opinion. Going through several rounds with a facilitator lets experts converge without pressure, which is what makes Delphi different.

Trap Brainstorming: participants interact. Delphi: they do NOT.

“Missed the sprint” is a symptom. Fixing it directly doesn’t help if the real cause lies deeper. Asking “why?” repeatedly gets you there: root cause analysis treats what’s actually causing the problem.

Notice that the answer is about process, and not about any one person. Good 5 Whys usually ends at something you can change.

Past projects tell you what tends to go wrong, which saves time. But every project is unique, so a checklist is a starting point, and treating it as complete means missing what’s new here.

Every plan quietly assumes things, like “the vendor delivers on time”. If that’s shaky and would hurt badly if false, you’ve found a risk nobody listed. That’s what assumptions analysis looks for.

Pictures show connections that lists can hide. Fishbone diagrams show causes, flowcharts show steps, and influence diagrams show what affects what.

You start from the problem and work backward through the possible causes. It’s drawn like a fish skeleton, and that layout helps a group explore every branch rather than stopping at the first idea.

Example effect: module defects. Bones: process, staff, design, environment, testing, requirements.

Everybody can follow a flowchart, even those who aren’t technical. This one shows when a risk owner acts, which removes confusion about what happens once a trigger occurs.

Boxes and arrows show how changing one thing affects others. If scope grows, how does that change quality, cost and time? An influence diagram makes those knock-on effects visible.

These add to the earlier techniques. Decision driver analysis is the one to note: it asks whether a choice was made for good reasons, because decisions made for politics or fashion are often risky.

A checklist works best when it’s organized, so that no area gets forgotten. Each group has its own slide with concrete questions you can ask. A long list of questions like this is good for known and predictable risks.

Memory trick “People Buy Cool Phones During Tech Sales”: Product size, Business, Customer, Process, Development env, Technology, Staff.

Bigger software has more parts to go wrong and more people to coordinate. Compare with your past projects: if this one is much larger than anything you’ve done, your experience may not apply.

These look outside the code. A product that matters greatly to revenue gets more pressure, while tight deadlines and regulations can limit your options, and those limits are a source of business impact risk.

A customer who’s unsure of what they want, or won’t spend time with you, is a real threat to the project. So ask these questions early. Any “NO” means you need to look more closely.

If the process only exists on paper, or people aren’t trained on it, you can’t rely on it. Quality then depends on individual heroics, which is what makes an ad hoc approach risky.

New technology might not do what’s promised, and your team has no experience with it. Note how this checklist flips: for technology, a “YES” is the warning sign.

Trap Technology checklist flips: “YES” means risk. The others: “NO” means risk.

Poor tools slow people down and cause mistakes, and they’re easy to overlook during planning. Here a “NO” is the warning sign, as with most of these checklists.

Having the right number of people isn’t enough. Someone split across three projects is really a fraction of a person, which is why committed is one of the questions. People make the biggest difference to success.

The risk register is one living document, filled in gradually. At this point, you know what the risks are, but you haven’t yet scored them, which is why those columns are empty.

You can’t address every risk, so analysis tells you where to spend effort. Cost-efficient is the catch: don’t spend more analyzing a risk than it could ever cost you.

Numbers let you compare very different risks fairly. RE = P × I turns “likely but small” and “unlikely but huge” into figures you can rank.

Don’t read 1 week as the actual delay. If it happens, you lose 4 weeks; 1 week is the expected cost, so it tells you how much to protect against.

Add up every exposure, and you get the likely total overrun. That’s useful for setting a reserve, as it’s based on the risks you’ve actually listed.

People give very different meanings to “likely”. A Likert scale ties words to ranges, so that a whole team means the same thing when it scores a risk.

If you can’t reasonably tell 20% from 40%, a finer scale gives false precision. So when information is thin, use three points.

Impact isn’t just money, as a risk may barely affect cost and seriously harm quality. Consistent criteria matter, or two people will score the same risk differently.

Probability or impact alone can mislead. A likely but trivial risk may matter less than an unlikely disaster. The matrix combines both so you can compare risks on one scale.

If it’s both likely and damaging, hoping for the best isn’t acceptable, so it gets a formal response plan. Low ones may only need watching.

Your time is limited, and a small number of risks usually cause most of the damage. 80-20 gives you permission to ignore the bottom of the list and focus where it counts.

A score based on guesswork looks scientific without being reliable. So before trusting the ranking, ask how good the information behind it is. Otherwise, you may focus on the wrong risks.

The same risk can look minor to a risk seeker and alarming to someone who’s risk averse. Knowing this bias helps you, so involve several people, rather than relying on one person’s judgment.

The register grows as you go. A watch list is the clever part: low risks aren’t deleted, just checked now and then, because they can still grow.

Before handling risks, decide how you’ll handle them: who, how often, with what budget. Without a plan, people treat risk work as optional and it gets dropped under pressure.

Working on everything at once means not doing any of it well. Handle what could strike soon, keeping others on a watch list, the same idea as rolling wave planning.

You don’t start from nothing. Past records and research show what’s happened on similar work, which is why historical information counts as an input.

A hospital and a startup tolerate very different risks. Risk tolerance tells you what’s acceptable: people take a risk when what they could gain outweighs what they could lose.

Don’t reinvent the rules if policies already exist. The scope statement is also useful, because its assumptions and constraints point directly at where risks may hide.

Risk work needs real time and money, so it has to be planned like other work. Making the risk management plan part of the main plan means risks get considered in everything else.

Risk knowledge is spread around, so bring those who hold it together. That’s why meetings are the main tool, and the plan they produce is the single output.

Instructor Next to the heading: “Meetings are the main tool.”

Trap Identification outputs the risk REGISTER; planning outputs the risk management PLAN.

This sets how the work happens, and who does it. Naming risk owners is the key part, because a risk that belongs to everyone tends to be handled by no one.

Formats and tracking may look like bureaucracy, but they let people compare risks over time. Tracking also lets an audit show whether the process is being followed.

Spending $10,000 to prevent a $1,000 problem makes no sense. So match the effort to the severity, and for low risks a simple note may be enough.

A response that arrives too late doesn’t help, and it may create new problems. It needs agreement, because others bear its cost, and one owner, so someone is clearly responsible for acting.

Seen again Ch 1, slide 68: Good risk responses: appropriate, cost-effective, realistic, agreed, owned

Threats and opportunities are mirror images, which makes them easier to remember. You remove a threat and guarantee an opportunity, shrink one and grow the other, hand off one and share the other.

Memory trick Threat/opportunity mirror: Avoid–Exploit, Mitigate–Enhance, Transfer–Share, Accept–Accept.

If you remove the cause, the risk disappears. That’s why avoidance is the strongest response, but it can mean dropping something valuable. It’s cheapest early on, before work depends on that part.

Removing a risky integration may also remove a feature you wanted. So weigh what you’d lose, rather than treating avoidance as free.

The risk still exists, but someone else pays if it happens. Transfer works best for money, as insurance can pay for damage, but it can’t give back your lost reputation.

With a fixed price, the seller pays for any overrun, so expect them to raise their price to cover that risk.

Here you pay whatever the work costs. That’s suitable when you can’t define the work well enough for a fair fixed price, but you carry the risk of overruns.

Trap Fixed price → risk on the SELLER. Cost reimbursable → risk on the BUYER.

Mitigation tries to stop it, monitoring watches for warning signs, and management is your plan if it happens anyway. Together, RMMM answers before, during and after.

You accept that the risk might still happen, but you make it less likely or less painful. Finding a problem through tests now is much cheaper than after release, which is why mitigation pays off.

Sometimes a risk can’t reasonably be reduced. Passive acceptance means you’ll deal with it if it comes, while active acceptance sets money or time aside just in case.

Don’t confuse this with mitigation. A contingency plan doesn’t make the event any less likely. It’s just what you’ll do if it happens, which saves panic later.

A data center may still fail, but a disaster recovery plan gets you running again. That’s a clear example of planning for after the event.

This is the time or money kept back to pay for a problem when it happens. A contingency allowance means you don’t have to find extra resources in a crisis.

What if your response doesn’t work? A fallback plan is your Plan B, so it’s kept for serious risks where failure of the first plan would really hurt.

With a threat you hope it won’t happen, and with an opportunity you want it to. Exploitation makes it more certain by acting, while sharing brings in a partner who’s better placed to capture it.

Seen again Ch 1.2, slide 104: Five opportunity strategies

Your fix can create its own problems: hiring an expert adds the risk that they fall ill. These are secondary risks, and they need responses too.

Even after responding, some risk usually remains. Residual risk is what’s left, so you decide whether it’s acceptable and keep a reserve to cover it.

A trigger tells the risk owner when to act, like a warning sign. Without one, people may not notice a risk is happening until it’s too late.

Responses cost time and money, and those must go into the plan, or they’ll be a surprise later. Monte Carlo analysis then simulates the project many times, showing the likely range of results.

Lengthy risk reports get ignored. A short list that’s easy to update gets read and acted on, while weeks on list shows which risks are stuck.

A contingency plan is prepared in advance. A workaround isn’t, because the problem wasn’t foreseen. If you need many of these, your risk identification may have been weak.

A task that’s “80% done” for weeks hides slippage. A binary milestone is done or not done, and when they’re only 1–2 days apart, a delay can’t hide for long.

If risks only come up when something goes wrong, nobody’s managing them. Making them a regular agenda item keeps them visible while they can still be dealt with.

A risk you marked as solved can come back when things change. That’s why even eliminated risks get another look: the goal is to catch what’s new or returned.