Risk and Decision Management: The Problem I Couldn't Ignore

I'm the founder of Causr and after managing projects in different industries for over six years, there is a problem that I couldn't ignore any longer.

In these projects we never struggled because Jira could not track risks or dependencies. We struggled because the important conversations lived somewhere else.

A decision made in a team or stakeholder meeting. A supplier commitment buried in a group Slack. A stakeholder changing direction on a call. By the time anyone realised what had changed, the milestone had already moved. Even with AI notetakers, the context still needed somewhere central to live.

That is why I started building Causr.

Most project teams do not have a shortage of tools, far from it.

They have task boards, plans, Slack channels, meeting notes, status reports and RAID logs. The problem is that the information that determines whether a project will deliver is spread across all of them and it requires reconstruction.

The task is tracked in one place. The decision that changed it is recorded somewhere else. The stakeholder commitment it depends on may not be recorded at all.

Project managers are left to hold those connections together.

I built Causr because project delivery depends on relationships that most tools treat as separate entries. Risks, blockers, decisions and updates only become useful when you can see what they affect. With an estimated 57% of projects failing with poor communication listed as a leading cause (PMI report), there needs to be a solution.

Work management software is good at tracking work. It can show what is in progress, what has been assigned and what remains open. That is useful. It is also only part of the delivery picture.

A task can be marked as on track while the milestone around it is already exposed.

The technical work may be progressing, but a supplier has not confirmed the integration date. The team may have completed its actions, but a decision from legal is still outstanding. The plan may show the right sequence, but the assumptions behind that sequence changed during a call three days ago.

None of this means the task system has failed. It means tracking work is not the same as understanding delivery.

Project managers operate in the gap between those two things, communication is the root of our roles. We need to know what is happening, but also why it is happening, what it affects and who needs to respond. Most systems do not hold that view. The project manager does.

RAID logs were supposed to help teams manage uncertainty. Too often, they become documents prepared for governance.

They are updated before the steering committee. Risks are rewritten so they make sense to people outside the project. Scores are reviewed. Old entries are closed. New ones are added because somebody remembers a conversation from the previous week.

The log may be accurate by the time the meeting starts.

That does not mean it helped manage the project while the problem was developing.

The issue is not that project managers are maintaining RAID logs badly. The issue is that the format asks them to turn a changing delivery situation into a set of independent rows.

A risk sits in one row. The decision that created it may sit in another file. The blocker that made it urgent appears somewhere else. The milestone under threat remains in the plan.

The project manager still has to connect them. A risk register can tell you that something is amber. It often cannot tell you the chain of events that made it amber without the project manager explaining it. That explanation is where most of the value sits.

Experienced project managers notice things before they appear in reporting, this is the fantastic skill honed over time.

They hear hesitation in a supplier update. They recognise that a minor change in scope will affect testing. They know that a stakeholder saying "that should be fine" is not the same as a confirmed decision.

This can look like instinct. Usually, it is context.

The project manager remembers the earlier conversation, the unresolved dependency and the commitment made two weeks ago. They understand how those things relate to the current milestone.

The problem is that this context often exists only in their head.

It may also be spread across notes, messages and documents, but the useful connection between each item still depends on the project manager remembering it.

That creates a fragile delivery model especially with a team so focused on their areas of influence and responsibility to the delivery process.

The more complex the project becomes, the more information the project manager has to carry. Add another supplier, another workstream or another steering group, and the mental load increases again.

When the project manager is stretched, the connections are harder to maintain. When they go on leave, somebody else has to reconstruct them. When a sponsor asks why a milestone moved, the answer depends on how quickly the project manager can rebuild the history.

Projects should not rely on one person remembering every important conversation in the right order.

When a milestone slips, the cause often looks obvious in hindsight. It's why 'hindsight is a wonderful thing' — in most cases. The approval came late. The supplier changed its estimate. The team worked from an assumption that was never confirmed. A decision remained open longer than expected.

But, these things rarely arrive as clear delivery events. They emerge through conversation, the intangible.

A concern is raised in a meeting but not treated as a risk because the context may be missing. A stakeholder asks for more time without confirming what that means for the plan. A dependency is mentioned in Slack and acknowledged with a thumbs-up. A decision is postponed until the next call and suddenly the priority begins to slip.

Each event looks manageable on its own. The impact becomes clear later, when the dates no longer work.

By then, the project manager is trying to explain not only that the project has slipped, but why.

They go back through meeting notes. They search Slack. They check who attended which call. They compare an old status report with the current plan. They try to establish when the situation changed and whether anyone agreed to it.

This work is treated as reporting. It's really reconstruction.

The information existed throughout the project. It just was not connected to the thing it affected.

There is a familiar point in a project where the reporting still looks acceptable, but the project manager knows something is wrong.

The milestone is still green. The team has not formally raised a blocker. The supplier has not missed a date yet.

But the conversations have changed.

Commitments are becoming less specific. Decisions are taking longer. Updates need more caveats. The contingency is being used without anyone calling it contingency.

The project manager knows the position is weakening. They may not yet have enough evidence to change the status or escalate the issue. So they keep watching, asking and following up.

This gap between knowing and proving is one of the hardest parts of delivery.

Raise the issue too early and it can sound subjective, raise it too late and the obvious question is why nobody saw it coming and suddenly it's all fingers pointing at you.

Better project reporting does not solve this on its own. The problem starts before the report is written.

Project managers need a way to capture the signals while they are still signals, connect them to the plan and build a clear history as the situation develops.

I did not start by trying to build a better delivery manager. I also did not want to create another place where project managers copy information shortly before a governance meeting.

I started with the relationships. A risk matters because it threatens a milestone, a blocker matters because it is holding up work and somebody owns the response, a decision matters because it changes what happens next, and an update matters because it changes the current understanding of the project.

Causr connects those things.

Instead of treating a risk as an isolated row, it links the risk to what it affects, who owns it and what is being done. A decision remains connected to the milestone or dependency it changed. Updates build a history around the item rather than disappearing into a weekly report.

The aim is not to record more information.

It is to preserve the connections that project managers already make in their heads. When a milestone moves, the reason should already be visible. The project manager should be able to explain what happened, when the position changed, who owns the response and what else may be affected. Not because they spent hours rebuilding the timeline.

Because the delivery story was captured while it happened.

Causr is not intended to replace Jira, Slack or the project plan. Those tools already have clear roles.

Jira tracks the work. Slack supports the conversation. The plan holds dates, milestones and sequence. Causr sits above them and holds the delivery context between them.

The important conversation may still happen in Slack. The technical work may still be managed in Jira. The project schedule may still live in the planning tool the organisation already uses.

I am not trying to move every part of project delivery into one system. I am trying to stop the important connections from disappearing between systems.

That distinction matters.

Most project teams do not need another tool that requires everyone to change the way they work. They need a clearer view of the risks, blockers, decisions and commitments affecting delivery.

Causr is being built for the person accountable for maintaining that view.

The measure of Causr is not how many risks a project manager can log.

It is whether they can understand the state of the project faster.

It is whether they can see which milestones are exposed before the status changes.

It is whether a new delivery lead can understand why the plan looks the way it does without spending two weeks interviewing the team.

It is whether a steering committee can focus on decisions rather than asking the project manager to explain the history behind every amber item.

Most of all, it is whether project managers can spend less time reconstructing context and more time changing the outcome.

That is the problem I could not ignore.

It is why I am building Causr.