Your program needs an SOP. Someone's been assigned to write it, and the expectation is that once the document is finished, everyone will follow the same process.
But writing down a process doesn't necessarily make it a good one.
If staff are already working around unclear steps, inconsistent decisions, or systems that don't support the work, documenting the current process can simply make those problems official.
The first article in this series made the case for understanding the work before writing the document. This is what that looks like in practice.
Before you start writing, there are six questions worth answering.
1. What Problem Is the SOP Supposed to Solve?
Start with the reason the SOP is needed.
Maybe staff complete the same task differently. Maybe documentation is inconsistent. Maybe a new employee has to ask three people how to complete a routine process.
Those are useful starting points because they describe something happening in daily operations.
"We need better documentation" is harder to act on. Better in what way? What's missing, unclear, or inconsistent?
What to ask: What keeps going wrong, and what should be happening instead?
The answer helps establish whether an SOP is the right solution and what it needs to accomplish.
2. Is the Process Actually Decided?
Sometimes the process hasn't been settled.
Staff disagree about when a case should be escalated, who can approve an exception, or what happens when required information is missing. Different supervisors have different expectations.
Writing an SOP before resolving those questions creates a problem. Someone has to make the decisions, and the person drafting the document may not have the authority to make them. (More on telling a policy gap from an SOP gap.)
What to ask: Are staff making decisions differently because the program hasn't established a clear expectation?
If so, settle those questions with the appropriate decision-makers before documenting the steps.
3. How Does the Work Actually Happen?
The existing procedure says one thing while staff do something else.
That difference matters.
Staff sometimes develop workarounds because a system changed, a form no longer matches the process, or a required step doesn't fit the way services are delivered.
Those workarounds aren't automatically good practices. But they tell you something about how the process functions in real conditions.
Talk with the people doing the work. Ask them to walk through a recent example, including what happens when something doesn't go as planned.
What to ask: If someone followed the current written procedure exactly, could they complete the task successfully using the tools and resources available?
If the answer is no, the process needs attention before it becomes a new SOP.
4. Who Needs to Be Involved?
An SOP describes a task, but that task can affect several roles.
Consider a process for reviewing and submitting monthly program data. Frontline staff enter information, supervisors review it, and another team member prepares the report.
If only the person submitting the report helps write the SOP, important steps can be missed.
The people who perform the work can identify practical barriers. Supervisors can clarify expectations. Leadership may need to approve decisions, particularly when the process involves compliance or funding requirements.
What to ask: Who performs, reviews, approves, or depends on this process?
You don't need everyone in every meeting. You do need the people whose knowledge or decisions are necessary to make the procedure accurate and usable.
5. What Requirements Must the Process Meet?
Some procedures are shaped by grant agreements, organizational policies, contracts, reporting requirements, or applicable regulations.
Those requirements need to be identified before the steps are written.
For example, a program has developed an informal way to document services that works well for staff but doesn't capture everything required by its funding agreement.
If the SOP simply describes the informal process, the documentation gap remains.
The reverse can also happen. A program requires extra steps because "that's how we've always done it," even though no one can identify the requirement behind them.
What to ask: Which steps are required, where are those requirements documented, and which steps reflect internal choices?
This helps distinguish what must happen from what the organization can redesign.
6. Who Will Own the SOP After It's Written?
An SOP needs more than an approval date.
Someone must be responsible for maintaining it when systems, staffing, funding requirements, or operational practices change.
Staff also need to know where to find it, when to use it, and how to raise questions when the written steps don't match a situation they encounter.
Without clear ownership, a useful SOP can become outdated while staff continue relying on informal instructions.
What to ask: Who will maintain this document, communicate changes, and check whether the procedure still reflects how the work should happen?
Answering that question before publication helps make the SOP part of daily operations rather than another file stored in a shared folder.
An SOP Is the Result of the Work, Not the Starting Point
A useful SOP comes from understanding the task, resolving unclear decisions, checking requirements, and working with the people responsible for implementation.
The writing matters. But much of the value comes from the work that happens before anyone starts drafting.
This is part of the Assess and Align phases of Program to Practice. Assess identifies where the process is breaking down. Align brings the people involved together to agree on a workable solution before new procedures are put into place.
Choose one process that needs attention and walk through these six questions.
You might find that an SOP is exactly what's needed. You might also discover that a policy decision, workflow change, or system adjustment has to come first.
Either way, you'll be in a better position to build documentation staff can actually use.
Not Sure Where to Start?
The Program Readiness Assessment helps you examine your program's documentation, workflows, implementation, and operational readiness to identify areas that need attention.