To send one sponsor update across several client projects, keep one shared table with a row per project, agree one rating rule before the first update, and list only the decisions the sponsor must make. Each project owner fills their own row from records the project already keeps. The lead checks the ratings and writes the headline once, so the sponsor gets one update rather than a separate report for each project.
What should one sponsor update contain?
One sponsor update contains a headline, a portfolio table with one row per project, a short list of the decisions the sponsor must make, and the next steps the team owes. Cascade describes an executive status report as a concise, timely update that shows whether a portfolio is on track, off-track, or at risk.
Put the parts in this order, so the sponsor reads the answer before the detail. Practical choice; the sources do not specify this order.
- Headline: the overall status of the client's projects in one or two sentences, written by the lead.
- Portfolio table: one row per project, with the same fields in every row.
- Decisions: only the choices that need the sponsor, each with a date.
- Next steps: what the team does next, and who owns each step.
Anything that needs more detail goes behind a link to the project's own tracker, not into the update. Practical choice.
How do you set up the table with one row per project?
Build one shared table with the same fields in every row: project, owner, health, trend, next milestone, top risk, decision needed, and next action. Scrumbuiss uses a portfolio table of this kind, with health, trend, and decision needed fields, and it keeps project detail out of the table.
- Create the table in one shared document or spreadsheet that every project owner can open. Practical choice; the sources do not specify this.
- Add one row per project, with the project name and owner in the first two columns. Practical choice; the sources do not specify this.
- Keep detail out of the row. Write the single top risk, then link to the project's own tracker for the rest. Sourced for keeping project detail out of the table: Scrumbuiss. Linking to your own tracker is a practical choice.
- Sort red and amber rows to the top, and show the trend beside the color so a project that got worse stays visible. Sourced: Scrumbuiss.
| Project | Owner | Health | Trend | Next milestone | Top risk | Decision needed | Next action |
|---|---|---|---|---|---|---|---|
| [Project name] | [Owner name] | [Green, amber, red, paused, or complete] | [Better, same, or worse] | [Milestone] by [date] | [One risk] | [Decision, or None] | [Action], [owner], [due date] |
The health column can hold paused and complete as well as green, amber, and red, because Scrumbuiss lists green, amber, red, paused, and complete as its health states. Use paused or complete for a project on hold or closed, and apply the same meaning in every row.
Each column can be copied from a record the project already keeps. The mapping below is a practical choice for the lead to check against each team's own records; the sources do not prescribe it.
| Column | Suggested place to copy it from |
|---|---|
| Project and owner | The project plan's header or team list |
| Health | The rating rule, applied to the next milestone date and the open risks |
| Trend | The health shown in the previous cycle's row |
| Next milestone | The milestone date in the project plan |
| Top risk | The highest-rated open item on the risk list |
| Decision needed | Open entries in the decision log that wait on the sponsor, or None |
| Next action | The next open task, with its owner and due date |
If a column has no source in a project's records, the owner should say so in the row rather than guess. Practical choice.
How do you agree on one rating rule across projects?
Write one short rule for green, amber, and red before any owner fills a row, and state which signal wins when they disagree. Smartsheet's executive template uses color to mark overall status, but its page does not define the colors, so the team has to set them.
- Write the rule in plain words, using the template below. Practical choice.
- Decide which signal wins when they disagree. A milestone date is easy to check, so it is a reasonable choice for the winning signal. Practical choice; the sources do not set a winning signal.
- Ask each owner to write one line in the row if their rating differs from the rule, and say why. Practical choice.
- Check each rating against the milestone date yourself before the update goes out. Practical choice.
Template:
Green: [your criteria for green] Amber: [your criteria for amber] Red: [your criteria for red] When signals conflict: [the signal that wins, such as the next milestone date]
Illustrative example, with placeholders rather than a real project: [Project name] is green on scope but red on the milestone [milestone name], which was due [date] and has passed. The rule says the milestone date wins, so the row shows red. The owner's reason line reads: [one-line reason, for example, the approval is still waiting on the sponsor]. The decision column names the one decision the sponsor needs to make.
Apply the rule the same way to every row, or the sponsor cannot compare them.
How do you collect each row without writing a separate report?
Ask each project owner to fill only their own row from records the project already keeps, then have the lead check each rating against the rule and write the headline last. Owners do not write separate reports, and the detail stays in each project's tracker.
- Send each owner the request below before the next sponsor meeting. Practical choice.
- Owners update their row only, and link to the detail in their tracker. Practical choice.
- Check that each rating matches the rule, each next action has an owner and a date, and each decision is named. Practical choice.
- Write the headline last, after every row is final. Practical choice.
Request wording:
Subject: [Client name] project update, rows due [date]
Hi [owner name], please update your row in [shared document] by [date]. Use the rating rule in [location]. Keep detail in [project tracker] and link to it from your row. If your project needs a decision from [sponsor name], name it in the decision column and say when you need the answer. Thank you, [your name]
A late row should still appear, marked as not yet updated, so the sponsor sees the gap rather than a missing project. Practical choice.
How do you show only the decisions the sponsor must make?
List only the decisions that need the sponsor, one per line, with the choice, the options, the date an answer is needed, and what slows down if the answer is late. Scrumbuiss advises keeping decision asks visible in its portfolio view.
Write each request with the choice first:
Decision: [Project name]. [Choice in one sentence.] Options: [Option A] or [Option B]. Lead's recommendation: [option and reason]. Answer needed by: [date]. If delayed: [what slows down].
The sources do not define a combined budget, dependency, or capacity view across projects, so the lead runs one check before sending. List any project that shares a person or a decision with another project, and name that conflict in the decisions list, for example: [Project A] and [Project B] both need [person name] to approve [item] by [date]. Practical choice; the sources do not specify this check.
A named conflict gives the sponsor a trade-off to choose between, rather than two projects quietly competing for the same person.
What does one full sponsor update look like?
A full sponsor update is a short headline, one table with a row per project, and a decision list, all on one page. The example below is illustrative: every name, date, and item in brackets is a placeholder, and it shows one red row, one amber row, and two decisions.
Illustrative example. Every name, date, and item in brackets is a placeholder.
Headline: [Client name] projects are mostly on plan this cycle. [Project 3] is red because [milestone] has passed, and the recovery plan is in [shared document]. [Project 5] is amber while it waits for [sponsor name] to answer [Decision 2].
| Project | Owner | Health | Trend | Next milestone | Top risk | Decision needed | Next action |
|---|---|---|---|---|---|---|---|
| [Project 3] | [Owner 3] | Red | Worse | [Milestone] by [date] | [One risk] | [Decision 1] | [Action], [owner], [date] |
| [Project 5] | [Owner 5] | Amber | Worse | [Milestone] by [date] | [One risk] | [Decision 2] | [Action], [owner], [date] |
| [Project 1] | [Owner 1] | Green | Same | [Milestone] by [date] | [One risk] | [Decision 2] | [Action], [owner], [date] |
| [Project 2] | [Owner 2] | Green | Better | [Milestone] by [date] | [One risk] | None | [Action], [owner], [date] |
| [Project 4] | [Owner 4] | Green | Same | [Milestone] by [date] | None | None | [Action], [owner], [date] |
The red and amber rows sit at the top, as the sort rule in Scrumbuiss asks. Sourced for the sort; the placeholder rows are illustrative.
Decisions:
- [Project 3]: [Decision 1 in one sentence]. Options: [Option A] or [Option B]. Lead's recommendation: [option and reason]. Answer needed by [date]. If delayed: [what slows down].
- [Project 5] and [Project 1] both need [person name] to approve [item] by [date].
The red row's evidence sits in its own short note, kept separate from this update. Practical choice.
When is one update not enough?
One update is enough when every project is green or amber and each has a known next step. A red project, or one waiting on a sponsor answer that has not arrived, needs its own short note with the evidence behind the rating. Practical choice; the sources do not set this test.
A combined update can hide problems. A lead may soften red ratings to keep the table calm, and a sponsor who reads only the headline may miss a blocker in one row. Before sending, check each red and amber row against the evidence, and confirm that every blocker appears in the decisions or next steps. Practical choice.
How do you keep each client's data separate?
Keep each client's rows and evidence in that client's own folder or workspace, and send the combined update only to that client's sponsor. If one sponsor covers several projects, one update works. If sponsors differ, filter the same table into one update per sponsor.
- Keep each client's rows and evidence in that client's own folder or workspace. Practical choice.
- Copy only the row text into the combined update, not the project files. Practical choice.
- Link a row only to a project page the sponsor can open. Scrumbuiss links each row to a live project dashboard, so use that pattern only when the sponsor has access. Sourced for the dashboard link pattern; the access check is a practical choice.
- Check that no other client's name, figure, or decision appears before the update is sent. Practical choice.
How do you send the update each cycle?
Send the update on the same day each cycle, after every owner's row is in and the lead has checked the ratings. Keep the subject line the same so the sponsor can find the last one, and record each sponsor answer as a closed decision in the next table. Practical choice; the sources do not set a sending day or cadence.
- Send the update to [sponsor name] with the subject [Client name] project update, [date]. Practical choice.
- Ask the sponsor to answer each decision by reply, naming the option they choose. Practical choice.
- Carry each answer into the next cycle's table, and mark the decision closed. Practical choice.
- Note any next action the team owes the sponsor, and check it at the next cycle. Practical choice.
This week, fill one client's rows from the existing project plans, check each rating against your rule, and have the update ready before your next sponsor meeting.