Frameworks and templates for program reporting - status updates, executive communications, and investment cases. Built from real experience reporting on security, infrastructure, and compliance programs to engineering teams, senior leadership, and executive sponsors.
Reporting is not the job. Delivery is the job. But reporting done well is what keeps stakeholders aligned, surfaces problems early, and builds the trust that makes everything else easier. Reporting done poorly creates noise, erodes confidence, and generates the kind of questions you do not want to spend your week answering.
These frameworks are designed to make the reporting part of the job efficient, honest, and useful.
This repo is focused on reporting patterns for technical programs where clarity, trust, and decision-making matter more than slide polish.
Current materials cover:
- Program status reporting
- Executive investment cases
- Steering committee deck structure
- Lessons learned facilitation
- Sample Red / Yellow / Green reporting
This repo is not a dashboard product and it is not a portfolio-management system. It is a set of practical reporting frameworks for TPMs who need to make program reality visible early enough for leaders to act.
| Framework | What It Is |
|---|---|
| Program Status Reporting Framework | A two-tier status report model - short version for async triage, long version for full context. Includes status color definitions, cadence guidance, executive vs. operational reporting, and the most common mistakes. |
| Executive Investment Framework | How to build and present an investment case for a security or infrastructure program. Covers the five questions every investment case must answer, how to structure a compliance-driven request, and how to report on investment progress once approved. |
| Steering Committee Deck Structure | Slide-by-slide guide for building a steering committee deck that drives decisions rather than just reporting status. Covers what each slide should answer, what does not belong in the deck, and how to run the meeting itself. |
| Lessons Learned Facilitation Guide | How to run a retrospective that generates real insight. Covers pre-work, psychological safety, facilitation structure, common failures, and how to turn the session into useful output rather than a list of platitudes. |
| File | What It Shows |
|---|---|
| Sample Red / Yellow / Green Status | A weak status update vs. a complete one, with an explanation of why the difference matters for decision-making. |
- OKR tracking template
- Portfolio health dashboard
Starting a program: Set up your status report format at kickoff. Establish the cadence, the audience, and the channel before the first update goes out. Consistency builds trust faster than quality alone.
Reporting to leadership: The Status Reporting Framework's long version is your source document. The short version is what you send. The executive can ask for the long version if they need it - most of the time they will not.
Making an investment case: Work through the Five Questions in the Executive Investment Framework before you write anything. If you cannot answer all five clearly, you are not ready to make the ask.
Reporting on an approved investment: See the last section of the Executive Investment Framework on progress reporting. The metric that justified the investment is the metric you report against.
Running a steering committee: Use the Steering Committee Deck Structure before you build the slide deck, not after. It defines what belongs in the meeting and what does not - which is as important as the format itself.
Closing a program: The Lessons Learned Facilitation Guide gives you the structure for a retrospective that produces real insight. Run it before the team disperses. The output feeds the close-out report and the next program team.
Reporting frameworks fail when they become performance art: clean decks, vague health colors, no ownership, and no decision asked.
If the report does not change what someone knows, decides, escalates, or does next, it is probably overhead.
The frameworks here are built around one principle: status reports should reflect reality, not aspiration.
A program that is Yellow but reported as Green is not being managed - it is being managed around. The people who need to know it is Yellow do not know, which means they cannot help, which means the problem gets worse. By the time it goes Red, options are limited and trust is already damaged.
Call things what they are. Yellow or Red with a path-to-green is a sign of a well-run program. Green followed by a sudden crisis is a sign of a reporting problem. Stakeholders who trust your reporting will stay engaged and give you room to operate. Stakeholders who feel they are getting a managed version of reality will start asking for details you do not want to provide.
If you have a reporting framework, template, or approach that has worked in practice - open a PR or file an issue. The bar is that it has to reflect real experience, be applicable outside one organization, and be documented well enough to use without asking questions.
These frameworks exist because vague status creates real cost. A good report does not make the program healthier by itself, but it does make the truth visible early enough to do something about it.
Built from experience reporting on platform security, infrastructure, and compliance programs to engineering teams and executive leadership. Maintained by Eric White | ChefPlex