Find the risk before it becomes the problem

I think about operational risk very simply: what could prevent the business from operating the way it's supposed to?

That could be a process failure, a project problem, missing information, unclear responsibility, a vendor issue, a system dependency, an employee dependency, or something else inside the operation.

Operational risk isn't only about major disasters. Small weaknesses that happen repeatedly can be just as damaging over time.

Start with the processes the business depends on most. Then ask what those processes depend on — people, equipment, suppliers, information, software, approvals, another department?

Once we understand those dependencies, we can start asking what happens if one of them isn't available or doesn't perform as expected.

The biggest risk isn't necessarily the problem that happens most often. Sometimes it's something that happens rarely but would have a major impact if it did.

Knowing that a risk exists is different from understanding it well enough to manage it.

I would want to know how likely it is, what the actual impact could be, what controls already exist, whether those controls work, who owns the risk, and what happens if the risk occurs anyway.

An assessment also tends to uncover dependencies that aren't obvious when you're looking at each department separately.

I don't believe every risk should automatically become a major project.

We look at likelihood and impact, but I also consider how easily the problem can be detected, what controls already exist, how difficult recovery would be, and how much it would cost to reduce the risk.

Then management can make a business decision. Some risks need immediate action. Some need monitoring. Some can reasonably be accepted. That's still risk management.

It's something the operation depends on that doesn't have a practical backup.

For example, only one employee knows how to perform an important process. Or only one supplier can provide a critical material. Or one spreadsheet contains information the entire department needs.

Everything may work perfectly for years. The risk becomes visible when that one thing suddenly isn't available.

It can be a significant one.

That employee may be excellent at what they do, but the company has created a dependency. What happens if they're sick? Take vacation? Leave the company? Become overwhelmed?

The solution isn't to make that employee less valuable. It's to make sure critical business knowledge isn't available only through one person — through documentation, cross-training, clearer processes, or backup responsibilities.

Probably both.

If the same problem keeps happening, I want to understand why the process allows it to happen repeatedly. But once we know it's recurring, it's also a known operational risk.

At that point, management should be asking what is being done differently to prevent the next occurrence. Fixing today's problem and managing tomorrow's risk should happen together.

A risk is something that could happen. An issue is something that is happening.

That distinction matters because you manage them differently. With a risk, we still have an opportunity to prevent it, reduce its likelihood, prepare for it, or monitor for warning signs. Once it becomes an issue, we're responding to something that has already occurred.

I would much rather have that conversation while it's still a risk.

You can't predict everything. But many problems leave clues.

Maybe deadlines are starting to slip. Exceptions are increasing. Employees are creating more workarounds. A vendor's performance is declining. Rework is increasing. A backlog is growing.

The information may already exist. The question is whether anyone is watching the right things and whether someone knows when action needs to be taken.

Because having a risk register and managing risk are not the same thing.

If risks are documented once and then nobody looks at them until the next review, the document isn't doing much. Risks change. New ones appear. Existing ones become more or less important.

The useful part is assigning ownership, monitoring meaningful indicators, and having a clear process for escalation and response. The register is just where we keep track of it.

I like risk management to be part of normal project management rather than a separate exercise.

During the project, we should continuously be asking: What has changed? What are we waiting on? What could affect the next milestone? Are dependencies still on track? Has a previously identified risk become more likely? Has something new appeared?

A project risk shouldn't become visible for the first time when the schedule is already late.

It depends on how much the operation depends on that supplier.

A supplier can have an excellent history and still experience something outside its control. I would look at the consequence of losing that supplier and how difficult it would be to replace them.

If replacing them takes two days and has little impact, the risk may be relatively small. If replacing them takes six months and stops production, that's a very different conversation.

By making the control proportional to the risk.

Not every task needs three approvals. Adding controls everywhere can make operations slower and encourage people to find ways around the process.

I want to know what we're trying to prevent, how serious the consequence is, and what the simplest effective control would be. Good risk management should make the business more reliable, not impossible to operate.

Sometimes.

Automation can reduce risks created by repetitive manual tasks, missed notifications, inconsistent processes, or information being transferred manually.

But automation can create new dependencies too. If an automated process becomes critical to the business, we need to understand what happens when that automation fails. Technology changes the risk — it doesn't automatically eliminate it.

There isn't one schedule that works for every risk.

A rapidly changing project may require frequent risk reviews. A stable business process may not. I prefer determining the review frequency based on how quickly the risk can change and how serious the impact could be.

The important thing is that risk management doesn't become an annual exercise that everyone forgets about for eleven months.

Absolutely.

Growth can create risk because the business changes faster than its processes. A process that worked with ten employees may not work with fifty. The owner may no longer be able to personally oversee everything. More customers create more transactions. More employees create more handoffs. More systems create more dependencies.

Growth isn't the problem. The risk comes when the operating structure doesn't grow with the business.

Those areas may affect operational risk, but they require specialized expertise.

My focus is on operational and project risk — the processes, dependencies, controls, responsibilities, information flows, and business systems that affect how work gets done.

If an assessment identifies an issue that requires legal, cybersecurity, insurance, safety, or another specialized professional, I believe the right approach is to involve someone qualified in that area rather than pretend one consultant should do everything.

I start by understanding the business and the areas management is concerned about. Then I look at the processes the company depends on.

I want to understand how the work actually happens, what it depends on, what has failed before, where management has limited visibility, and what would happen if an important part of the process stopped working.

From there, we identify and prioritize the risks, evaluate existing controls, and determine what actions make sense. The goal isn't to hand management a long list of everything that could possibly go wrong — it's to help them understand what matters, what needs attention, and what they can do about it.