These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
- OKR Tracking System
- Features
- Blockers and risks
Blockers and risks
Put raised issues and project risks in front of the people who own them.
OverviewFailed Operations×
OKR Tracking System · Blockers and risks
New
Failed Operations
Operation receipts
| Receipt number | Operation type | Reference | Occurred at | Result | Actor | |
|---|---|---|---|---|---|---|
| OR-81602 | Project Created | RFR-961 | 19 Oct | Failed | ||
| OR-71123 | Work Package Created | RFR-922 | 19 Oct | Failed | ||
| OR-37995 | Task Created | RFR-950 | 26 Oct | Failed | ||
| OR-57193 | Task Status Changed | RFR-306 | 13 Oct | Failed | ||
| OR-11882 | Time Entry Submitted | RFR-452 | 06 Oct | Failed |
6 of 6 records
RFR-961Operation receipts · OR-81602
Project CreatedOccurred at19 Oct
ResultFailed
What you can do
Triage an issue and monitor exposure
A blocker records severity, status, raised date, project, reporter and owner. When an existing issue is set to Open, the triage workflow checks its severity. With severity present it changes the status to Triaged and writes an operation receipt. If the issue is no longer Open or has no severity, the attempted triage is blocked and a failed receipt is recorded. Risks carry probability, impact, mitigation, owner and project links for ongoing review.
Setting an eligible issue to Open starts the configured triage action. The blocker owner checks the resulting status and receipt before continuing resolution work. A risk remains a separate record with probability, impact and mitigation; it can stay under monitoring after the immediate blocker has moved forward.
How the work is organized
- Route the blocker. Record severity, the person who raised it and the owner on the issue linked to the objective.
- Watch exposure. Keep probability, impact and mitigation on the separate risk record.
- Check the receipt. After triage, compare the issue status with the operation result before assigning resolution work.
What to agree during setup
Agree severity meanings and who takes ownership of an Open blocker. Define when a fixed blocker is verified and closed. For risks, decide when monitoring begins, what a useful mitigation note contains and who changes status after the exposure passes. Use one issue with severity and one without it to rehearse triage. Ask the blocker owner to inspect both receipts and tell the project manager which issue needs correction.
Check the handoff on an actual case
A team member raises a high-severity blocker on an active objective. Setting the eligible blocker to Open starts triage; the blocker owner checks the resulting status and receipt. The manager can see the triaged status, then follow it while work is in progress and through fixed and verified. A separate schedule risk remains open with a mitigation note so the objective owner can review both the immediate issue and future exposure. When the fix is ready, the project manager checks the original issue before verification. The risk owner keeps the mitigation current until that separate exposure is resolved.
What your team sees
- Open Blockers — Open, triaged and in-progress issues by severity and owner.
- Active Risks — Open and monitored exposure with probability and impact.
Follow the work through
What it keeps track of
Data model- Blockers
- Defects and change items raised against project work.
- Risks
- Project risks with probability, impact, owner and mitigation.
- Objectives
- Engagements delivered for an organization, with budget and schedule.
- Team members
- Delivery staff with role, practice and weekly capacity.
- Operation receipts
- Evidence that a delivery operation was executed.
Who uses it
Permissions- Blocker Owner
- , Project Manager.
- The Blocker Owner follows triage and resolution; the Project Manager checks verification and its effect on the objective.
Set up OKR Tracking System your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.