SOP Development
Standard operating procedures written from a validated map of the real process and a defined account of what each role needs to be able to do. Authoritative enough to settle a question, short enough that someone will open them.
Most consultancies open with SOPs. That is the wrong end of the work.
Writing procedures first produces a record of how leadership believes the work happens, or how it was designed to happen at some earlier point. It is a description of intent. The people performing the work read it, recognize that it does not describe their job, and carry on as before. The organization now has documentation and believes the problem is solved.
We work the other way around. The process is mapped from the people who perform it, the gaps are identified, the capability each role actually needs is established, and only then are the procedures written. SOPs are the fourth stage of five, not the first, and the sequence is the single largest determinant of whether anyone uses what you paid for.
What Makes a Procedure Usable
A procedure has one job: to let a competent person do the task correctly without interrupting a colleague. Everything in the way of that is decoration.
- Inputs, steps, owner, output and escalation path, stated at the level of the person performing the task
- Short enough to settle a question at a glance, which for most procedures means under a page
- Consistent structure and voice across every document, so that familiarity with one transfers to all of them
- Written in the vocabulary your people already use, not translated into consulting language
- A version and maintenance convention, so the second revision does not quietly contradict the first
- Delivered in editable formats you own, whether Word, Markdown, SharePoint, Confluence or your existing knowledge base
Where SOPs Sit in the Sequence
Each stage exists because the next one needs its output. Procedures written without the first three stages have nothing accurate to describe.
Map the current state
Document what actually happens, from the people who do it, using the mapping methodology.
Identify the gaps
Bottlenecks, duplicated effort and steps with no owner, ranked by cost rather than by who raised them.
Define the learning needs
Establish what each role must be able to do, and separate what people must know from what they only need to be able to look up. This is the specification the procedures are written against, and skipping it is why so much corporate documentation manages to be simultaneously too long and insufficient.
Write the procedures
SOPs and work instructions built to that specification, at the length the task genuinely requires.
Build the training from the procedures
Derived from the SOPs rather than written alongside them, so the two cannot drift apart. A change to a procedure has an obvious consequence for the training.
Signs Your Procedures Are Not Working
- New hires learn by sitting next to someone rather than by reading anything
- The documentation exists but people ask a colleague instead, and are right to
- Two documents describe the same task differently and nobody knows which is current
- Procedures were written for an audit and have not been opened since it concluded
- The person who wrote them has left and nobody has updated them since
- A procedure runs to eighteen pages and is technically complete and practically useless
Common Questions
What is an SOP?
A written instruction covering one task in enough detail that a competent person can perform it consistently without asking a colleague. It states the inputs, the steps, the owner, the expected output and what to do when something goes wrong.
How long should an SOP be?
Short enough that someone under time pressure will open it. Most procedures should settle a question in under a page. Length is not thoroughness, and a procedure nobody opens documents nothing.
Should SOPs come before or after process mapping?
After. A procedure written before the process is mapped records how the work was believed to happen. Map first, identify the gaps, define what each role needs to be able to do, then write against that specification.
Can you update procedures we already have?
Frequently, yes. Where existing documentation is broadly sound we assess and revise it rather than starting again, which is both cheaper and easier for your people to accept. Where it describes a process that no longer exists, rewriting is the honest answer.
What formats do we receive?
Editable ones you own outright. Nothing is held in a proprietary system that requires a subscription to read.
Which procedure would you fix first?
Tell us what it is and we will tell you honestly whether we can help, and roughly what addressing it would take.