Kirk Kendall | Risk Management Isn't About Avoiding Problems — It's About Seeing Them Early

Kirk Kendall

Most project teams talk about risk management as if it's about preventing bad things. Avoiding delays. Avoiding cost overruns. Avoiding accidents. The goal is to identify risks and eliminate them.

But here's the reality of complex industrial construction: you can't eliminate most risks. You can only manage them.

Kirk Kendall thinks about risk management differently. It's not about prevention—it's about seeing. The project that anticipates where problems might emerge is positioned to handle them when they do. The project that's surprised by problems is in trouble.

This comes from military background as much as project experience. In military operations, you can't prevent all enemy actions. But you can anticipate them. You can plan for likely scenarios. You can position yourself so that when something happens, you have options.

Same with projects. Weather will probably create delays—that's not a risk to eliminate, it's something to plan around. A supplier might fail to deliver on schedule—that's not something to ignore, it's something to build contingency for. A site condition might be different from what was assumed—that's something to anticipate and have strategies for.

Real risk management on industrial projects starts with understanding what could realistically go wrong. Not catastrophic things—you can't plan for all possible disasters. But the things that have actually happened on similar projects. What could disrupt your critical path? Where are you dependent on things outside your control? What are the points where small problems could cascade?

One big project Kirk managed had complex supply chain requirements—major equipment with long lead times from overseas. The risk wasn't that the equipment might be defective. The real risk was that delivery timelines might slip, or that equipment might be delayed in transit. So the plan built contingency. Extra time was built into the schedule at key points. Alternative suppliers were identified for certain components. The logistics timing for installation was front-loaded so that delays had less impact.

Did problems happen? Yes. A supplier delayed delivery of a critical component. But because that risk had been anticipated and managed, it didn't derail the project. The team had a response ready. The delay was absorbed because the schedule had flexibility at that point.

Compare that to projects where risk management is just a checkbox. A risk register gets created with hundreds of line items. Each has a probability and impact rating. And then... nothing happens. The register sits in a file. When the problems that were listed actually occur, the team is surprised.

Real risk management is different. It's identifying the risks that would actually matter. A delay in equipment delivery matters if it affects your critical path. It doesn't matter if it affects non-critical items. A site condition matters if it changes how you can work. It doesn't matter if it's just something unusual. A weather delay matters if your schedule is tight. It matters less if you have time built in.

So good risk management starts with understanding your project—really understanding it. Where is your flexibility? Where is it tight? What are the decision points where you need information? What are the sequences where one delay cascades?

Then you identify the risks that actually affect those points. And you build mitigation strategies, not abstract ones, but concrete ones. If a supplier might be late, what will you do? Switch to another supplier? Accelerate an earlier phase? Adjust a later phase? Have that decision made before the risk occurs.

Kirk has seen this work repeatedly. A project that anticipated logistical challenges built stages so that site preparation could happen even if equipment delivery was late. A project that understood regulatory complexity front-loaded interactions with authorities so that approvals wouldn't surprise the schedule. A project that knew its workforce market built training and incentives ahead of time so they could attract the crew they needed.

None of these projects avoided all problems. But they anticipated the problems that mattered and they were positioned to respond.

There's also a discipline to risk management that involves consistent monitoring. You don't just identify risks at the beginning and forget them. You track them. Did a risk that you thought had low probability suddenly become likely? Are you entering a phase where a different risk becomes critical? Are conditions changing in ways that affect your assumptions?

This requires discipline and it requires competence. A project manager needs to understand the project deeply enough to notice when conditions change. That's harder than just checking a list, but it's what actually works.

The discipline also includes something that's uncomfortable: being willing to escalate risk. If something is becoming a real problem and your current mitigation strategy isn't working, you need to surface that early. Not when you're desperate. When you still have options. That requires honesty about how things are actually going, not optimism about how you hope they'll go.

One element Kirk emphasizes is building resilience into projects, not just planning to avoid problems. Resilience means you have flexibility. You have alternatives. If one approach isn't working, you have a different approach. If one supplier fails, you have another. If one sequence gets disrupted, you can still succeed with a different sequence.

Projects with good resilience can handle uncertainty. Projects without it are fragile. They depend on everything going right. And on complex industrial projects, everything rarely goes right.

So risk management isn't about eliminating risk. It's about seeing what could go wrong, planning how you'd handle it, and building resilience so that when something does go wrong—and something will—you're not surprised and you're not powerless.

That's the difference between projects that manage risk and projects where risk manages them.