Operational Resilience in Practice: Process Design
Operational resilience is directly proportional to the strength of your ITSM processes, which is why process design is critical. If your processes aren’t designed to work in practice, they won’t perform when it matters — and that’s where resilience breaks down.
In the previous article, we looked at process assessment — how to understand how your processes actually perform. That’s where you move from assumptions to facts.
Process design is what comes next.
Once you understand where things break down, the challenge is not adding more process — it’s designing processes that actually work in practice and support operational resilience.
ITSM Process Design
Process design is where operational resilience starts to get built.
It’s how you take what you learned in your assessment and turn it into something people can follow — consistently, predictably, and under pressure.
Most organizations don’t struggle because they lack processes. In fact, most are over-documented. The issue is that their processes don’t reflect how work actually gets done.
They’re too complex. Too rigid. Or disconnected from reality.
The problem isn’t process.
It’s poor process design and management.
The Pendulum Swings
We’ve seen this before.
Back in the mainframe days, IT environments were tightly controlled. Processes were strong, reliability and operational resilience was high, and everything was predictable — but agility suffered.
Then came distributed computing. The business moved faster, but reliability, consistency, and control took a hit. Systems ended up back in the data center so controls could be reintroduced.
Now the pendulum has swung again.
Process is often viewed as a constraint. Frameworks like Agile and DevOps are sometimes interpreted as a way to bypass process in the name of speed.
But that’s not what’s actually happening.
Agile and DevOps didn’t remove process — resilient organizations have replaced bad process with better process design.
You cannot move faster, reduce errors, and improve reliability without a process that supports execution.
Every industry depends on this.
A factory doesn’t improve throughput without well-designed processes. A logistics company doesn’t deliver reliably without them. A hospital doesn’t respond effectively in an emergency without them.
IT is no different.
What Good Process Design Looks Like
There’s more to process design than a flowchart.
A process defines how work actually gets done — who does what, when, and with what inputs and outputs. It defines how decisions are made, how work moves between teams, and how performance is measured.
When those elements are unclear, execution becomes inconsistent.
And inconsistency is where operational risk shows up.
Good process design reduces that variability. It creates clarity, and that clarity leads to consistent execution.
That’s what improves operational resilience.
👉 Recorded Webinar: Process Mapping Workshop
Designing for Execution
Process design is not an academic exercise.
It’s not about creating the perfect model or aligning perfectly to a framework. It’s about designing something that works in the real world.
Start with what you learned in your assessment.
Where does execution break down? Where do teams operate differently? Where are delays introduced? Where does risk show up in day-to-day work?
Design around those realities.
You don’t need to start from scratch. Organizations are more alike than they are different, which is why best practices exist. But they are guidelines, not the law. The process still needs to reflect your environment, your teams, and your constraints.
A process that looks good on paper but doesn’t work in practice does nothing for operational resilience.
Collaboration Drives Adoption
You cannot design a process in isolation.
This is where many organizations get it wrong. Processes are designed by a small group, documented, and then pushed out with the expectation that people will follow them.
They don’t.
You need to involve the people who actually run the process — not just process owners or leadership, but the people doing the work.
That’s where the real insights come from. It’s also where you build buy-in.
If the people executing the process didn’t help design it, they won’t follow it.
Even well-designed processes will face resistance, which is why design must be paired with accountability and governance. But collaboration during design is what makes adoption possible in the first place.
👉 Read: 7 Simple Rules for Process Design
Keep It Simple
Complexity is one of the biggest reasons processes fail.
Too many steps, too many approvals, too many edge cases — all of it creates confusion and slows things down.
Good process design focuses on clarity and usability.
Keep it as simple as possible — but no simpler than the risk requires.
The goal is not to document every possible scenario. The goal is to enable consistent execution across the organization.
If people can’t understand the process, they won’t use it. And if they don’t use it, it doesn’t matter how well it was designed.
Automation Follows Design
Automation is important, but it comes after process design.
Too often, organizations let tools define their processes. “Out of the box” becomes the default approach, even when it doesn’t reflect how the organization actually operates.
Before you automate, you need to define how the process should work.
Who is responsible? What approvals are required? What data needs to be captured? How does work move from one team to another?
Automation should support your process — not define it.
Validate and Iterate
You don’t get process design right in one pass.
Validation is critical.
As you design, bring stakeholders back in. Walk through the process. Use working sessions. Show how it will actually operate.
This helps you catch issues early, make adjustments quickly, and build confidence in the design.
Process design should be iterative. The goal is not perfection — it’s something that works and can improve over time.
What This Looks Like in Practice
When process design is done well, the impact is obvious.
You see consistency across teams instead of variation. Roles are clear, handoffs are smoother, and rework starts to decrease. Work flows more predictably, and issues are easier to identify and resolve.
More importantly, the process holds up under pressure.
That’s the real test.
Operational resilience doesn’t show up when things are running smoothly. It shows up when something breaks.
Well-designed processes reduce variability — and variability is where operational risk lives.
In the Next Article: Process Governance
Process design is where improvement starts to take shape.
It takes what you learned in your assessment and turns it into something operational — something people can follow and rely on.
But even well-designed processes don’t sustain themselves.
In the next article, we look at process governance — how to ensure your processes are followed, measured, and continuously improved.
Process design is what turns assessment into action. Without it, you understand the problem but don’t fix it. With it, you build processes that perform — consistently, reliably, and at scale — and that is what drives operational resilience.