The last thing we give you is an honest account of what you can do without us.
Most organizations in this sector have hired outside help before, and most have been left with a document rather than a working system. Here is exactly how we avoid that, and how you can hold us to it.
| Stage | What happens | What you get |
|---|---|---|
| 1 · Diagnose | Structured interviews across every level, a systems and vendor inventory, document and record review, and a written baseline. We look at what is actually happening, not at what the policy says should happen. | A prioritized baseline naming gaps, risks, and opportunities; a recommendation on sequence; and an honest statement of what is not a systems problem at all. |
| 2 · Design | Target-state design, done with the people who will operate it. Nothing is designed away from the staff who will run it — designs that ignore the operator are why previous attempts failed. | Target operating model, workflows, architecture, and a sequenced implementation map with owners and dates. |
| 3 · Build | The actual construction: policies, workflows, templates, dashboards, configurations, and software increments, delivered in monthly increments and submitted for your written acceptance. | Working apparatus, delivered incrementally, with an acceptance record for each increment. |
| 4 · Transfer | Documentation written for an operator rather than an auditor, hands-on training with the people who will do the work, administrator handoff, and a named internal owner assigned to every function. | Operating documentation, training delivered and evidenced, administrator credentials and runbooks, ownership assignments. |
| 5 · Verify | An honest assessment of whether the transfer worked, including where it did not. | The sustainability scorecard, an open-risk register, a next-year roadmap, and written post-engagement terms. |
Every workstream produces reusable artifacts. A workstream that produces only advice has not delivered. The test is whether you can operate the thing after we stop.
Monthly delivery, monthly acceptance. Work arrives in monthly increments with a one-page record of what was delivered and where it is filed. You accept, or you state a deficiency and it is remedied.
Payment follows delivery, not the calendar. The fee is earned by delivering the accepted package, not by the passage of time.
Every function gets a named internal owner. Not a department — a person. A function without a named owner has not been transferred, and the scorecard says so.
No unowned dependency at closeout. If something remains that only we can do, it is written down, named as a dependency, and either resolved or explicitly accepted by you with a plan.
Documentation is written for the operator. Plain language, screenshots, the actual click path, and the exception cases.
Nothing enters production without acceptance. Preview, sandbox, and demonstration access are not licenses and may not be used for real regulated work.
Human review is designed in. Where software drafts a document or scores a decision, a qualified member of your staff must review and accept it. The system is built so this cannot be skipped.
Your identity only. Everything your families, constituents, staff, or funders see carries your identity. Our branding does not appear inside your systems.
We say what we did not do. The scorecard includes failures and shortfalls. A capacity report that reads as pure success is not a capacity report.
The last deliverable of every engagement, addressed to your board. It is short and blunt.
| Section | What it says |
|---|---|
| Can run independently | Each function you can now operate without us, the named internal owner, the date competence was demonstrated, and how it was demonstrated. |
| Can run with support | Functions you can operate with occasional help, what kind, and how often it is expected to be needed. |
| Cannot yet run | Functions that did not transfer, stated plainly, with the reason — insufficient time, insufficient staffing, a decision you have not made, or a shortfall on our part. |
| Residual dependencies | Anything still requiring us or another outside party, with the cost and the exit path for each. |
| Open risks | Risks identified during the engagement that remain unresolved, with owners. |
| Next-year roadmap | What you should do next, in priority order, whether or not we are involved — including where another provider is the better choice. |
| Measured change | Before and after on whatever was measurable: finding counts, cycle times, administrative hours, systems consolidated, indicators newly reportable. |
We are a charitable organization, and every piece of paid work has to advance that purpose. Before an engagement is signed we ask, in writing: does this fall within an approved program; does the activity itself advance an educational or capacity outcome; is the organization within the class we serve; is the fee consistent with our published access policy; and — the question that decides it — if we could not keep the fee, would we still want to do this work?
If the answer to that last question is no, we do not take the engagement.
Consultants leave you a report. Vendors leave you a dependency. We leave you a working system, the documentation to run it, and an honest scorecard telling you what you can and cannot do without us. It is a harder business model, and it is the only one that actually closes the gap.