The Matthews had ten documents describing how community theater productions s...

The Matthews had ten documents describing how community theater productions should run.

Director guidelines. Support team roles. Escalation paths with SLAs. A RACI matrix for key milestones. Volunteer code of conduct. A six-phase production timeline — Planning through Early Rehearsals through Partial Load-In through Tech and Dress through Performance through Strike.

Every phase named. Every role described. Every escalation scenario anticipated.

And none of it produced a calendar. None of it connected a volunteer to a specific shift on a specific date. None of it generated a backstage call sheet for opening night. Marketing deadlines were listed relative to a phase start — "Week 1" — with no trigger point to convert that into an actual date on the calendar.

The documents were complete. The system didn't exist.

This is the most common operations problem I see in arts organizations and small nonprofits. Not a lack of documentation — often the opposite. Years of accumulated policies and procedures and guidelines that describe what should happen with real care and specificity. And then the timeline slips. Volunteers don't show up because no one confirmed the shift. The post-show review never happens because there's no template and no one owns it. The set build runs into the rehearsal schedule because nobody tracked who had the stage on which days.

The documentation describes the system. It doesn't run it.

A policy document tells you what should happen. A system makes it happen. Those are not the same thing, and most organizations — especially small ones without dedicated operations staff — confuse them constantly. Writing the document feels like doing the work. It isn't.

When I audited the Matthews community theater workflow in March, the documentation held up. The six-phase production timeline was well-structured. The three-tier escalation paths made sense. The RACI matrix covered the right milestones. Whoever wrote these documents did the thinking.

What was missing was mechanism.

No production-level calendar. The phases existed — but nothing generated actual dates for a specific show from the moment it got approved. Each production started from scratch, manually reconstructing a timeline that should be automatic.

Nine volunteer lanes defined — FOH, backstage, set build, all of it — but nothing connecting a named person to a specific shift on a specific night. The volunteer coordination infrastructure was entirely implicit. The policy said "volunteer management" was a phase; nothing asked who was running the box office on Saturday.

Backstage roles during performances were undefined. No call sheet template. No documented stage manager responsibilities. No communication protocol for who makes what decision when something goes wrong during a show.

Post-show review was listed in the documentation — mentioned as a step — but there was no template, no timeline, no ownership. "Do a post-show review" is not a system. It's an intention.

Marketing deadlines were relative. "Week 1 of rehearsals" is a meaningful reference point in the document. It means nothing without a rehearsal start date and a mechanism to calculate the actual calendar date.

Seven gaps. All of them the same shape: description without execution mechanism.

The fix wasn't more documentation. It was connecting what the documents described to something that actually runs.

What we built was a phase-based production template that lives in the Projects database — not in a separate reference doc, but in the actual operational system where tasks and assignments live. When a production gets approved, the template generates the structure. Each of the six phases — plus a Phase 0 for pre-approval and licensing — is a toggle with its own filtered task view, its own volunteer shift view, and its own phase-specific checklist.

The critical piece: buttons at the bottom of each phase that launch the next one with pre-loaded tasks, pre-calculated dates, and pre-assigned roles. The document described what Phase 3 should contain. The system generates Phase 3, with specific dates, when Phase 2 closes.

Volunteer scheduling got its own database — Volunteer Shifts — that connects to People, connects to the production, and connects to specific dates. Not a lane called "volunteer management." An actual record that says who is working the box office on Friday the 14th.

Marketing deadlines are now calculated, not relative. "Week 1" becomes a real date automatically from the production calendar. The trigger exists.

The principle here applies to every arts organization trying to fix its nonprofit operations, and it's simpler than most workflow consultants make it sound.

Find the gap between description and execution. Every policy document in your organization is either descriptive or operational. Descriptive docs tell you what should happen. Operational systems make it happen. Most organizations have plenty of the first and not enough of the second.

Ask this about every policy or procedure in your org: does this document describe what should happen, or does it actually make something happen? If someone has to read the document and then go build the thing from scratch every time, it's descriptive. That's not useless — it's just not a system.

The upgrade path is usually straightforward once you name the gap:

What decision or action does this document intend to produce? Where does that decision or action need to live to actually happen? What generates it, and when?

For the Matthews production workflow: the decision was "which volunteer is on this shift." That needed to live in a database connected to dates and people, not in a lane called "volunteer management" inside a policy doc.

That's the gap. Fill the gap.

Most small nonprofits can't afford a dedicated operations director. The Matthews has three staff. Every production adds load to the same people who are already running programs, managing rentals, and handling development. The answer to that constraint isn't more headcount — it's making sure the work that can be systematized actually is.

Every hour the ED spends reconstructing a production timeline from scratch is an hour the documented workflow didn't save. Every volunteer no-show that happens because the coordination process lived in someone's head is a gap between what the policy described and what the system did.

The document is not the system. The document is the blueprint.

Build the system.

If you're running an arts organization or a small nonprofit and this pattern sounds familiar — good documentation, operational problems anyway — the first step isn't another policy. It's an audit of the gap between what your documentation describes and what your actual systems execute. That's where the problems live, and that's where the work is.