Issue, risk or change request: how they differ

Every project produces three kinds of "things to deal with" that are often confused: what has already happened, what could happen and what someone is asking for. Treating them alike is an expensive mistake: each is managed differently, with a different owner, different deadlines and different consequences. This guide gives a simple rule to tell them apart and an example of each.

The three definitions

The decision rule

Ask yourself three questions, in this order:

1. Is someone asking for something that was not agreed? If so, it is a change request, even if the ask comes disguised as a problem ("the report has no region column" can be an error, if it was in scope, or a change, if it was not).
2. If not, has it already happened? If so, it is an issue.
3. If not, could it happen? Then it is a risk.

The first question is the most important, because it protects the scope: a change treated as an issue gets resolved "for free" inside the budget.

One example of each

• Issue: "The customer load failed: 300 records are missing". It has already happened. It is assigned to someone, given a severity and a priority, hours are logged until it is resolved, and it is closed.
• Risk: "If the client does not deliver the item data before the 15th, the migration will be delayed". It has not happened yet. It is noted with probability and impact and a plan: ask for the data in advance, prepare a partial load.
• Change request: "We want to add a sales-by-region report". It was not agreed. It is recorded with who asks for it, the effort is estimated and a decision is made on whether to approve it, and at what cost.

How they turn into one another

The three categories are not watertight compartments:

• A risk that occurs becomes an issue. If the client did not deliver the data, it is no longer watched: it is resolved.
• An issue can reveal a change. If, when investigating a "fault", it turns out the system does what was agreed but the client expected something else, what remains is a change request.
• A repeated issue often hides a risk that had not been seen: it is worth noting so that it does not happen again.
• An approved change can bring new risks: more scope, less margin.

Common mistakes

1. Mixing everything in a single list of "pending items". The distinction between urgent, important and optional is lost.
2. Treating changes as issues to avoid the awkward conversation with the client. The scope eats the budget without anyone seeing.
3. Not recording risks until they become issues, when there is no margin left to prevent them.
4. Giving every issue the same severity. Severity (how much damage) and priority (when it gets handled) are different axes: an issue can be serious and not urgent, or minor and urgent.
5. Closing without recording the cause, so the learning is lost.

How it works in PjMan

PjMan has a separate register for each, inside every project, so they do not get mixed:

• Issues: an entity independent of tasks, with a status (from an organisation catalogue the PM configures; by default Open, In analysis, In resolution, Resolved and Closed), severity and priority as separate axes, assignees, estimated and logged hours, detection and closing dates (the latter set automatically when moving to a final status), and an optional link to a phase or task. They have a list and a Kanban board, and count in reports (open, closed, average resolution time, unassigned). (Issues)
• Risks: with probability, impact, priority, status and mitigation plan. (Risks)
• Change requests: with requester, estimated effort, cost and timeframe, and a status of pending, approved or rejected. (Change requests)

Each has its short code (I0003, R0002, S0001), which is used to cite it in a conversation or to ask the assistant about it. Visibility also differs: project management sees all three, but a consultant can view and create issues tied to their work and has no access to risks or change requests. (Roles and access) Reports gathers the issue indicators of your projects. (Reports)

To go deeper, the guides on the risk register and on change requests cover each case in more detail.

Create your account or explore the demo.

Frequently asked questions

Is a client error in their own data an issue or a change? If it blocks the planned work, it is an issue (the blockage must be resolved). If the fix involves work that was not in scope, there is also a change to decide.

Where do I note something that could happen but I do not know how likely it is? In risks, with medium probability. The important thing is to leave it written down and review it.

Can I convert one into another? In PjMan each record is independent; if a risk materialises, you record the issue and close the risk. The history stays in each record.