This chapter details how to define programs with architectural precision using seven key components. It covers scoping boundaries, classification schemes, and hierarchies to distinguish ongoing programs from projects or organizational units.

By the end of this chapter, you'll be able to:
Before moving to the next chapter, ensure you can:
Apply these concepts to your own context:
1. **Definition Discipline**: How well are programs defined in your organization? Do programs have clear purpose statements, scoped boundaries, and measurable outcomes - or are they vaguely described?
2. **Naming Clarity**: When people in your organization say "program," do they mean ongoing value-creation programs, or do they also use "program" for projects, initiatives, organizational units, and services? What confusion does this create?
3. **Scope Challenges**: What drives program scope in your organization - outcome logic (right-sized), organizational boundaries (silo-driven), or historical accident ("we've always grouped these together")? What's the impact?
4. **Classification Utility**: Would classifying your programs (by intervention type, delivery model, complexity) provide useful insights? What would you learn? How might it change resource allocation or strategy?
5. **Hierarchy Clarity**: Does your organization have a shared understanding of program hierarchies, or do people disagree about which programs are "under" which others? How does this affect coordination and governance?