vault backup: 2026-07-23 14:57:54
This commit is contained in:
@@ -1,103 +1,110 @@
|
||||
# Risk Management
|
||||
Duration: 30–40 minutes
|
||||
|
||||
Duration: 30--40 minutes
|
||||
|
||||
## Definition
|
||||
|
||||
Identify, assess, mitigate, and monitor risks before they become project problems.
|
||||
|
||||
This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
|
||||
A **risk** is an uncertain event or condition that could affect the
|
||||
project's outcome, schedule, scope, quality, cost, or operations. An
|
||||
**issue** is a problem that is already happening.
|
||||
|
||||
## Simple Mental Model
|
||||
|
||||
The goal is not to add project-management bureaucracy. The goal is to make the project easier to understand, predict, and manage.
|
||||
> **Risk = might happen. Issue = is happening.**
|
||||
|
||||
Good project management tries to identify important uncertainty before
|
||||
it becomes a surprise.
|
||||
|
||||
## How It Works
|
||||
|
||||
We will examine this concept through four levels:
|
||||
Use a lightweight four-step process:
|
||||
|
||||
1. What the concept means.
|
||||
2. How a project owner should use it.
|
||||
3. How you should review or challenge it as the manager.
|
||||
4. How it should eventually appear in your project-management system.
|
||||
1. **Identify** what could prevent the outcome or next milestone.
|
||||
2. **Assess** probability and impact.
|
||||
3. **Respond** by avoiding, mitigating, transferring/sharing, or
|
||||
accepting the risk.
|
||||
4. **Monitor** the important risks as the project changes.
|
||||
|
||||
You do not need fake numerical precision. Low / Medium / High is often
|
||||
enough.
|
||||
|
||||
Example:
|
||||
|
||||
--------------------------------------------------------------------------
|
||||
Risk Probability Impact Response Owner
|
||||
-------------- -------------- -------------- -------------- --------------
|
||||
DevOps Medium High Confirm Project owner
|
||||
unavailable commitment
|
||||
before QA early
|
||||
|
||||
--------------------------------------------------------------------------
|
||||
|
||||
A dependency is something you know the project needs. A risk is
|
||||
uncertainty around what might happen.
|
||||
|
||||
## Example
|
||||
|
||||
The exercises for this lesson should use real projects from your environment such as Umami, Mogador, QA automation, data governance, website/Product initiatives, or projects dependent on DevOps and Security.
|
||||
|
||||
The objective is to move from theory to a repeatable management practice.
|
||||
Your project is on schedule, but Security has not reviewed an
|
||||
architecture required for production. The deadline has not slipped yet,
|
||||
but the unresolved review is a material risk. The project may already
|
||||
deserve Yellow health.
|
||||
|
||||
## How It Fits Into the Bigger Picture
|
||||
|
||||
The course builds progressively:
|
||||
|
||||
- Project vs operations establishes what kind of work we are managing.
|
||||
- Outcomes and Definition of Done establish what success means.
|
||||
- Scope establishes the project's boundaries.
|
||||
- Milestones establish meaningful progress.
|
||||
- Dependencies, estimation, prioritization, capacity, risks, and health make delivery more predictable.
|
||||
- Status reporting, meetings, ownership, and portfolio management make the system scalable.
|
||||
- Closing and the final PM system turn the concepts into an operating method.
|
||||
Dependencies tell you what the project needs. Estimation exposes
|
||||
assumptions. Risk management asks what could make those assumptions
|
||||
fail. \[\[Project Health\]\] then reflects important risks before
|
||||
deadlines are actually missed.
|
||||
|
||||
## My Company / Real-World Context
|
||||
|
||||
Your team works across departmental projects, Product work, operational incidents, tickets, data, QA, SEO/WCAG, and dependencies on IT teams such as DevOps and Security.
|
||||
Likely project risks in your environment include vendor delivery, DevOps
|
||||
availability, Security approval, Product requirement changes,
|
||||
operational interruptions, QA availability, data quality, and key-person
|
||||
dependencies.
|
||||
|
||||
The lesson should therefore be applied to an environment where:
|
||||
|
||||
- Project owners are usually members of your own team rather than dedicated PMs.
|
||||
- Operational work regularly interrupts project work.
|
||||
- Product and IT are important cross-functional partners.
|
||||
- You need portfolio-level visibility without personally maintaining every task.
|
||||
- Project owners should increasingly draft and maintain their own project plans while you validate, challenge, prioritize, and escalate.
|
||||
Focus on the few risks capable of materially changing delivery rather
|
||||
than maintaining a huge register nobody reads.
|
||||
|
||||
## CTO Perspective
|
||||
|
||||
The leadership objective is to move progressively from personally coordinating work toward building a management system that produces reliable outcomes.
|
||||
|
||||
The expected progression is:
|
||||
|
||||
```text
|
||||
Contributor → manages tasks
|
||||
Project Owner → drives milestones and delivery
|
||||
Manager → manages projects, priorities, risks and escalation
|
||||
Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs
|
||||
```
|
||||
A project should not remain Green merely because nothing bad has
|
||||
happened yet. Leadership status must be forward-looking.
|
||||
|
||||
### Questions to Ask
|
||||
|
||||
- What information do I need to make a management decision?
|
||||
- What should the project owner be responsible for maintaining?
|
||||
- What requires my intervention?
|
||||
- What can be standardized across every project?
|
||||
- Is the process helping delivery, or merely creating administration?
|
||||
- What could prevent the next milestone?
|
||||
- What assumptions are we relying on?
|
||||
- Which risk has the highest impact?
|
||||
- Who owns the response?
|
||||
- What can we do now?
|
||||
- What signal tells us the risk is becoming an issue?
|
||||
- Does this risk change project health?
|
||||
|
||||
## Meeting Scenario
|
||||
|
||||
**Situation:**
|
||||
|
||||
A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome.
|
||||
**Situation:** Security has not reviewed a required architecture and
|
||||
production is approaching.
|
||||
|
||||
**Possible response:**
|
||||
|
||||
> Let's bring this back to the project plan. Show me where we are against the next meaningful checkpoint, what is at risk, and what decision or help you need from me.
|
||||
> The milestone hasn't slipped yet, but the unresolved Security review
|
||||
> is now a material delivery risk. Let's get a committed review date and
|
||||
> escalate if that date threatens production.
|
||||
|
||||
## Key Takeaways
|
||||
|
||||
- The purpose of project management is predictable delivery, not documentation for its own sake.
|
||||
- Project owners should own increasingly more of the planning and maintenance.
|
||||
- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio.
|
||||
- Every concept learned should eventually contribute to one lightweight common project template.
|
||||
- The final system should make exceptions and problems visible without requiring you to inspect every task.
|
||||
- Risks are uncertain future events; issues are current problems.
|
||||
- Identify risks before they become blockers.
|
||||
- Focus on material risks.
|
||||
- Assess probability and impact.
|
||||
- Significant risks need an owner and response.
|
||||
- Health should reflect major risks before a deadline is missed.
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Projects vs Operations]]
|
||||
- [[Project Outcome]]
|
||||
- [[Definition of Done]]
|
||||
- [[Scope]]
|
||||
- [[Milestone]]
|
||||
- [[Dependencies]]
|
||||
- [[Capacity]]
|
||||
- [[Risk]]
|
||||
- [[Project Health]]
|
||||
- [[Portfolio Management]]
|
||||
- \[\[Dependencies\]\]
|
||||
- \[\[Project Health\]\]
|
||||
- \[\[Estimation and Forecasting\]\]
|
||||
- \[\[Capacity and WIP\]\]
|
||||
- \[\[RAID\]\]
|
||||
|
||||
Reference in New Issue
Block a user