The purpose of this document is to define a high-level strategic proposal (along with any potential alternatives) to share with leadership for their approval and/or feedback and build better alignment among project teams. This document is also designed to provide a clear “north star” for subsequent tactical planning and execution. This document will help accountable leaders bring clarity to the problem they’re trying to solve, the principles by which they will solve the problem, the success criteria, and a sense of the lift and critical dependencies associated with the work. Using this template helps build and maintain a sense of alignment among leaders, individual contributors, and leadership by making clear where you’re going, why, and how.
What is the specific problem that needs to be solved? How does it impact your organization's effectiveness or values, customer outcomes, or revenue outcomes? What risk does it present? What happens if you fail to address it? This section tells the story of why you should undertake this work. Keep this section as plain and straightforward as you can so the problem is readily understood. Save the complexity for later.
What are the primary objectives for this program? Keep these short and sweet, without complexity. Use bullets, try to have no more than five total objectives, and where possible make sure the outcomes are measurable (binary objectives are ok where you simply need to establish something new!). Make sure the objectives consider all necessary business needs including customer and internal requirements, risk, sustainability, and scalability. If you intend to ship something that isn’t safe or that you can’t maintain, you probably need to reassess your objectives.
Are there already a set of existing operating principles that this program will operate under? If not, what should they be? These statements should reflect company values, business or customer requirements, and anti-goals if necessary. These help guide decision making in a consistent manner through the life of a program. Again, use simple, bulleted statements.
This section summarizes the potential approaches (and recommends one or more of them) in order to achieve the objectives. This section may include multiple approaches that could be taken for various tradeoffs of security risk reduction, effort, other risks, etc… Some of these approaches may be orthogonal to each other and able to be used in conjunction with others, while some may be mutually exclusive.
Describe at a high level what this approach entails and how it will be executed to meet the objectives outlined above. Make clear what makes this approach distinct from alternatives below. You can use a paragraph or two of prose or bullets.
Clearly define the scope of the proposed approach. If specific systems, teams, or features need to be excluded from or included in the work, list those here.
What are the “big-rock” items that you need to ship to meet your objectives? When should you ship them in an ideal world based on your needs or customer needs (absent resourcing considerations)? How much effort do they entail? Consider using the format below:
**Milestone: **Title or brief description
**Summary: **A few sentences about the Milestone. What does it entail? How do we accomplish it?
**Impact on Objectives: **A few sentences about what objectives the Milestone helps achieve. Be explicit about how this work meets a need or reduces risk.
**Priority (High, Med, Low): **A basic reflection of the importance and urgency of this Milestone vs. others.
**Effort: (S, M, L, XL): **A basic reflection of the overall lift this Milestone represents vs. others.
Are there any specific resources that are required to implement this approach? Are there any that would be significantly more efficient?
Are there additional resources that could be added to accelerate the delivery of this approach? To reduce risks?
Any new program represents some amount of additional risk to manage. Maintenance? Reputational? Are there specific dependencies that would block work or prevent milestones from being worked in parallel?
Are there any important considerations or questions that need answering and can’t be forgotten? Is there something you want to flag for leadership or stakeholders? This is a good place to record these items for others to consider.
List any relevant documents, issues, PRs, design records, or external resources here. These may have been used to inform the content in this document or be useful for new stakeholders to gain context.