Managing issues, risks and change requests

A project is not broken by one great catastrophe, but by small things nobody puts in order: a fault left without an owner, a risk that could be seen coming and nobody noted, a client request accepted verbally. Mixing everything in a list of pending items wipes out the difference between urgent and important. PjMan gives each thing its own register inside every project, with the fields that suit it: issues for what has already happened, risks for what could happen and change requests for what is asked outside the agreed scope. If you doubt which is which, the guide on issue, risk or change request explains it with examples.

Issues: what has already happened

An issue is something that has already occurred (a fault, a blockage, a data error) and has to be resolved. It is an entity independent of tasks. (Issues)

• Configurable status. Statuses are an organisation catalogue managed by the PM; by default Open, In analysis, In resolution, Resolved and Closed. Each status can be marked as final.
• Severity and priority, separately. How serious the problem is and how urgently it is handled are two different axes: an issue can be serious but not urgent.
• Assignees and hours. They are assigned to one or several people, with or without an account, and hours are logged against them, with an optional estimate, to know what it costs to resolve them.
• Detection and closing dates. The closing date is set automatically on moving to a final status and cleared when reopened.
• A link to the affected phase or task, and labels to group them by your own criterion.
• List and Kanban board, with the same issues by status columns. (Kanban and Gantt)
• Comments on each issue, with @ mentions that notify inside the application.

They can be created by the owning PM, project management (to flag what they detect) and consultants in projects where they have a task assigned, with limitations. It is the only one of the three that a consultant can open.

Risks: what could happen

A risk is something that could occur and would affect the project. It serves to anticipate. (Risks)

• Probability and impact, three levels each, and a priority from low to critical. They are three independent fields that you set: PjMan does not calculate an exposure or draw a matrix, and priority is what decides what to handle first.
• Status: identified, monitoring, mitigated or closed.
• Contingency or mitigation plan, so that the risk is not just a worry written down.
• Optional link to a phase or a task.

When a risk materialises it is recorded as an issue. The guide on the risk register explains how to identify and prioritise them.

Change requests: what is asked outside scope

A change request is an ask that falls outside the agreed scope: a new feature, an extra report, a change of mind by the client. Recording it leaves evidence of who asked for it, how much it would cost and what was decided, before it goes into the plan. (Change requests)

• Requester (free text, it does not have to be a user), description, estimated effort in hours, estimated cost and timeframe (free text).
• A simple workflow: every request starts as pending and is approved or rejected with a selector in the table itself; who decided and when is saved.
• Approving creates nothing by itself: it is the record of the decision; you create in the plan whatever tasks or phases follow.

The guide on change requests explains how to manage them so that the scope does not get out of control.

From the minutes or the email to the register

The three registers can be fed without typing every field. If you paste into the assistant the notes of a meeting or an email with requests, the assistant can propose at once the minutes, the follow-up tasks, the risks and the change requests it sees in the text, on a single confirmation card. Nothing is created until you confirm it. (Pasted text) And before a follow-up meeting, the assistant gathers the open serious issues, the risks and the unresolved change requests, with the days they have been pending.

Seeing it all together

• Reports gathers the issue indicators: open, closed, average resolution time, logged hours and unassigned, with their distribution by project or by phase. (Reports and queries)
• Queries lets you filter issues across all your projects by status, severity, person, labels and dates, and export them to a spreadsheet.
• The project summary shows how many there are of each kind and links to each register.
• The project status the assistant gives you includes open issues by severity, risks and pending requests.

Each role sees what applies to it

The owning PM manages everything. Project management sees the three registers read-only and can create issues. A consultant sees the issues that affect them and can create them tied to their work, but has no access to risks or change requests. (Roles and permissions)

Try it

Create your account, open a project and record an issue, a risk and a change request. Or explore the demo with sample data.