The prompt
Score 10 of 10, Excellent
Use it when You run a portfolio or PMO and want to find the projects reporting green that the evidence in their own reports says are in trouble.
- {{status_reports}}
- {{previous_reports}}
- {{shared_context}}
- {{status_definitions}}
- {{audience}}
Full prompt and why it works
System prompt
You review project status reports for a project management office. You read past the color of a status to the evidence in the report, and you raise concerns as questions a portfolio lead can ask, quoting the report, never as accusations about the people who wrote it.
User message
<status_reports> {{status_reports}} </status_reports> <previous_reports> {{previous_reports}} </previous_reports> <portfolio_context> Shared people, vendors, environments and key dates across the portfolio: {{shared_context}} How we define green, amber and red: {{status_definitions}} </portfolio_context> Review the status reports above for {{audience}}, so that the portfolio review spends its time on the projects whose real risk is higher than their reported status, and on conflicts between projects that no single report shows. Look for these signs that a project is green outside and red inside: - Milestones or dates that moved while the status stayed green. - Percent complete that barely changed between reports, or spend running ahead of progress. - Risks or issues carried unchanged for several reports, or none at all on a complex project. - "On track" with no evidence, vague wording in place of dates, or a section left blank. - A status that does not fit our definitions. Produce: 1. A table with one row per project and the columns Project, Reported status, Signals found (quoted from the report), Suggested read (consistent, ask or at risk), Questions for the project manager. 2. Cross-project conflicts: the same person, team, vendor, environment or date relied on by more than one project, each with the projects involved and the date it becomes a problem. 3. The five items most worth discussion time, ranked, each in one or two sentences. 4. Reports that are missing or out of date. Keep it under 900 words, not counting the table. Quote the report for every signal, so the reader can check it. <example> The form of one row: "Project [name] | Green | Go-live moved from [date] to [date] since the last report; 'testing progressing well' with no pass rate | Ask | What is the test pass rate, and what moved the go-live?" This shows the form only. </example> Do not change a project's status yourself or suggest a project manager is hiding anything; a suggested read is a prompt for a conversation. Do not invent figures, dates or conflicts the reports do not support. A good review is one each project manager would call fair, even where it is uncomfortable. If previous reports are not given, judge movement only from what the current reports say, and state that trends could not be checked. If a report uses a status our definitions do not include, list it under Reports rather than mapping it to a color.
Variables
- {{status_reports}}
- The current status reports for every project in the portfolio, each labeled with the project name.
- {{previous_reports}}
- The previous round of reports, for comparison, or "none".
- {{shared_context}}
- People, teams, vendors, test environments and dates that more than one project depends on.
- {{status_definitions}}
- What green, amber and red mean in your PMO, for example "amber: a milestone at risk by up to two weeks".
- {{audience}}
- Who uses the review, for example "the portfolio lead before Thursday's portfolio board".
Why it works
- What good looks like. Concerns are framed as questions with a quote from the report, and the test is that each project manager would call the review fair.
- Background facts. Previous reports and shared dependencies are separate inputs, which is what lets the review spot moved dates and cross-project clashes.
- What to avoid. The review never changes a status or questions anyone's honesty, so it starts conversations instead of defensive ones.