Reusable templates and lightweight operating tools for technical program management.
These are not meant to be perfect corporate artifacts. They're 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
- Clarify who owns what, who's consulted, and who just needs to know
- 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
This repo is the documents. The things that run - checklists, trackers, scripts - are in tpm-toolbox.
Four documents, in this order. They're the spine; everything below is situational.
- Program Charter Template - the founding conversation. Do this before anything else, because everything after it is execution.
- Program Kickoff Checklist - turns the charter into a room full of people who agree.
- Meeting Notes + Action Item Tracker - the habit that stops things getting dropped.
- RAID Log Guide - how to run a risk register people actually trust.
Read the worked examples alongside them. Each one shows a weak version next to a useful one, which is faster than any amount of instruction. They all draw on the same program, a platform encryption migration, so the artifacts connect to each other rather than standing alone.
- Program Phases Playbook - orienting a team on where the work actually is
- Program Swim Lanes - one leadership view across parallel workstreams
- Communications Plan - status that scales past what you can carry in your head
- RACI - Waterfall and RACI - Agile - settling who owns what. Two matrices rather than one with a toggle, because phase gates and sprint cadence break down differently. Fillable spreadsheet version: RACI_Templates.xlsx
- RFC and ADR - proposals before a decision, records after one
- Stakeholder Engagement Playbook - influence without authority, which is most of the senior job
- Cyber Incident Playbook - command structure when something is actively on fire
- Enterprise RAG Program - running retrieval as a program rather than an AI experiment
- Close-Out Report - giving a program a real ending instead of a quiet drift into operations
| Situation | Start Here |
|---|---|
| New cross-functional program | Program Charter Template |
| Program feels vague or stuck | Program Phases Playbook |
| You inherited work that is already late and already an argument | Rescuing Work That Is Off Track |
| Risks are scattered across meetings and memory | RAID Log Guide |
| Too many people are asking for status in different ways | Communications Plan Template |
| Stakeholders are misaligned, skeptical, or resisting, and you cannot just order them | Stakeholder Engagement Playbook |
| Multiple workstreams need one leadership view | Program Swim Lanes Template |
| Nobody can say who actually owns a decision - phase-gated program | RACI Template - Waterfall |
| Nobody can say who actually owns a decision - sprint-based team | RACI Template - Agile |
| 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 |
| A security incident is unfolding and you need command structure now | Cyber Incident Management Playbook |
| Someone handed you "we want AI over our own documents" | Enterprise RAG Program |
| Someone needs to learn PM basics without jargon | PM: A Thanksgiving Story |
| 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. |
| Rescuing Work That Is Off Track | What to do when you are handed something already moving, already late, and already the subject of an argument. Diagnosis, baselining with real throughput data, renegotiating the commitment, and the day 1 / 30 / 90 / 180 shape of the recovery. |
| 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. |
| Stakeholder Engagement Playbook | The strategy layer above the comms plan: how to identify the stakeholders who matter, map power and interest, and move skeptics and resource owners you do not command - influence without authority across the program lifecycle. |
| Program Swim Lanes Template | A multi-workstream view for programs with parallel tracks, owners, milestones, risks, and executive summary needs. |
| RACI Template - Waterfall | A phase-gated responsibility matrix for settling who's responsible, accountable, consulted, and informed across initiation through closure. |
| RACI Template - Agile | A sprint- and release-cadence responsibility matrix for Scrum, Kanban, or SAFe teams, including the ownership handoff at release. |
| Template | What It Is |
|---|---|
| Cyber Incident Management Playbook | An Incident Commander playbook grounded in the LDR553/CIMTK framework. Covers first-hour actions from detection through the first exec briefing, plus the full six-phase incident lifecycle from detect and classify through sustain and exercise. |
| Template | What It Is |
|---|---|
| Enterprise RAG Program | Running Retrieval-Augmented Generation as a program rather than an AI experiment. Playbook with phases, seven workstreams, governance and risk tiers, plus templates for the charter, use case catalog, data source inventory, evaluation plan, RAID starter, milestone exit criteria, and definition of done. The security workstream lives in security-program-playbooks. |
| 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. |
| Sample Program Charter Excerpt | A worked excerpt of a charter's core (Why / What / Scope) - a weak, directional version vs. one with a baseline, measurable Definition of Done, and an out-of-scope list that defends the scope. |
| Sample RACI Rows | Five rows from a real migration, weak against better. Two accountable owners, a TPM held accountable for work it cannot do, and the test that settles a row: if this goes wrong, whose calendar does the meeting land on? |
| Sample Architecture Decision Record | The same decision written twice. The weak one records what was chosen; the better one records what was rejected, what it cost, and the two conditions that would reopen it. |
| 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. |
| RACI templates (waterfall & agile) | Ready | Two separate matrices, not one template with a toggle - the phase structure and the sprint cadence break down differently and forcing them into one format hides the real handoff points. |
| 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. |
| Cyber incident playbook | Ready | Grounded in LDR553/CIMTK. Use as-is for first-hour response and the six-phase lifecycle; adapt battle rhythm timing to your org. |
| 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.
When ownership itself is the thing in question - not status, not risk, but who's actually on the hook for a decision - use the RACI Template - Waterfall or RACI Template - Agile, depending on how the program runs. Waterfall maps ownership to phases and gates. Agile maps it to the sprint and release cadence, where the handoff usually gets lost between "dev is done" and "it's actually live."
Use the Cyber Incident Management Playbook.
Part 1 covers the first hour: triage, command, scope, intent, battle rhythm, and the first exec brief. Part 2 covers the full lifecycle from detection through post-incident review. Use it as the incident commander's field reference, not a document to write from scratch mid-incident.
Use the Program Swim Lanes Template for cross-workstream visibility and the Communications Plan Template for audience, cadence, and message discipline.
Good reporting doesn't make a program look better than it's. 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's. 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. A program where every status update reads "on track" but nobody can say who owns the next decision probably needs a RACI more than it needs another status meeting.
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 don't 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
- Draft a first-pass RACI from a kickoff conversation, then correct it against what the room actually agreed to
- 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 doesn't 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's 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 doesn't 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 same goes for a RACI matrix with every cell filled in - a grid where every role touches every row isn't more thorough, it's a sign nobody actually worked out who owns what.
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.
- tpm-toolbox - The things I kept using after the program ended, including kickoff and meeting templates.
- program-reporting-frameworks - How to write a status report an executive can act on, and a steering deck that forces a decision.
- security-program-playbooks - What I'd hand a TPM taking over an encryption or compliance program in their first week.
- ai-automations - Prompts I actually use, and the frameworks for deciding how much AI belongs in a piece of work at all.
- learning-notes - A public notebook on security, systems design and program practice. Some of it will turn out to be wrong.
These templates get better when they are used.
If a section doesn't 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.
Copyright (c) 2026 Eric White. Licensed under CC BY 4.0: use it, adapt it, put it to work in your own program. Credit is the only condition.