When you’re planning to launch a big new program (or other big effort) at work, it’s valuable to step back and clarify, very succinctly the purpose and scope of this new thing. It’s easy early on when planning a big new thing to think you, and the people around you, are all clear and in-sync on the purpose and scope, but you’re probably not. It’s so valuable to spend the effort to sharpen it down into a few tight bullets or sentences that fit on a single slide.
I love this quote in this context — don’t keep adding words to your document/presentation, work on being intentional with a few, impactful words:
I didn’t have time to write a short letter, so I wrote a long one instead.
– Mark Twain
As the program comes into focus, consider fleshing out other key elements and communicate them clearly and publish it somewhere persistent, so the team working on it, and people affected/relevant to it can conveniently reference it:
Who
- Business Owner – Who owns the program after it launches, which is often not the same people planning and launching the new thing (this is often referred to as the “customer” for the effort, even though it’s often a colleague of yours, not an external customer)
- Program Launch Lead – Who will drive this effort getting from
- Relevant POCs in other functional areas as appropriate, such as IT, Finance, Marketing
- Responsible, Accountable, Consulted, Informed (RACI) Matrix, either focused on the launch effort for the post-launch execution/sustainment aspect of the program
What
- Project Objectives – specific, clear, measurable objectives
- Relevant tools, Technologies, and/or Links
- Assumptions
- Pre-Launch Risks
- Requirements – Make a table or list showing the requirements, and avoid overwhelming the reader with a huge list. If this is a complex effort, you should have high-level requirements here, that are decomposed elsewhere into a comprehensive requirements backlog/list.
When
- Program Launch Date
- Program Milestones – dates with specific scope to complete by each date
- Launch and/or Execution cadence, defining relevant significant meetings (e.g. Preliminary Launch Review) and recurring meetings (e.g. Sprint Planning meeting every two weeks)
Other Elements to Consider
There’s a lot more you can add in various areas, depending on what type of effort, and the complexity, and your organization’s size and maturity, but if you start with the lists above, you’ll have a solid foundation to start from. A few other things you could consider:
- Impact Assessments, such as cybersecurity impacts or financial impacts
- Decision Analysis – if this effort includes selecting from various courses of actions (COAs), such as different technologies or approaches, show a table with the options, and how they are being evaluated with scores
- Information Architecture
- Wireframes or Prototype designs
- Workflow
- Change Management approach/governance
- Permissions model
- Test/Quality Plan
- Transition Plan
- Communications Plan