Crawl, Walk, Run Launch Plan

Use this skill when a practice is about to launch, restart, or add a Medicare between-visit program, has inherited one it didn't design, or has a pilot that has run without a decision, and wants a plan that starts with one program and one cohort and grows…

This skill is Labor as Code™ for the launch method in Getting Paid to Do the Right Thing. Labor as Code is a skill that encapsulates a person's knowledge, judgment, taste, and skill in durable, inspectable, versioned form. The know-how is starting a between-visit program small enough that being wrong is cheap, watching every step before automating any of it, and ending the first stage on a date with a decision instead of letting it drift.

The method lives in "Test One Program for Ninety Days Before You Grow It": the five parts of a crawl, the stage gates (Table 12.1), the ninety-day plan (Table 12.2), Riverbend's success and kill criteria (Table 12.3) and its crawl week by week (Table 12.4), the pilot trap, the walk, the run's four measurements (Table 12.5), and Maria Okafor's first thirty days with an inherited program. "Medicare Has Paid for Care Outside the Visit for Over a Decade" gives the Opportunity Map the program choice starts from, and "A Program Survives Only if Each Patient-Month Covers Its Cost" gives the Practice Math it's checked against. Read them for the argument and the cases, including Summit Endocrine's six hundred enrollments in eight weeks. This skill builds the same plan for the user's practice and never reuses Riverbend's counts or criteria as the user's.

The skill plans; the partners decide. It drafts the criteria, the plan, and the day-90 recommendation. The partners sign the criteria before launch and make the stop, hold, or walk call. The skill never writes a criterion after the results are in; criteria written afterward describe what happened and don't judge it.

The skill works from counts. Opportunity Map counts, Capture Ladder counts, minutes, and a de-identified crawl log. No patient records come into the session.

Before running

1. Find out where the practice is. Before launch (start at Step 1), mid-crawl (start at Step 5 with the log), at day 90 (Step 6), deciding whether to walk or run (Step 7), or newly responsible for a program someone else started (Step 8).
2. Ask for the size of the organization. Solo or small practice, small group with several sites, or large group or health system. The walk changes with size.
3. Ask for the pressure. A vendor offering to enroll the whole list, a partner who wants revenue this quarter, a pilot nobody wants to disturb. Name it; the plan has to withstand it.

Step 1: Pick one program from the practice's own counts

1. Start from the patients' problems, not the fee schedule. Have the user count Medicare patients by the Opportunity Map's ten groups (continuity, transitions, monitoring, behavioral health, navigation, social barriers, caregivers, prevention and planning, serious illness, chronic pain), each with the definition they used. The groups overlap; the shape matters, not the total.
2. For a solo or small practice, expect two or three groups to matter. For a small group, build the map per site. For a large organization, build it per clinic and don't average.
3. Match the two largest relevant groups to candidate programs, and check each candidate against the user's Practice Math (the practice-math-program-model skill runs it). Pick the program whose base case works at realistic participation and realistic labor cost. Weigh what the team already knows how to do and how much new machinery the program needs (monthly programs need a registry and a queue; event programs need a trigger; team-based programs need defined roles).
4. One program. Not two. Two at once and nobody can tell which one is teaching what.

If no Practice Math exists, say the program choice is provisional until it does.

Step 2: Define the crawl

A crawl has five parts, and the skill checks each one:

• One program. From Step 1.
• One cohort of 50–100 patients. Small enough that one coordinator knows every patient by name by the third week; big enough that the ladder's gaps show up as patterns. The book prefers a cohort defined by one physician's panel, because it gives the champion a reason to care and keeps the escalation path short. Keep the crawl to one payer's rules (the book's example is traditional Medicare only) if the panel mixes payers.
• One clinical champion. A named physician who signs care plans, takes escalations, and attends the weekly review, with the minutes blocked on a real calendar.
• Explicit success and kill criteria. Step 3.
• Manual observation of every step. Someone writes down what happens at each step of the Attention Loop (Find, Enroll, Attend, Record, Collect, Verify): how long it took, who did it, where the information came from, where it went next.

Size the crawl's staff time from minutes if the user has them: cohort × (care + admin minutes per enrolled patient-month). Budget more than the arithmetic says, because watching every step takes time. Say plainly that the first crawl month will likely cost more per patient than the old way; that's the price of learning, and it's why the cohort is small.

If anyone proposes enrolling the whole eligible list, or a vendor offers to enroll hundreds of patients in weeks, show the arithmetic the book uses against it: patients × the program's monthly required minutes is the care work owed every month from the first bill, before admin minutes, and every patient needs to understand a monthly charge. Enroll at the speed the team learns, not the speed someone else can dial.

Step 3: Write the success and kill criteria before launch

Draft them from the user's baseline ladder, admin minutes, cohort size, and champion. Rules:

1. Every criterion is a number the practice can measure from counts it already collects, with the date it will be measured.
2. Include at least one criterion about whether patients were helped (Riverbend used contact within two business days after emergency visits and discharges), and at least one about staff workload (Riverbend used whether its nurse left on time four days of five).
3. Remove criteria that use revenue alone or that need new software to measure.
4. A kill criterion must trip on a trend visible by day 75. Replace any that trips only on catastrophe ("a compliance finding").
5. For each criterion, say how it could be gamed without improving anything, and tighten it.

Typical kinds, all with the user's own targets: served rate in the second crawl month; admin minutes per enrolled patient-month by day 90; claims sent without documented consent and a signed care plan (the book sets this at zero); collection rate; the helped proxy; the workload criterion. Typical kills: admin minutes on a day-75 spot check above the old program's level; a served rate below a floor; patient complaints about charges traced to the enrollment conversation.

Mark the list "draft: partners to sign on [date]." The partners sign it in days 11–20.

Step 4: Lay out the ninety days

Use the book's seven blocks and the deliverable each ends with:

Put real dates on each block. Add the book's specifics:

• Days 21–30: walk the Attention Loop for one imaginary patient on a whiteboard with the people who'll do the work. For each step, write who does it, how long it takes, what they need to know, and where they get it. Mark every step where the answer is one person's memory; those are the steps to watch hardest.
• Days 31–45: launch at the start of a calendar month if the program bills monthly, so crawl months line up with billing months.
• Days 46–60: build the cohort's ladder every Monday, name the single widest gap, try one fix, check it the next Monday. One gap at a time.
• Days 61–75: take the three admin tasks the log shows were repeated most, move them to software, a report, or a checklist, and measure minutes before and after. Check first whether the existing EHR contract already includes a module nobody switched on. Don't automate a step nobody has watched a person do.

Thirty of the ninety days happen before the first patient enrolls. If the user wants to compress them, say what the book says: the practices that compress those thirty days spend the next sixty guessing.

Step 5: Run the weekly loop during the crawl

When the user brings a week's log or ladder:

1. Compute the cohort's ladder and the drop at each rung.
2. Name the widest gap and one fix, with an owner.
3. Record one thing the practice stopped doing, if the week produced one. Habits left over from an old attempt (calling in list order, counting minutes on sticky notes, a spreadsheet) usually never stop unless someone decides they stop.
4. Check last week's fix against this week's number.

Use the capture-ladder-diagnosis skill for any gap whose cause isn't obvious.

Step 6: End the crawl on a date with one of three words

On day 90 (or the date the partners set), grade the crawl against the criteria signed before launch, not a new set. For each criterion: target, result, met or missed, and where a miss points. Note which results are ahead of their remittances; a crawl decision usually runs a few weeks ahead of its paid claims, so say which month's collection rate the decision rests on.

Recommend one of the book's three answers:

• Stop. The program doesn't belong in this practice now. Tell enrolled patients plainly, close out the month's billing, and write down what was learned so the next attempt starts from it.
• Hold. One named problem stands between the practice and a walk. Fix it for thirty more days, then decide again. One hold only. A second hold is a stop nobody has admitted yet.
• Walk. The criteria were met, or the misses point somewhere specific. Move on a written schedule, with the conditions written into the decision and a date by which the partners vote again if they aren't met.

Give the reasoning, tied to specific criteria. Where the results genuinely support two answers (for example, most criteria met but a workload criterion missed for a cause that may or may not be the crawl itself), present both side by side with what would make each right, and name the fact that would settle it. If a kill criterion tripped, say so first; the recommendation has to answer it.

Watch for the pilot trap. A crawl still at its starting size long past its decision date, working well enough that nobody wants to disturb it and not well enough that anyone wants to bet on it, is a pilot trap. If the user describes one, the recommendation is to set a decision date now and grade against the original criteria, or write them now and say plainly that they were written late.

Step 7: Set the gates for walk and run

Walk requires that the crawl met its success criteria for two consecutive months and the partners said "walk" on a specific date. Plan the walk's three jobs:

1. A written workflow, one page per Attention Loop step. The test: could a new medical assistant hired next spring run the step from the page? Delete any step the crawl log doesn't show; generic steps describe a vendor's workflow.
2. Automate the next repetition the log exposed, ranked by total minutes.
3. Bring in the rest of the eligible patients in batches small enough to watch, each with its own first-month ladder so the practice can see whether new patients behave like the crawl cohort.

Only then a second program, as its own crawl with its own champion and criteria, after the first program meets its criteria for two consecutive months at the larger size.

By size: a solo or small practice walks with the same people who ran the crawl, and writing the workflow matters most because the program still lives with one nurse. A small group walks one site first, copies the written workflow to a second site, and compares the two ladders month by month. A large group or health system crawls at one site and walks at two or three before anyone draws an organization chart.

Run requires that the practice can produce four monthly measures for every program without a special project: quality (whether patients were helped), exceptions (escalations opened, closed, and past deadline; patients who fell off), margin (contribution margin per enrolled patient-month from actual minutes and collections), and patient experience (complaints, questions about charges, who stopped and why). List which of the four the user can produce today and which still take hand work. Adding patients before these numbers come easily is walking faster, which is more dangerous than walking.

Step 8: If the program was inherited, observe for thirty days first

For a new administrator walking into a running program, treat it as a crawl someone else designed and observe before changing anything. The book's five moves, in order:

1. Build the Capture Ladder from counts.
2. Find out who owns each step, including steps a vendor owns and steps nobody owns.
3. Read ten patient records end to end (the user does this, not the skill).
4. Pull the vendor contract's payment terms and name the behavior each term rewards. Flag any term that rewards billing activity whether or not the patient is helped.
5. Put the program on hold for new enrollment only. Existing patients keep their services until the problems have owners.

Build a week-by-week thirty-day plan: what to look at, which counts to pull, what question each count answers. Strike any step in the first thirty days that switches vendors, restructures staff, or changes clinical protocols; the plan's job is to produce facts. On day 30, the recommendation is stop, hold, or walk, as in Step 6.

Checks before calling the work done

• One program and one cohort of 50–100 patients, with a named champion and blocked minutes.
• Criteria were written before launch, each a number with a date, with at least one helped criterion and one workload criterion, and every kill criterion visible by day 75.
• Every block of the ninety days has a date and a deliverable.
• The day-90 answer is stop, hold, or walk, graded against the original criteria, and a second hold is called a stop.
• Walk and run each have their entry requirement stated, and the plan doesn't grow before it's met.

What this skill does not do

It doesn't pick a program on payment rate alone, and it doesn't borrow Riverbend's cohort, criteria, or targets as the user's. It doesn't write criteria after the fact to match the results. It doesn't make the stop, hold, or walk decision; the partners do. It doesn't recommend a vendor or switching one in the first thirty days of an inherited program. And it doesn't treat enrollment speed as progress. Served rate, documentation quality, patient understanding, and whether anyone was helped lag by weeks or months, and a practice that enrolls faster than it can observe is borrowing against numbers it can't see yet.