Keep it simple and practical

Complexity creeps into organizations. Each incident leads to a new control, each audit finding to a new form, each exception to a new rule. Over years, processes accumulate steps that nobody can fully explain, and the effort spent following them grows while the value they deliver stays the same or falls. The sixth guiding principle pushes back against this drift. It asks organizations to use the minimum number of steps needed to achieve an objective, to eliminate anything that does not add value, and to design solutions that are practical for the people who must use them. This lesson explains what simplicity means in service management, how to decide what to remove, how simplicity and control can coexist, and why simple is not the same as easy.

What the principle asks

Keep it simple and practical means: always use the minimum number of steps to accomplish an objective. Outcome-based thinking should be used to produce practical solutions that deliver valuable outcomes. If a process, service, action or metric fails to provide value or produce a useful outcome, eliminate it. Although this principle may seem obvious, it is frequently ignored, resulting in overly complex methods of work that rarely maximize outcomes or minimize cost.

Applying the principle involves:

• Ensuring value: every activity should contribute to value creation.
• Simplicity is the ultimate sophistication: it can be harder to design something simple than something complicated.
• Doing fewer things, but doing them better: focus effort where it produces the most value.
• Respecting the time of the people involved: needless steps and reports waste the time of staff and consumers alike.
• Making things easier to understand, so people are more likely to adopt them.
• Looking for quick wins that show progress and build momentum.

Why complexity grows

Complexity rarely comes from a single bad decision. It accumulates through reasonable responses to individual events. After a failed change, a review step is added. After a security incident, an extra approval is required. After an audit, a new record must be kept. Each addition made sense at the time, but nobody reviews whether the reasons still apply. Meanwhile, exceptions multiply: special handling for one customer, a different form for one department, an extra report for one manager.

The result is a process that tries to handle every possible case. ITIL warns against this directly: trying to design a process or service that accounts for every exception leads to over-complication. A better approach is to design for the common cases and create clear, simple rules for handling exceptions when they arise.

Deciding what to remove

Removing steps requires judgment. Some steps that appear to add no value actually protect against real risks; removing them could cause harm. Others exist only because nobody questioned them. A useful approach is to ask three questions of each step:

• What value does this step add, and for whom?
• What risk does it control, and how likely and serious is that risk?
• Could the same value or control be achieved more simply, for example by automating it or combining it with another step?

Simplicity and control

A common objection to simplification is that it weakens control. In practice, overly complex controls often weaken control, because people find ways around them. An approval that is always granted becomes a rubber stamp, providing a false sense of security. A form with forty fields leads people to enter placeholder data. A policy too long to read is not followed.

Simple, well-designed controls tend to be followed more consistently. The principle therefore supports effective governance (lesson 10): controls should be proportionate to the risk they manage, clear enough to be followed and checked, and reviewed regularly to confirm they still work.

Simple is not the same as easy

Designing something simple can be hard. It takes effort to understand a process well enough to know which steps matter. It takes courage to remove a step that someone senior once insisted on. And it takes discipline to resist adding complexity each time an exception arises. The principle quotes a familiar idea: simplicity is the ultimate sophistication.

Simple also does not mean simplistic. A simple solution handles the real problem well with the fewest moving parts. A simplistic solution ignores important parts of the problem. Removing a security review entirely, for example, would be simplistic if it exposed the organization to serious risk. The aim is to find the simplest design that still achieves the outcome.

Quick wins

The principle encourages looking for quick wins: small, visible improvements that deliver value quickly and build support for further change. Removing a pointless report, shortening a confusing form or publishing a clear knowledge article are typical examples. Quick wins demonstrate that improvement is possible and that suggestions are acted on, which encourages people to suggest more. They should, however, be part of a broader direction, not a substitute for addressing harder problems.

Practical, not just simple

The word "practical" in the principle matters. A solution must work for the people who use it, in the conditions where they use it. A process designed in a meeting room may be elegant on paper but impractical for an agent juggling calls. Involving the people who do the work in designing it (lesson 5) is the best way to ensure solutions are practical. Testing designs in real conditions, in small iterations (lesson 4), confirms they work before they are rolled out widely.

Practicality also applies to documentation. A two-page guide that people actually read is more useful than a hundred-page manual that sits unopened. Knowledge articles should be written for the reader, using plain language and showing the steps in order. Templates, checklists and examples often help more than long explanations.

Links to Lean and other principles

This principle reflects Lean thinking, which classifies activities that do not add value as waste and seeks to eliminate them. Lean identifies forms of waste such as waiting, over-processing, unnecessary motion, defects and unused talent, all of which appear in service management. The principle also works closely with optimize and automate (lesson 8): simplify first, then automate what remains. Automating a complicated process simply produces complicated automation.

Keeping things simple over time

Simplification is not a one-off project. Because complexity accumulates through reasonable reactions to individual events, it returns unless organizations review their processes regularly. Some practical habits help:

• Give every control, report and approval an owner who must confirm, at least yearly, that it still adds value or manages a real risk.
• When adding a new step after an incident, set a review date and remove the step if the risk has been addressed another way.
• Track how often exception paths are used; an exception used constantly is really part of the standard process and should be designed in, while one never used may be removed.
• Ask new staff what confuses them. People new to a process notice complexity that long-serving staff no longer see.

These habits make simplicity part of normal management rather than a periodic clean-up. They also support governance, since a regularly reviewed set of controls is easier to explain to auditors and governing bodies than an accumulated collection whose purpose nobody remembers.

Key point to remember

Every step should earn its place. If nobody can say what value a step adds or what significant risk it controls, it is a candidate for removal, and the effort saved can be spent on work that matters.