Reusable templates and lightweight operating tools for technical program management.
These are not meant to be perfect corporate artifacts. They are working templates for getting alignment, exposing risk, clarifying ownership, and helping teams move.
This repo is the workbench, not the policy binder.
This repo is for TPMs, engineering leaders, security program owners, and project leads who need practical structure without turning every program into process theater.
Use it when you need to:
- Start a program with clearer scope and ownership
- Turn ambiguity into an operating plan
- Track risks, assumptions, issues, and dependencies
- Communicate status without hiding the hard parts
- Create enough structure for teams to move with confidence
- Teach core program management ideas to people who are new to the work
| Template | What It Is |
|---|---|
| Program Phases Playbook | A phase-based view of how programs move from first idea through planning, execution, launch, and close-out. Useful for orienting a team around where the work actually is. |
| Program Charter Template | The founding document for a serious initiative. Captures problem, goals, scope, non-goals, stakeholders, risks, decisions, and success criteria. |
| Program Close-Out Report Template | A practical close-out format for outcomes, schedule and budget summary, risks, handoff, lessons learned, and recommendations. |
| Template | What It Is |
|---|---|
| RAID Log Guide | A guide for running a Risks, Assumptions, Issues, and Dependencies log as a living program tool, not a spreadsheet nobody trusts. |
| Communications Plan Template | A stakeholder and communications planning template for status reports, updates, document locations, meeting cadence, and escalation paths. |
| Program Swim Lanes Template | A multi-workstream view for programs with parallel tracks, owners, milestones, risks, and executive summary needs. |
| Template | What It Is |
|---|---|
| Program Kickoff Checklist | A lightweight checklist for aligning scope, stakeholders, risks, dependencies, decisions, and operating rhythm before a program starts. Lives in tpm-toolbox. |
| Meeting Notes and Action Item Tracker | A simple structure for capturing decisions, owners, due dates, open questions, and follow-ups. Lives in tpm-toolbox. |
| Template | What It Is |
|---|---|
| RFC Template | A Request for Comments template for proposals that need structured review before a decision is made. Covers context, motivation, proposal, risks, alternatives, and decision path. |
| ADR Template | An Architecture Decision Record template for documenting important decisions after they are made. Captures context, decision, alternatives, consequences, and status. |
| File | What It Shows |
|---|---|
| Sample RAID Log Entry | A concrete example of a weak risk entry versus a useful one, with field-by-field explanation of why specificity matters. |
| File | What It Is |
|---|---|
| PM: A Thanksgiving Story | A short presentation that teaches core project management concepts using Thanksgiving dinner as the running example. Built for a non-practitioner audience. Originally developed for Year Up. |
| Area | Status | Notes |
|---|---|---|
| Program charter | Ready | Good starting point for new programs, especially when scope and ownership are still fuzzy. |
| Program phases playbook | Ready | Useful for orienting a team around lifecycle, gates, artifacts, and decision points. |
| RAID log guide | Ready | Strong enough to use directly. Pair it with the sample entry. |
| Communications plan | Ready | Useful for stakeholder mapping, status cadence, and escalation planning. |
| Program swim lanes | Ready | Good for multi-workstream programs that need an executive summary layer. |
| RFC and ADR templates | Ready | Good base formats for engineering alignment and decision records. |
| Close-out report | Ready | Useful when a program needs a real ending, not just a quiet drift into operations. |
| Examples | Working | More examples will make this repo easier to adopt. The next useful additions are a sample charter excerpt and a steering decision example. |
Start with the Program Charter Template.
The charter forces the conversations that need to happen before execution starts:
- What problem are we solving?
- What is in scope?
- What is explicitly out of scope?
- Who owns the work?
- Who makes decisions?
- What does done mean?
- What risks are already visible?
- What constraints are real?
If you cannot fill in the charter, that is the signal. Do not paper over it. Use the blank sections to drive the next conversation.
Use the RAID Log Guide, Communications Plan Template, and Program Swim Lanes Template.
The RAID log is the program memory. The communications plan is how you keep people informed without spending the whole week answering the same status questions. The swim lanes view helps leadership understand how parallel workstreams fit together.
Use the Program Swim Lanes Template for cross-workstream visibility and the Communications Plan Template for audience, cadence, and message discipline.
Good reporting does not make a program look better than it is. It makes the actual state of the program easier to understand.
Start with the Program Phases Playbook.
Figure out where the program actually is, not where people say it is. Then look for the missing artifacts that should exist at that phase.
A program in execution with no clear charter is probably carrying hidden alignment debt. A program near launch with no risk log is probably relying on memory and heroics. A program closing without lessons learned is probably going to repeat the same mistakes.
Use the RFC Template before a decision is made.
Use the ADR Template after a decision is made.
The RFC is for structured debate. The ADR is for memory and accountability. Mixing those up creates confusion. If a team is still debating options, write an RFC. If the decision has been made and people need to understand it later, write an ADR.
Use PM: A Thanksgiving Story when you need to explain program management to people who do not live in TPM language.
The concepts are not simplified. They are translated. There is a difference.
These templates work well with AI as a drafting and critique partner.
Good uses:
- Turn messy notes into a first-pass charter
- Ask for risks, assumptions, issues, and dependencies you may have missed
- Rewrite a status update for a specific audience
- Check whether a decision ask is clear
- Convert meeting notes into owners, actions, due dates, and open questions
- Pressure-test whether a program is actually ready for kickoff or launch
Bad uses:
- Pasting confidential company data into a public model
- Letting AI invent facts, owners, dates, or commitments
- Publishing AI-generated artifacts without review
- Treating a polished draft as an aligned plan
- Using the template to avoid a hard conversation
AI can help with structure and speed. It does not own the facts, the judgment, the tradeoffs, or the final artifact.
This repo is too much process for a small effort that can be solved in two conversations.
It is not enough process for a regulated, multi-year program with legal review, audit evidence, customer commitments, and multiple executive sponsors.
That is fine. Templates are not laws. They are forcing functions.
Use them to expose the conversation you need to have. Do not use them as paperwork for its own sake.
These templates are starting points, not prescriptions.
A small three-person project does not need every field in the charter. A large security or infrastructure program may need more detail than what is here. Use judgment.
Fill them in or do not use them.
A half-filled charter is worse than no charter if it creates the illusion of alignment. If a section does not apply, say that. If a field is unknown, say who owns finding out. Blank space is not harmless when people mistake it for agreement.
The artifact is not the work.
The work is getting the right people aligned on the right problem, with clear ownership, visible risk, and a shared understanding of what happens next.
| Situation | Start Here |
|---|---|
| New cross-functional program | Program Charter Template |
| Program feels vague or stuck | Program Phases Playbook |
| Risks are scattered across meetings and memory | RAID Log Guide |
| Too many people are asking for status in different ways | Communications Plan Template |
| Multiple workstreams need one leadership view | Program Swim Lanes Template |
| Engineering proposal needs structured review | RFC Template |
| Decision was made and needs to be remembered | ADR Template |
| Program is ending or moving to operations | Program Close-Out Report Template |
| Someone needs to learn PM basics without jargon | PM: A Thanksgiving Story |
- Stakeholder engagement playbook
- Sample program charter excerpt
- Sample steering committee decision example
No giant roadmap. The goal is to add examples and templates that are useful enough to stand on their own.
- tpm-toolbox - Lightweight TPM trackers, checklists, and practical tools, including kickoff and meeting templates.
- program-reporting-frameworks - Status, steering committee, lessons-learned, and investment frameworks for honest program reporting.
- security-program-playbooks - Security TPM guides for intake, compliance triage, evidence planning, and cross-team execution.
- ai-automations - AI-assisted TPM prompts, workflows, examples, and review checks for safer program artifacts.
- learning-notes - Technical concepts, TPM craft notes, and working notes across security, systems design, and program practice.
These templates get better when they are used.
If a section does not hold up in real work, change it. If a template creates confusion, simplify it. If an example would make the tool easier to adopt, add it.
The bar is practical usefulness, not completeness.
Built from experience running platform security, infrastructure, compliance, and enterprise execution programs.
Maintained by Eric White.