FAQ · PRACTICE
This is the question that separates a real operations consultant from a business coach with a whiteboard, and it’s the right one to ask. The answer: I do the work, not just describe it.
Here’s what that means in practice.
The “advisor only” trap
A lot of consulting stops at advice: an assessment, a deck of recommendations, a bill. You get told what to change and then you’re on your own to change it — while still running the practice full time. Unsurprisingly, the change doesn’t happen. The deck sits in a drawer.
That’s not how I work. Advice without implementation is just a suggestion you paid for.
Done-with-you and done-for-you
When I engage with a practice, I’m in the work, not just pointing at it:
- I map the process — the actual flow of work, not the imagined one.
- I write the SOPs — the followable procedures, in your tools, not a Word doc nobody opens.
- I wire the systems — the scheduling, follow-up, and reporting, so the software does the remembering.
- I train your team — so the people actually run it, not just nod through a demo.
You’re involved the whole way — it’s your practice, and the goal is that the system reflects how you actually operate. But you’re not the one doing the grunt work. That’s what you’re paying me for.
The handoff: it lives in your team, not in me
The test of whether implementation was done right is simple: after I leave, does it keep running? If a system only works while the consultant is in the room, it wasn’t implemented — it was performed. The deliverable here is a practice that runs on documented systems your own people can operate.
That’s the difference between practice consulting and advice: one leaves you with a running machine; the other leaves you with a to-do list.
What “done” actually looks like
It helps to know the finish line before you start, so here’s what a completed engagement hands you:
The process is mapped, and it reflects how work actually flows — not the version in the old manual. The SOPs are written into your own tools, followable by a new hire without a shadow. The systems talk to each other, so scheduling, follow-up, and reporting don’t depend on anyone remembering. And your team has been trained to run it — not walked through a demo once, but able to operate it next week.
Then I leave, and here’s the test: the practice keeps running at the same quality without me in the room. If it does, it was implementation. If it only worked while I was there, it was theater — and I don’t do theater.
Why “done-with-you” beats “done-for-you”
Here’s a subtle but important point: I could build it all and hand you a finished machine with a bow on it — but that would leave your team dependent on me the moment anything changes. The training and involvement are what make the system yours. You don’t want to rent the machine; you want to own it. So the goal isn’t just that the work gets done — it’s that your people know how to run it and keep improving it long after I’m gone.
Want to see which systems in your practice need the most attention first?