Your program grew rather than being designed. It started as an instinct and a person who cared, it worked, and it expanded, and now no one can say cleanly what it actually is, who exactly it is for, or what specific change it is meant to make.
You cannot make reliable, or prove the impact of, or honestly fund a program that has never been defined. This work defines it: the people you serve, the change you intend for them, and the model of service that produces that change, written down as the reference everything else is built on. It is design work, done on purpose and in plain words. It is not a strategic planning retreat, not a mission-writing exercise, and not a grant narrative. It does not decide whether the program should exist; that is a mission decision, and if that is your real question this work will send you there. It does not prove the program works; that is the impact work, and this names the change you intend so that work has something to measure. Use this if the diagnostic found your program was never really designed, or if you cannot say plainly and in writing who it serves and what it is meant to change. If your program is already clearly defined and delivered inconsistently, go to Standardize and Document Delivery instead.
A program is only as clear as its answer to two questions: who is this for, exactly, and what is it meant to change for them. Vague answers here produce a program that tries to be everything and reliably delivers nothing. Define the specific people this program is for, tightly enough that you could tell whether a given person is or is not who it is meant for, and name who it is not for. Then state the specific change it is meant to make in their lives, in their terms, not the outputs you count for a funder.
And the disagreement is really about what the organization is for at all, that is a mission question, not a design question. Route to mission and strategic direction, settle it, and return. Designing a delivery model on top of an unsettled mission builds on sand. This is a route, not a stop.
Between a person arriving and a person changed, there is a sequence of things your program does, and if that sequence is not mapped, it cannot be delivered the same way twice. Lay out the program as a path: how a person enters, what happens at each stage, and how they exit, and for each stage, what it is meant to accomplish toward the change. Mark which parts are the frame that should be the same for everyone and which are the human relationship that should not be scripted. Then walk the map against the intended change and ask honestly whether this sequence could actually produce it, or whether there is a gap where you are hoping rather than delivering.
Open the Service Model Map →A design can be clear and still be wrong: off mission, impossible to staff, or built on a link to the change that will not hold. Check the design on three honest questions: does it fit the mission, can you actually staff and fund it, and does the model plausibly produce the change. Where any answer is no, decide whether to redesign or to route the question out. And where the program is licensed or regulated, check the design against those requirements and adjust it to meet them; these are not negotiable.
If the design does not fit the mission, route the fit question to mission and strategic direction before you build further. If you cannot tell whether the model produces the change and are about to spend real money betting that it does, that is the impact measurement work, and you may want to design the measurement in now. And if the design requires staff, skills, or money you do not have, route the capacity question to the staffing and funding work rather than designing a program you cannot run. This is a route, not a stop.
A design that lives in a workshop memory is not a design. Bring the who, the intended change, and the model into one short, plain document that anyone in the organization could read and understand what this program is and is meant to do. Then agree, out loud and with the delivery team, that this is now the definition the program is held to, and set a date to revisit it, because a program is refined as you learn, not frozen.
Open the Program Definition Document →If your program serves a vulnerable population, children, people in crisis, people receiving clinical or personal care, then the design is not only a service question but a safeguarding and duty-of-care question, and the requirements are set by law, licensing, and professional standards, not by you. Design to meet them as fixed points, and where you are unsure what they require, bring in the relevant licensing body, a nonprofit attorney, or the credentialed professional for that field. This framework can help you organize the design; it cannot certify that your design is safe or lawful for the people in your care, and that certification is not optional.
You can hand a new staff member the written definition and they can tell you who the program is for, what it is meant to change, and roughly how it works, without asking your best person. Your team recognizes the written program as the one they actually deliver. And you can name the change you intend in the words of the people you serve, not only in the counts a funder asks for.
With the program defined, your plan most likely sends you next to Standardize and Document Delivery, to make the model happen reliably. Where the design surfaced whether the program should exist, that routes to mission and strategic direction; where it surfaced the need to prove the change, that routes to the impact measurement work.