Implementation Is the Work

The program is not the implementation

A strong curriculum, strategy or program can still fail in a real organization. Not because the idea was weak, but because the operating conditions were never designed to carry it.

That distinction matters. Organizations often spend most of their attention on content: the curriculum, the model, the training deck, the sequence of activities, the outcomes they hope to produce. Then implementation is treated like the administrative part that happens after the real work is finished. In practice, implementation is where the real work becomes visible.

A useful program has to survive calendars, staffing patterns, permissions, competing priorities, facilitator confidence, technology constraints, participant access, leadership turnover and the ordinary friction of institutional life. If those conditions are not part of the design, the program is not ready simply because the materials are complete.

Readiness is a set of decisions

Readiness should not be reduced to enthusiasm. A team can be excited and still be unready. It can have funding and still be unready. It can have a polished curriculum and still be unready.

The more useful question is whether the organization has made the decisions required for delivery. Who owns the work? Who has authority to remove barriers? Who facilitates? What happens when a facilitator is absent? What access, space, technology or materials are required? How will participants enter and move through the experience? What data can responsibly be collected? Who reviews what is learned and makes the next decision?

Those are not operational details at the edge of the work. They are the infrastructure of the work.

Five conditions I look for before launch

When one of these conditions is missing, the answer is not always to stop. Sometimes the right move is to reduce the scope, redesign the pilot or change the implementation sequence. Readiness is not a pass/fail label; it is a design decision about what the environment can responsibly carry now.

• Ownership: A named person or team is accountable for the implementation—not merely supportive of it.
• Access + permission: The people, spaces, technology, schedules and approvals required for delivery are actually available.
• Facilitator capacity: The people delivering the work understand both the content and the judgment required to use it well.
• Operational fit: The cadence, session length, workflows and expectations fit the environment rather than assuming ideal conditions.
• Evidence + learning: There is a proportionate way to capture participation, experience, implementation friction and what should change next.

Pilots should answer a question

A pilot should not be a smaller version of a launch simply because the organization is not ready to commit. It should be designed to answer something specific.

Can facilitators use the material as intended? Does the cadence work in this setting? Are participants able to engage with the format? What support do staff need? Where does the workflow break? Which parts of the experience are essential, and which can be adapted without weakening the model?

A good pilot creates permission to learn before scale creates pressure to defend. That is why the evidence plan matters from the beginning. The goal is not to manufacture proof that the program worked. The goal is to know enough to make a better next decision.

The implementation question changes the design

Once implementation is treated as part of design, the work itself changes. Materials become easier to navigate. Training becomes more applied. Roles are clearer. Evidence becomes more proportionate. Partners know what they are agreeing to. And the organization can distinguish a content problem from an implementation problem when something goes wrong.

That is the standard I want AYA work to meet: not simply good ideas, but structures that can function under real conditions.