Risks, issues and change requests
as separate records, not tasks.
What might happen, what has happened and what you are asking to change each get the record its job needs, linked to the others, so the task list stays a list of work.
What you get
Three records, linked
A risk can become an issue, and an issue can raise a change request, and each keeps the link to where it came from.
A risk register on every project
Record what could go wrong, with a severity, a category (schedule, resource, budget, scope or external), the tasks it touches and what to do about it. Edit it as it changes, and dismiss what no longer applies.
AI risk detection
Run an analysis and the AI reads the plan for schedule, budget, resource and scope risks, each with a suggested mitigation, for you to keep or dismiss.
An issue log for what has happened
Nine issue types, four severities and a lifecycle from open through investigating to resolved and closed, per project and across the whole organization.
When a risk happens, promote it
Promote a risk and an issue is drafted from it for someone to accept. The accepted issue keeps the link to its risk, and the risk is marked resolved. When the answer is work, turn the risk into a task instead.
Change requests with their impact
Ask to change scope, schedule, budget or resources as its own record, with the impact in days and in money written down before anyone approves it.
A change control board that decides
Project managers, the organization's board members or named reviewers approve or reject. An approved change is marked implemented, and every step stays in its history.
Change requests that name their cause
When fixing an issue means changing the plan, raise the change request from the issue, and each change request lists the issues raised against it.
Risks in the finish date
Give a risk a probability and an impact in working days, and the Monte Carlo run counts it when it works out how likely the plan date is.
Might happen, has happened, asks to change
Each record answers a different question
The PMBOK Guide keeps these apart for a reason: they are reviewed by different people, on different days, for different decisions.
A risk asks what we will do if it happens, so it carries a severity, a category and a response.
An issue asks who is fixing it and by when, so it carries a type, a severity, an owner and a status from open to closed.
A change request asks whether we agree to change the plan, so it carries the impact in days and money and a decision with a history.
Free, no account
See the risk in a schedule you already have
Upload a Microsoft Project or Primavera file and get the finish dates it is likely to hit, or the problems hiding in its logic.
Questions about risks, issues and change requests
Which plan do I need?
The risk register works on every plan, with or without AI, and the issue log is on every plan, including Free. AI risk detection is on the Professional plan and up, and counting risks in the Monte Carlo finish date on the Business plan and up. Change requests and the change control board are on the Enterprise plan and up.
What is the difference between a risk, an issue and a change request?
A risk is something that might happen, so you plan a response before it does. An issue has already happened and needs an owner and a fix. A change request asks to change what was agreed, its scope, dates, budget or people, and needs a decision. Keeping them as three records means each one has the fields and the lifecycle its job needs.
Why not track them all as tasks?
A task is work to do. A risk may never need any, an issue needs a severity and a resolution, and a change request needs an impact and an approval. Put all three in the task list and the schedule fills with items that are not work, while the register a sponsor asks for does not exist. In Onplana a risk becomes a task only when the answer to it is work.
What happens when a risk comes true?
Promote it to an issue. Onplana drafts the issue from the risk's description and response, and once someone accepts it the issue keeps the link back to the risk and the risk is marked resolved, so the register shows which risks turned into problems. If dealing with the issue means changing the plan, raise a change request from the issue.
Does the AI decide which risks matter?
No. The analysis suggests risks with a mitigation for each, and they sit in the register for a person to keep, edit or dismiss. Nothing reaches the plan until someone acts on it.
Give the sponsor a register, not a task list.
Start free with the risk register and the issue log, and add change control when the programme needs a board.