Client Delivery
Part of Task and issue workflows
Separating issues, risks and ordinary tasks
Use separate records for planned work, present problems and uncertain future events.
Use separate records for planned work, present problems and uncertain future events. A task states an action and expected output. An issue describes a problem that exists now.
A risk describes something that might happen and what the team will do if it does. These are working definitions for a project workflow; a tool may use different labels, so agree on meaning before configuring it.
A quick classification test
Ask three questions. If an event has already happened and affects delivery, record an issue. If someone is expected to complete a defined action regardless of an uncertain event, record a task.
If the event is still uncertain but would alter delivery if it occurred, record a risk with a trigger and response. One situation can produce linked records without becoming three copies of the same description.
Consider a hypothetical launch. “Prepare product images” is a task. “The approved image file is corrupted” is an issue. “The supplier may deliver final packaging late” is a risk.
The risk may call for a task to secure a backup image plan. If the supplier misses the agreed date, record the actual impact as an issue while retaining the original risk assessment.
Distinguishing Tasks, Issues, and Risks in Project Management
- TaskPlanned action with expected output. Example: 'Prepare product images'.
- IssueProblem that already exists and affects delivery. Example: 'The approved image file is corrupted'.
- RiskUncertain future event that could impact delivery. Example: 'Supplier may deliver final packaging late'.
Give each record enough information
A task needs an owner, output and due date or review trigger. An issue needs observed facts, affected work, impact, next investigation and resolution criteria. A risk needs a condition, possible consequence, owner, planned response and trigger for escalation. Avoid assigning a false probability where the team has no basis; a qualitative priority with an explanation may be more honest.
Atlassian's workflow documentation shows that statuses, priority and resolution are distinct fields in Jira. That is a useful warning against using “high priority” as an issue type or “resolved” as proof that a risk cannot recur. The product's labels should support the team's distinctions rather than determine them.
Key Elements for Effective Record Management
- Task Requirements
- Owner, output, due date or review trigger
- Issue Requirements
- Observed facts, affected work, impact, next steps, resolution criteria
- Risk Requirements
- Condition, consequence, owner, response plan, escalation trigger
Keep the relationships visible
When an issue blocks a deliverable, connect the records and state the dependency. The deliverable's owner still owns the work, but the issue has its own investigator. When a risk response creates a task, link it to the risk so the team can see whether the response was completed. Do not close the risk merely because a mitigation task was created.
Review each class differently. Task review asks whether work is progressing and acceptable. Issue review asks whether the problem still exists and what can restore progress.
Risk review asks whether exposure has changed, whether the trigger has occurred and whether the response remains feasible. A single backlog meeting can cover all three, but one undifferentiated count cannot describe project health.
Managing Risk Responses in Project Workflows
- Identify riske.g., 'Supplier may deliver final packaging late'
- Create mitigation taskLink task to risk (e.g., 'Secure backup supplier agreement')
- Monitor and reviewTrack if trigger occurs; assess if response remains feasible
- Close with reasonRecord outcome: e.g., 'Risk retired – supplier delivered on time' or 'Risk materialised – now an issue'
Review Practices for Each Record Type
- Task ReviewIs work progressing? Is the output acceptable?
- Issue ReviewDoes the problem still exist? What restores progress?
- Risk ReviewHas exposure changed? Has trigger occurred? Is response still feasible?
Close with a reason
Record why an issue was resolved or why a risk was retired. A duplicate issue, a fixed defect and a no-longer-relevant request are different outcomes. Keep the decision visible so a later project does not repeat an investigation. If a risk materialises, do not rewrite it as though it always was an issue; the prior record may explain what the team knew and planned at the time.
