Your program is understood, but it is delivered differently by different people, at different sites, on different days, and its quality rides on who happens to be working.
The good version lives in the head of your best person, and when they are out, or when you grow, or when they leave, it walks out with them. This work takes the good version of the delivery and writes it down plainly enough, with clear roles and real training, that anyone you trust can deliver it well, so quality stops depending on who shows up. It is not turning a human service into a script, and it is not writing a binder to sit on a shelf. It does not standardize the relationship between your people and the people they serve; that relationship is the gift, and scripting it would ruin it. What it standardizes is the frame around the relationship: the steps that should be the same for everyone, the decisions that should be made the same way, and the standard of what good delivery looks like. Use this if your program is clearly defined but delivered inconsistently. If it has never really been defined, go to Design the Program first; you cannot standardize a model you have not written.
The good version of your program already exists, in the practice of your strongest deliverers. Before you write any standard, capture what they actually do, because a standard invented in an office and a standard drawn from your best real practice are not the same thing, and only one of them works. Observe or walk through how your best people deliver each stage, and record what they do, the decisions they make, and the judgment calls that separate good delivery from poor. Then mark which parts are the frame that should be the same for everyone and which are the human relationship that should stay each person own.
Open the Delivery Practice Capture →This is where the captured practice becomes a plain, usable delivery standard: what happens at each stage, how the key decisions are made, and what good delivery looks like, written so a trusted person could deliver it well. Write for the person who will use it, not for a regulator or a shelf, and leave the protected relationship parts as principles, not scripts. Then have someone who did not write it try to follow it and mark where it is unclear, wrong, or missing a real decision.
The standard must embed the legal and licensing requirements as fixed points, not summarize them loosely. If you are unsure what a requirement means for a specific delivery step, that is a professional question, and it routes to the licensing body or a nonprofit attorney before you write that step, so the standard you publish is one your people can safely follow. This is a route, not a stop.
A standard that does not say who does what will be done by whoever is willing, which is how delivery drifts back onto one overloaded person. For each part of the standard, name who owns it, who supports it, and who covers it when the owner is out, so no part of the program has only one person who can do it. Then mark every part that still depends on one irreplaceable person and decide how to cross-cover it.
That is a staffing question, not a documentation question. Route it to the staffing work, or, for a volunteer-delivered program, to volunteer engagement, rather than assigning three people worth of delivery to one person and calling it a role map. This is a route, not a stop.
A written standard changes nothing until people can deliver from it. Teach the standard by doing it, with your strongest people modeling the good version and new or inconsistent deliverers practicing against the standard until they can deliver it well. Then check that people can deliver to the standard without the original key person in the room, which is the whole point.
Open the Delivery Training and Fidelity Handoff →A standard that is written and trained but not actually used, and never updated, decays back into whatever people did before. Build the standard into the everyday: into onboarding for new people, into how the work is set up and handed between shifts, so following it is the path of least resistance rather than an extra task. Then set a simple, regular time to revisit it and keep it current as the program learns.
Open the Delivery Adoption and Maintenance Plan →A delivery standard for a licensed or regulated service is a legal document in effect: your people will follow it, so if it is wrong about a safety rule, a mandated report, a clinical protocol, or a licensing requirement, it will produce real harm reliably rather than occasionally. Where your standard touches any regulated or safety-critical part of delivery, have it checked against the actual requirements by the relevant licensing body, a nonprofit attorney, or the credentialed professional for that field before you train people to it. This framework helps you capture and organize good practice; it cannot verify that your standard is clinically or legally correct, and that verification is not optional.
Your best person can take a week off and the program still runs well. A new hire can be brought to good delivery from the written standard and real training, rather than by shadowing one veteran for months. Delivery looks recognizably the same, at its good version, across your sites, shifts, and staff, in the parts that should be the same, while the human relationship stays each person own.
With delivery reliable, your plan most likely sends you next to Build Quality and Improvement Into Delivery, to tell whether the reliable delivery is actually good and to make it better. Where standardizing surfaced a real staffing shortage, that routes to the staffing or volunteer work.