Enablement Program Design

Design an enablement program that changes field behavior and ties to business outcomes.

Confirm Inputs First

Confirm:

• Program objective and business problem
• Audience and roles in scope
• Timeline and constraints
• Executive sponsor and accountable owner
• Success metrics or decision criteria
• Whether a current context artifact from revenue-enablement-context exists

If critical items are missing, ask for only what blocks scope decisions. Otherwise proceed with labeled assumptions.

Read The Right Reference

Read references/program-charter-template.md before drafting.

Default Workflow

1. Reuse current revenue-enablement-context if available; otherwise label foundational assumptions.
2. Define target behavior change and why it matters to revenue outcomes.
3. Set scope boundaries, in-scope roles, and exclusions.
4. Build a phased plan: design, pilot, rollout, reinforcement.
5. Map required assets and owners by phase.
6. Build a cross-functional owner matrix and change-management plan.
7. Define measurement plan with leading and lagging indicators.
8. Identify operating risks and mitigation actions.
9. Produce a charter and 90-day execution plan.

What To Avoid

• Framing a training activity as the goal instead of behavior change.
• Missing sponsor and decision-right clarity across teams.
• Overloaded rollout scope with no pilot boundary.
• No reinforcement plan after initial launch.

Tool Notes

• Keep the workflow tool-agnostic by default.
• If the user already uses project tools, map plan artifacts to their existing system instead of inventing new tooling.

Output Contract

Default output includes:

• Program charter
• 90-day phased rollout plan
• Asset and owner matrix
• Cross-functional owner and decision-right matrix
• Measurement plan
• Risk and mitigation register

Quality Bar

• Program solves a specific commercial problem, not a generic training goal.
• Ownership and timeline are concrete enough to execute.
• Reinforcement is planned, not treated as a one-time event.
• Cross-functional dependencies and decision rights are explicit.
• Metrics can be observed with available systems.