Capturing & Tracking Risks

*Adapted from David Root (2014)

Techniques & Process (“Capturing”)

  • Use formalized brainstorming sessions: bring together diverse stakeholders, have prompts, facilitator/scribe/timekeeper.
  • Employ Software Risk Evaluation (or similar moderated sessions) to systematically assess risk candidates.
  • Use taxonomy-based questionnaires (risk categorization / checklists) to ensure coverage.
  • Risk forms / templates: as soon as someone identifies a concern, fill out a risk form with condition + consequence.
  • Ensure everyone in any activity can identify and report risks—not only managers or formal roles.

Assigning Responsibility

  • Every risk should have an owner: someone with authority and resources to act. Without assignment, risks tend to be ignored.
  • The owner must have:
    1. Responsibility – make sure tasks related to that risk are taken.
    2. Authority – ability to make decisions or escalate.
    3. Resources / capability to respond.
  • For some risks, consider transfer (outsourcing, insurance, third parties). But even if transferred, you should still monitor it.

Mitigation Strategies

  • Must be doable / realistic: fit the project’s constraints (time, budget, people).
  • Types of mitigation strategies:
    • Prevention / avoidance – eliminate the risk’s cause or reduce likelihood.
    • Reduction / minimization – lessen impact if risk occurs.
    • Contingency planning – what to do if risk becomes real.
    • Training / skill building – reduce risk by increasing team capability.
    • Processes / procedural changes – add reviews, checkpoints, quality gates etc.
    • Awareness raising – ensure people know about the risk so they can act.

Tracking & Review

  • Risks should be reviewed periodically, with frequency depending on project size, criticality, stability of environment.
  • Remove risks that are no longer applicable (“no longer risks”, “obsolete”, or they’ve been resolved / mitigated).
  • Identify which risks have become issues/problems.
  • Monitor changes in priority, impact, or likelihood over time. Some risks decrease in impact / probability as mitigations take effect.
  • Track mitigation strategy progress: Is the planned action done? Is it helping?

Examples (Mitigation / Responsibility / Tracking)

Example # Condition Consequence(s) Possible Mitigation(s) / Assigned Owner / Tracking
Ex 1 There is a puddle of water on the floor. ‒ Carpet may be ruined
‒ Someone may slip and get hurt
‒ Equipment (electronic) may short out		 Mitigation: Immediate cleanup; place warning signs; identify source of water leak and repair; have a policy for floor inspections.
Owner: Facilities or safety manager.
Tracking: daily checks until leak fixed; weekly inspections; log incidents.
Ex 2 Historically, project teams have lost a team member in the first 3 months. Project scope, schedule, quality may/will change (disruption, knowledge loss) Mitigation: Cross-training; knowledge documentation; backup staffing; hiring buffer; mentor pairing.
Owner: Project manager / HR.
Tracking: monitor staff turnover; early months stress; schedule risk reviews early.
Ex 3 The project requires the use of C# and no one on the team has experience with it. Delays due to learning curve; bugs; lower productivity; possibly poor design decisions Mitigation: Training; bring in consultant or hire someone with C# experience; pair programming; prototyping; allocate more time for development.
Owner: Technical lead or engineering manager.
Tracking: track learning progress; measure productivity; adjust schedule if needed; monitor code quality.

When & Where to Identify / Track & Where to Review

  • Anytime, anywhere: as soon as there’s a concern, during any meeting / artifact review / design work.
  • Use “statement of fact” style for capturing: helps avoid speculation / fuzzy language.
  • Scheduled reviews: decide upfront (e.g. weekly for critical/high-risk projects, monthly for stable ones) and include them in project plan.
  • Triggered reviews: after major changes (scope change, new technology, external event for project), after incidents, or after stakeholder feedback.

Acknowledgments

This content is heavily inspired by and adapted from lectures by Eduardo Miranda and David Root on software project management. The structure, examples, and pedagogical approach reflect their teaching materials and frameworks.

Sources

  • ISO 31000: risk management standard – emphasizes roles, integrating risk into decisions, monitoring, etc. Wikipedia
  • PMI / PMBOK guides: frequency of risk review / communication depends on project nature; status updates / risk reporting schedule form part of risk management plan. Project Management Institute Project Management Stack Exchange

  • Best practices articles (e.g. AuditBoard, Everbridge, IBM) on mitigation strategies: set clear roles, involve stakeholders, use tools / templates, monitor continuously. AuditBoard Everbridge

  • Root, David. Managing Software Development. Lecture materials, 2014.

Disclaimer: AI is used for text summarization, explaining and formatting. Authors have verified all facts and claims. In case of an error, feel free to file an issue.