4.0 KiB
Risk Management
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.
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.
How It Works
We will examine this concept through four levels:
- What the concept means.
- How a project owner should use it.
- How you should review or challenge it as the manager.
- How it should eventually appear in your project-management system.
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.
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.
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.
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.
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:
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
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?
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.
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.
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.
Related Concepts
- Projects vs Operations
- Project Outcome
- Definition of Done
- Scope
- Milestone
- Dependencies
- Capacity
- Risk
- Project Health
- Portfolio Management