Rescue a Software Launch as a TPM

Recover a failing software launch with a TPM command center and go/no-go plan.

Introduction

30 Second Summary

A software launch can look healthy until test results expose blocked work. When the deadline is close, scattered updates make the real decision hard to see.

In this project, you will take over Northstar Notify as its Technical Program Manager. You will turn conflicting updates into an evidence-based go/no-go decision with a dated recovery plan for leadership.

What You'll Build

Your finished launch-recovery package shows a red Day 10 program becoming a customer-safe Day 15 plan that you can defend to leadership in 90 seconds.

By the end of this project, you'll have:

A leadership-ready TPM command center that shows owners, milestones, dependencies, five launch gates, current evidence, and overall health in one view.
A RAID log and critical path that show why Day 10 is unsafe and which owner-based actions make Day 15 credible.
An executive-ready recovery story you can deliver through a one-page update, a three-slide review, and a 90-second briefing with a direct leadership ask.
Secret Mission: Reopen the launch decision after a failed rollback drill and defend a Day 16 target under schedule pressure.

Are there any prerequisites?

No prior technology or program-management experience is required. Your existing access to Google Sheets, Google Docs, and Google Slides covers every tool in the simulation.

Before We Start

Your existing workspace has Google Sheets, Google Docs, and Google Slides ready. This step commits you to the project role before any hands-on work: I am the TPM for Northstar Notify, and my job is to protect customers while creating a credible path to launch.

Set Up the TPM War Room

Northstar Notify starts with teams believing the Day 10 launch is on track. Without one source of truth, updates can fragment across conversations.

Your TPM war room creates one shared home for every program update.

In this step, get ready to:

Create the program command center in Google Sheets.
Create the written leadership channel in Google Docs.
Create the executive-review shell in Google Slides.

Create the program command center

The command center holds the working program record. It gives every owner a consistent place to report evidence.

The workbook separates delivery tracking, RAID management, and decision analysis into dedicated tabs. This structure makes each update easier to place.

Return to the Google workspace account you confirmed earlier in your browser.
Sign in with that account if your browser asks.

You should see your existing Google workspace without any new account setup.

Create a blank Google Sheets file in that workspace.
Name the file Northstar Notify - Program Command Center.

You should see the file name at the top of your new spreadsheet.

Rename the first tracker tab Launch Plan.
Add a second tracker tab named RAID Log.

You should now see two named tracker tabs at the bottom of the spreadsheet.

Add a third tracker tab named Decision Matrix.

You should now see Launch Plan, RAID Log, and Decision Matrix at the bottom of the spreadsheet.

Enter these headers from left to right in row 1 of Launch Plan: Workstream, Owner, Milestone, Due Day, Dependency, Status, Evidence, and Next Action.
Enter these headers from left to right in row 1 of RAID Log: ID, Type, Description, Owner, Impact, Due Day, Mitigation, and Status.

You should see eight headers across the first row of each tracker tab.

Leave Decision Matrix blank for the options analysis later in the simulation.

The command center now has two structured trackers plus one empty decision workspace.

Create the written leadership channel

The leadership update turns tracker details into a short decision narrative. Its fixed headings keep the message focused on impact and action.

Create a blank Google Docs file in your existing Google workspace.
Name the file Northstar Notify - Leadership Update.

You should see the file name at the top of your new document.

Enter each heading on a separate line in this order: Overall Status, What Changed, Customer Impact, Decision, Path to Green, and Leadership Asks.
Format each line as a document heading.

This order moves leadership from current health to the decision required. It finishes with the support the program needs.

You should see six headings in the document. Each heading should have empty space beneath it for a later update.

Create the executive-review shell

The executive review provides a visual version of the same program story. Three slides keep the review centered on health, risk, and recovery.

Create a blank Google Slides file in your existing Google workspace.
Name the file Northstar Notify - Executive Review.

You should see the file name at the top of your new presentation.

Enter Program Health and Decision as the title of the first slide.

You should see one titled slide in the presentation.

Add a second slide to the presentation.
Enter Critical Path and Top Risks as its title.

You should see two titled slides in the presentation.

Add a third slide to the presentation.
Enter Path to Green and Leadership Asks as its title.

You should see three titled slides in the presentation.

Before you check, consider whether every required title, tab, heading, and tracker column is present.

Switch back to Northstar Notify - Program Command Center.

You should see the tabs Launch Plan, RAID Log, and Decision Matrix.

The first row of Launch Plan should read Workstream, Owner, Milestone, Due Day, Dependency, Status, Evidence, and Next Action.

The first row of RAID Log should read ID, Type, Description, Owner, Impact, Due Day, Mitigation, and Status.

The Decision Matrix tab should be blank.

Switch back to Northstar Notify - Leadership Update.

You should see the headings Overall Status, What Changed, Customer Impact, Decision, Path to Green, and Leadership Asks.

Switch back to Northstar Notify - Executive Review.

You should see three slides titled Program Health and Decision, Critical Path and Top Risks, and Path to Green and Leadership Asks.

✔️ My workspace matches

Your three-file war room is ready. Every future update now has a clear destination.

ⓧ I'd like to double check

Fix the command center

Correct the Sheets file name to Northstar Notify - Program Command Center.
Correct the tracker tab names to Launch Plan, RAID Log, and Decision Matrix.
Correct the Launch Plan headers to Workstream, Owner, Milestone, Due Day, Dependency, Status, Evidence, and Next Action.
Correct the RAID Log headers to ID, Type, Description, Owner, Impact, Due Day, Mitigation, and Status.
Clear any content from the Decision Matrix tab.

Fix the leadership channels

Correct the Docs file name to Northstar Notify - Leadership Update.
Correct the document headings to Overall Status, What Changed, Customer Impact, Decision, Path to Green, and Leadership Asks.
Correct the Slides file name to Northstar Notify - Executive Review.
Correct the slide titles to Program Health and Decision, Critical Path and Top Risks, and Path to Green and Leadership Asks.

Your TPM war room is ready. Next, you will turn the fictional program brief into a baseline launch plan.

Build the Baseline Launch Plan

Your three-file war room is ready. The empty tracker now needs a baseline that every team can use as the same source of truth.

A target date becomes defensible only when every team has a named owner, milestone, and dependency. Launch gates turn readiness into pass-or-fail evidence.

In this step, get ready to:

Record six owned workstreams with their milestones and dependencies.
Define the five required launch gates.
Publish the Day 10 baseline with an overall Green status.

Accept the fictional program brief

Northstar Commerce plans to release the fictional Northstar Notify customer beta on Day 10. Day 10 is a relative program milestone instead of a calendar date.

Keeping one workstream per row makes ownership easy to scan. Columns A through G hold the current baseline while the Next Action column stays available for later updates.

Switch back to Northstar Notify - Program Command Center in Google Sheets.
Select the Launch Plan tab.

You'll see the eight headers created earlier in row 1.

Use the row-number menu beside row 1 to insert 10 blank rows above the current headers.

You'll see the existing headers move to row 11.

Fill row 12 across columns A through G with Backend API, Maya, Stable API and performance test, Day 8, None, Green, and Team reports on track.
Fill row 13 across columns A through G with Mobile app, Leo, Integrated release candidate, Day 9, Stable Backend API, Green, and Team reports on track.

You'll see two Green workstreams with Maya and Leo as their owners.

Fill row 14 across columns A through G with Web preference center, Priya, Customer preference controls, Day 8, Security data-access review, Green, and Team reports on track.
Fill row 15 across columns A through G with Security and privacy, Omar, Audit logging and data-access sign-off, Day 8, Backend and web evidence, Green, and Team reports on track.

You'll see four Green workstreams with their prerequisites named in the Dependency column.

Fill row 16 across columns A through G with SRE and operations, Nina, Monitoring and rollback drill, Day 9, Stable release candidate, Green, and Team reports on track.
Fill row 17 across columns A through G with Product and communications, Sofia, Beta approval and customer message, Day 10, All launch gates passed, Green, and Team reports on track.

You'll see six owned workstreams spanning the technical work and the customer release.

Keep cells H12 through H17 blank for future next actions.

Rows shifted out of place?

Clear any values that started in the wrong column.
Re-enter each affected row beginning in column A.
Check that the eight original headers remain together in row 11.

Ask for help fixing misplaced workstream data in the Launch Plan.

Define the launch gates

These five thresholds are fictional Northstar requirements for this simulation. They create a shared definition of safe launch readiness.

How do the technical gates work?

The p95 latency is the response time that 95 percent of requests meet or beat. It highlights slow customer experiences that an average can hide.

A rollback restores the previous stable software version after a problem. The drill checks whether the team can recover within the required time.

Enter at least 99% successful requests during performance testing in cell D1.
Enter p95 latency at or below 500 milliseconds at 1,000 requests per minute in cell D2.

You'll see the reliability success-rate gate above the latency gate.

Enter no open launch-blocking security or privacy finding in cell D3.
Enter mobile and web release candidates complete in cell D4.

You'll see the security gate followed by the release-candidate gate.

Enter rollback restores the previous stable version within 10 minutes in cell D5.

You'll see five required gates listed in cells D1 through D5.

Gate text hard to read?

Widen column D until each gate is readable.
Check that each requirement occupies one cell.
Compare the percentages and time limits with the values above.

Ask for help checking the five launch gates.

Publish the baseline health

A status gains meaning from its confidence source. This baseline is Green because every team reports being on track while none of the five gates has passed yet.

Placing the summary in cells A1 through A4 keeps the date and confidence visible beside the gate list. Leadership can compare reported health with measured readiness in one view.

Enter Target: Day 10 in cell A1.
Enter Overall Status: Green in cell A2.

You'll see the target and initial program status together at the top of the sheet.

Enter Passed Gates: 0 of 5 in cell A3.
Enter Confidence Source: Team reports only in cell A4.

You'll see that the Green status comes from team reporting instead of passed launch evidence.

Trace the Dependency column from the Product and communications row toward each prerequisite.
Confirm that every dependency cell names the workstream or launch condition its row waits on.

Before the final review, what supports the Green status today: test evidence or team reporting?

Review the four summary cells in A1 through A4.
Count the required gates in D1 through D5.
Count the populated workstream rows from 12 through 17.
Scan the Status column for the same health value in every workstream row.

You'll see a Day 10 target with an overall Green status. You'll also see zero passed gates with confidence based on team reports only.

Your table shows six owned workstreams with milestones and dependencies. Your gate list shows five pass-or-fail requirements.

Strong start. You now have a fixed baseline that makes later changes visible instead of letting verbal updates rewrite the plan.

Your baseline launch plan is ready. Next, live readiness evidence will test whether the Day 10 promise can survive contact with reality.

Run Launch Readiness

Your baseline in Google Sheets gives every Northstar Notify workstream an owner. It also shows how the teams expect to reach the Day 10 customer beta.

That Green status currently rests on team reports. Day 8 readiness evidence now tests whether the original date can satisfy every launch gate safely.

In this step, get ready to:

Replace team-report optimism with measured readiness evidence.
Trace the critical path to the earliest safe customer beta.
Record active problems and future uncertainty in the RAID log.

Process the Day 8 evidence

Objective readiness evidence comes from measured results and verified technical states. It gives you a stronger basis for launch decisions than verbal confidence.

Day 8 Readiness Evidence

Maya reports 96.8% successful requests with p95 latency of 850 milliseconds at 1,000 requests per minute. Her earliest stable retest is Day 11.

Omar reports that customer preference changes are missing from the required audit log. The finding blocks security sign-off until an earliest verified fix on Day 10.

Leo cannot finish the mobile release candidate before the API stabilizes on Day 11. Nina needs that stable release candidate before running the rollback drill on Day 13.

Sofia has drafted the Day 10 customer announcement. She asks the team to preserve the original date.

How to Read p95 Latency

p95 latency describes the response time experienced by 95 percent of requests. Northstar checks it alongside the successful-request rate because both measurements affect customer reliability.

Compare the measured success rate of 96.8% with Northstar's required 99%.
Compare the measured p95 latency of 850 milliseconds with Northstar's maximum 500 milliseconds.

Before you update the plan, does the Day 10 customer beta still satisfy all five launch gates?

Switch back to Northstar Notify - Program Command Center from earlier.
Select the Launch Plan tab.
Leave the five required gates unchanged.

Set Overall Status to Red.
Set Confidence Source to objective readiness evidence.

Your summary now displays a Red program based on measured readiness evidence.

Update the Backend API row to show earliest stable retest Day 11, Red, 96.8% successful requests and p95 850 ms at 1,000 RPM. Both reliability gates failed, and Optimize and retest by Day 11.
Update the Mobile app row to show earliest Day 12, Red, Cannot complete until API stabilizes, and Complete integration after stable API.

You can now see the first schedule dependency. The failed API test pushes mobile integration beyond the original launch date.

Update the Security and privacy row to show earliest verified fix Day 10, Red, Customer preference changes are not written to required audit log. Launch-blocking, and Implement logging, verify records, and sign off by Day 10.
Update the SRE and operations row to show earliest Day 13, Red, Cannot run rollback drill until stable release candidate exists, and Run monitoring validation and rollback drill Day 13.

The security finding creates a separate launch blocker. The rollback drill also moves because SRE lacks a stable release candidate.

Update the Web preference center row with the next action Support security evidence.
Update the Product and communications row to show Day 10 originally, Green, Day 10 customer announcement drafted, but gates are not passed, and Hold customer announcement pending decision.

This is the launch-readiness turning point. Objective evidence has replaced the Green story built from team reports.

Why One Workstream Remains Green

The Product and communications workstream completed its current task by drafting the announcement. Its Green status describes that workstream's progress.

The overall program remains Red because customer launch readiness depends on all five gates. One completed communication task cannot offset launch-blocking reliability or security evidence.

Trace the realistic launch path

The critical path is the chain of dependent work that determines the earliest possible finish date. A delay anywhere on this chain moves the customer beta.

How the Handoffs Move the Date

The stable Backend API on Day 11 unlocks mobile integration.
The Mobile app release candidate on Day 12 unlocks SRE validation.
The SRE rollback drill on Day 13 unlocks the leadership review.
The Day 14 leadership review leaves one day of launch buffer before the customer beta.
The Day 10 security fix remains a parallel launch blocker outside the dependency chain.

Leave Target: Day 10 unchanged so the original commitment stays visible.
Record Backend API -> Mobile app -> SRE and operations -> Customer beta as the critical path.

The dependency chain now shows which work determines the earliest customer release.

Add a realistic sequence block with Backend API Day 11, Mobile app Day 12, SRE rollback drill Day 13, leadership go/no-go Day 14, and customer beta Day 15 with one-day launch buffer.
Keep the security fix visible as a parallel launch blocker due on Day 10.

Your timeline now separates the original Day 10 target from the evidence-based Day 15 path. The buffer protects the customer beta from launching immediately after the final decision.

Build the RAID response

A RAID log keeps risks, assumptions, issues, and dependencies visible. An issue is already happening while a risk describes something uncertain that may happen later.

Classify Before You Log

Use Issue for the failed reliability test because the failure already exists.
Use Issue for missing audit logging because the blocker already exists.
Use Dependency for work that waits on another deliverable.
Use Risk for a future event that remains uncertain.

Return to the RAID Log tab from earlier.
Enter I-01 as an Issue with description Reliability test failed success and latency gates, owner Maya, impact Launch-blocking reliability failure, due day Day 11, mitigation Optimize, retest, and publish evidence, and status Open.
Enter I-02 as an Issue with description Audit logging missing and security sign-off blocked, owner Omar, impact Launch-blocking security/privacy finding, due day Day 10, mitigation Implement logging, verify records, and sign off, and status Open.

The RAID Log now separates the two active failures by owner. Each issue has a dated mitigation tied to evidence.

Enter D-01 as a Dependency with description Mobile integration and rollback validation wait for a stable API and release candidate, owner Leo and Nina, impact Delays critical path to customer beta, due days Days 12 and 13, mitigation Reserve Day 12 mobile and Day 13 rollback validation windows, and status Open.
Enter R-01 as a Risk with description Customer communications may be sent before the revised go/no-go decision, owner Sofia, impact Customer confusion and expectation mismatch, due day Day 14, mitigation Hold external message and prepare revised communications, and status Open.

The dependency explains why the date moves. The future communications risk shows what could still go wrong before leadership makes a decision.

Before you review the finished command center, which date do you expect the complete evidence to support?

Select the Launch Plan tab.
Confirm that the summary shows Overall Status: Red with Passed Gates: 0 of 5.
Confirm that Backend API, Mobile app, Security and privacy, plus SRE and operations show Red.
Confirm that the critical path reads Backend API -> Mobile app -> SRE and operations -> Customer beta.
Return to the RAID Log tab.
Confirm that I-01, I-02, D-01, and R-01 all show Open.

The evidence supports an earliest safe customer beta on Day 15. That sequence includes the Day 14 leadership go/no-go review plus one day of launch buffer.

Does the Dashboard Still Look Green?

Check that the overall status cell uses Red instead of the original Green.
Compare each Red workstream against its Day 8 evidence and earliest completion day.
Check that the Day 15 sequence follows the dependency order recorded in the critical path.

Ask for help checking the evidence if the dates still conflict: Help me compare my Northstar Notify launch plan with the Day 8 readiness evidence.

You have done the difficult TPM work: your command center now exposes why Day 10 is unsafe. Next, you will compare the available choices and create an owner-based path back to Green.

Make the Go/No-Go Decision

Your Google Sheets command center now shows why Day 10 is unsafe. The next TPM move is a defensible go/no-go decision grounded in that evidence.

A Red status exposes the problem. This step turns it into a customer-protecting decision with an owner-based route back to Green.

In this step, get ready to:

Compare three launch options in the Decision Matrix.
Assign each recovery milestone to an owner and date.
Record the approved decision in the RAID Log and leadership update.

Compare the three launch choices

A decision matrix makes each option's trade-offs visible. It keeps schedule pressure from hiding customer risk or failed gates.

Switch back to the Northstar Notify - Program Command Center file from earlier.
Select the Decision Matrix tab at the bottom of the sheet.

You should see the blank Decision Matrix that has been waiting for this analysis.

Add these six column headings to the first row: Option, Customer Risk, Gate Compliance, Schedule Impact, Learning Value, and Reversibility.
Enter this first comparison row: Option A: full Day 10 customer beta despite failed gates | High | Non-compliant | Minimal | Limited safe learning | Low.

You should see Option A preserve the original date while scoring poorly on customer safety and gate compliance.

Enter this second comparison row: Option B: cancel all Day 10 activity and move beta to Day 15 | Low | Compliant if gates pass | Moderate | Low | High.
Enter this third comparison row: Option C: employee-only demo on Day 10 with no external release and Day 15 beta if all gates pass | Low | Compliant | Moderate | High | High.

You should now see all three options compared against the same five criteria.

Reversibility measures how easily the program can change course without exposing customers. The employee-only demo preserves learning while the external beta remains protected by the launch gates.

Write your recommended option below the matrix before checking the benchmark.

The benchmark rejects Option A because failed reliability and security gates make an external Day 10 launch unsafe. It selects Option C because that choice protects customers while preserving a controlled learning event.

Set the final recommendation to Recommendation: Option C.

You have turned a tense schedule debate into a decision that leadership can inspect and defend.

Create the path to Green

A path to Green assigns each missing piece of evidence to one owner and one date. The RAID log preserves the decision history if new evidence later forces another review.

Select the Launch Plan tab.
Replace the launch summary with this four-part status: Target customer beta: Day 15 | Overall Status: Red pending gate completion | Passed Gates: 0 of 5 | Day 10 activity: employee-only internal demo, no external customer release.

You should see Day 15 as the customer target while the overall program remains Red until every gate passes.

Add a Recovery Sequence label below the existing workstream table.
Enter Day 10 | Omar | Closes and verifies audit logging as the first recovery row.

You should see the security blocker assigned to Omar with a Day 10 evidence deadline.

Enter Day 11 | Maya | Publishes passing reliability evidence as the next recovery row.
Enter Day 12 | Leo | Completes mobile integration as the next recovery row.

You should see the stable API evidence scheduled before the mobile integration milestone.

Enter Day 13 | Nina | Completes monitoring and rollback drill as the next recovery row.
Enter Day 14 | TPM | Runs final evidence review as the next recovery row.

You should see the rollback drill feeding directly into the final evidence review.

Enter Day 15 | Sofia | Releases customer beta only if all five gates pass and publishes revised communications as the final recovery row.

Your sequence should now run from Omar's Day 10 security evidence to Sofia's conditional Day 15 customer release. The critical path remains Backend API -> Mobile app -> SRE and operations -> Customer beta.

Select the RAID Log tab.
Add Evidence, Rejected Option, and Reopen Condition as columns to the right of the existing table.

You should see space for the facts behind the decision and the condition that forces leadership to review it again.

Use These Decision Record Fields

ID: DEC-01.
Type: Decision.
Description: No-go for Day 10 customer beta. Approve employee-only internal demo and target Day 15 customer beta.
Owner: TPM and leadership.
Impact: Protect customers and preserve controlled learning.
Due Day: Day 10.
Mitigation: Complete owner-based recovery plan and final evidence review.
Status: Active.
Evidence: 96.8% success rate, p95 850 ms, missing audit logging, blocked dependencies.
Rejected Option: Full customer beta on Day 10 despite failed gates.
Reopen Condition: Any failed required gate reopens go/no-go.

Add a new RAID Log row using the DEC-01 decision record above.

You should see the Day 10 no-go recorded beside the issues and dependencies that caused it. Any future failed gate now has an explicit route back to go/no-go review.

Write the leadership decision note

The Google Docs decision note turns the command-center evidence into a short leadership record. It connects the failed gates to customer risk and the dated recovery plan.

Switch back to the Northstar Notify - Leadership Update file from earlier.
Place your cursor below the Decision heading.

You should see the blank space reserved for the leadership decision.

Add the following decision note exactly as written:

The original Day 10 Northstar Notify customer-beta target is no longer safe because performance testing produced 96.8% successful requests and p95 latency of 850 milliseconds at 1,000 requests per minute, while required audit logging is missing and security sign-off is blocked. Launching customers with failed reliability and security gates creates unacceptable customer risk. We selected Option C: an employee-only internal demo on Day 10 with no external release, followed by a Day 15 customer-beta target if all five gates pass. Omar will verify audit logging by Day 10, Maya will publish passing reliability evidence by Day 11, Leo will complete mobile integration by Day 12, Nina will complete monitoring and rollback validation by Day 13, and the TPM will review final evidence on Day 14. Leadership ask: approve the customer-communication change from Day 10 to Day 15.

Confirm that the note sits directly below the Decision heading.

Before you review the finished artifacts, which decision do you expect leadership to see first?

Return to the Northstar Notify - Program Command Center file.
Select the Decision Matrix tab.
Check which option is recommended.
Select the Launch Plan tab.
Check the customer target and Day 10 activity.
Select the RAID Log tab.
Check the decision status and reopen condition.

You should see Recommendation: Option C in the Decision Matrix. The Launch Plan should communicate No-go for Day 10 customer beta through its internal-demo-only plan.

The customer target should read Target customer beta: Day 15. The RAID Log should state that any failed required gate reopens go/no-go.

Return to the Northstar Notify - Leadership Update file.
Check that the decision note matches the approved recovery plan.

You should see the failed reliability evidence and missing audit logging tied directly to the Day 10 no-go. You should also see the Day 15 target and the request to approve revised customer communications.

Your no-go decision now has evidence, owners, dates, and a clear reopen condition. Next up, you will turn this recovery plan into an executive briefing that leadership can act on.

Brief Leadership

Your Day 10 no-go decision now protects customers through a dated recovery plan. The evidence behind that decision is recorded in your command center.

Senior leaders need a short narrative that connects technical failures to customer impact. This step turns your evidence into a clear decision plus specific leadership action.

In this step, get ready to:

Complete a one-page leadership update.
Build a three-slide executive review.
Rehearse a 90-second executive briefing.

Complete the one-page update

A leadership update gives decision-makers the status first. It then connects evidence to customer impact plus the recovery plan.

Your Google Docs file already contains the decision note. You will reorganize that evidence under the six headings from earlier.

Switch back to Northstar Notify - Leadership Update in Google Docs.
Replace the earlier standalone decision note with content under the six existing headings.
Under Overall Status, write Red.
Under What Changed, write Readiness evidence showed 96.8% successful requests. p95 latency reached 850 milliseconds at 1,000 requests per minute. Both reliability gates failed. Required audit logging is absent. Security sign-off is blocked.
Under Customer Impact, write A Day 10 external beta could expose customers to unreliable notifications. Preference changes could also go untracked.
Under Decision, write No-go for the Day 10 customer beta. An employee-only internal demo is allowed. There is no external customer release. Any failed required gate reopens go/no-go.
Under Path to Green, write Omar verifies audit logging on Day 10. Maya produces passing reliability evidence on Day 11. Leo completes mobile integration on Day 12. Nina completes monitoring plus the rollback drill on Day 13. The TPM reviews final evidence on Day 14. Sofia releases the customer beta on Day 15 only if all five gates pass.
Under Leadership Asks, write Approve revised customer communications moving from Day 10 to Day 15.

Why This Structure Works

The first line gives leaders the current status. The next sections show the evidence behind it.

The update finishes with a dated recovery path plus one decision for leadership. Every section earns its space on the page.

Remove repeated sentences until the update fits on one page.
Confirm that all six headings remain visible.
Confirm that the first line under Overall Status says Red.

Your leadership update now tells the full recovery story on one page. A leader can find the status plus the requested decision without searching through the command center.

Build the three-slide review

An executive review turns the written update into a visual storyline. Each slide answers one leadership question about the decision.

Your Google Slides deck already has three titled slides. You will use Slide 1 for the decision, Slide 2 for the evidence, plus Slide 3 for the recovery plan.

Switch back to Northstar Notify - Executive Review in Google Slides.
Select the slide titled Program Health and Decision.
Add Overall status: Red.
Add Day 10 customer beta: No-go.
Add Employee-only demo allowed. Day 15 conditional recovery target.

Build an Executive Storyline

Slide 1 leads with the decision. Slide 2 proves why that decision is necessary.

Slide 3 shows how the program returns to green. This sequence keeps the conversation focused on action.

Slide 2 explains why the launch date moved. It connects the critical path to the two launch-blocking issues.

Select the slide titled Critical Path and Top Risks.
Add Critical path: Backend API -> Mobile app -> SRE and operations -> Customer beta.
Add Launch blocker: failed reliability evidence. Owner: Maya.
Add Launch blocker: missing audit logging and blocked security sign-off. Owner: Omar.
Add Mobile and rollback work depend on a stable API and release candidate.

Slide 3 converts the recovery plan into a dated sequence. It ends with the approval that leadership needs to provide.

Select the slide titled Path to Green and Leadership Asks.
Add Day 10: audit logging verification and internal demo. Day 11: reliability evidence. Day 12: mobile integration. Day 13: monitoring and rollback drill. Day 14: final evidence review. Day 15: conditional customer beta.
Add Leadership ask: approve revised customer communications.

Start the deck in presentation view.
Advance through all three slides.

On Slide 1, you should see the Red status plus the Day 10 no-go decision.

On Slide 2, you should see the critical path plus the two named launch blockers.

On Slide 3, you should see the Day 10 through Day 15 recovery sequence plus the leadership ask.

You now have an executive review that moves from decision to evidence to action. Each slide supports one part of your spoken briefing.

Run the executive review aloud

A spoken briefing tests whether your decision remains clear without the detail of the full command center. The strongest version connects status to customer impact within 90 seconds.

Use Message Hierarchy

Lead with the Red status before discussing metrics. Leaders need the decision context before the supporting detail.

Finish with the leadership ask. A briefing without a clear ask leaves the next action unresolved.

Use the one-page update plus the three-slide deck as prompts.

Before you start the timer, do you expect your current briefing to fit inside 90 seconds?

Start a 90-second timer.
Deliver the briefing in this order: status, what changed, customer impact, decision, path to green, leadership ask.

A complete briefing contains five visible signals.

Confirm that you stated the overall status is Red.
Confirm that you named the failed reliability gates plus the missing audit logging.
Confirm that you stated the Day 10 customer beta is a no-go.
Confirm that you described the conditional Day 15 path to green.
Confirm that you asked leadership to approve revised customer communications.

Stakeholder questions test whether the decision survives schedule pressure. Each response should connect back to customer risk or objective launch evidence.

Answer Product's question in one sentence: Why can we not keep Day 10 and fix issues after launch?
Answer Engineering's question in one sentence: Why is Day 15 credible rather than another optimistic date?
Answer Leadership's question in one sentence: What evidence will cause you to reopen the decision?

Benchmark Your Responses

Product: Day 10 is unsafe because required launch gates remain failed.

Engineering: Day 15 is credible through dated owners plus a Day 14 evidence review against all five gates.

Leadership: Any failed required gate reopens go/no-go.

Keep the Case Honest

Northstar Notify is a fictional case exercise. Its value comes from your reasoning plus the quality of your artifacts.

Describe this work as a fictional case exercise whenever you share it.
Confirm that your timed briefing finished within 90 seconds.
Confirm that your Product response links failed gates to customer risk.
Confirm that your Engineering response uses dated dependencies plus required gates.
Confirm that your Leadership response reopens go/no-go after any failed required gate.

That completes your leadership-ready launch-recovery package. You can now defend the Day 10 no-go plus the conditional Day 15 target under executive pressure.

Secret mission

Respond to a Failed Rollback Test

Day 15 was approved only while every required gate remained achievable. The Day 13 rollback drill now takes 18 minutes against a 10-minute gate. Reopen the decision based on this failed gate. Move the conditional customer beta to Day 16 before briefing the fictional VP of Product.

Clean Up Your Resources

Your three Northstar files remain in your Google account. This project costs $0 with your existing access, so keeping them creates no project-related charge.

Decide whether to keep the files available, close them for now, or delete them entirely.

Resources you used:

The Google Sheets file named Northstar Notify - Program Command Center.
The Google Docs file named Northstar Notify - Leadership Update.
The Google Slides file named Northstar Notify - Executive Review.

Keep everything running

No action is needed. Choose this if you want to keep practising the Day 16 decision or revisit your launch-recovery reasoning.

Keep Northstar Notify - Program Command Center as the source of truth for the fictional program.
Keep Northstar Notify - Leadership Update as your one-page escalation record.
Keep Northstar Notify - Executive Review as your three-slide briefing deck.
Return to the completed package whenever you want to rehearse the 30-second escalation.

Pause - I'll come back to this later

Close the three files for now. The saved cloud files remain available when you are ready to continue.

Close the browser tab containing Northstar Notify - Program Command Center.
Close the browser tab containing Northstar Notify - Leadership Update.
Close the browser tab containing Northstar Notify - Executive Review.

Your Day 16 decision package stays intact in your Google account.

Delete - I don't want to use this again

Remove all three files if you do not want to retain the fictional program data.

Your practice files stay available unless you complete the permanent-deletion instructions below.

Delete the command center:

Return to the Google Sheets home screen from the open command center.
Delete Northstar Notify - Program Command Center through its file context menu.
Confirm Northstar Notify - Program Command Center no longer appears in the Google Sheets file list.

Delete the leadership update:

Return to the Google Docs home screen from the open leadership update.
Delete Northstar Notify - Leadership Update through its file context menu.
Confirm Northstar Notify - Leadership Update no longer appears in the Google Docs file list.

Delete the executive review:

Return to the Google Slides home screen from the open executive review.
Delete Northstar Notify - Executive Review through its file context menu.
Confirm Northstar Notify - Executive Review no longer appears in the Google Slides file list.

Complete permanent removal:

Open your Google workspace trash.
Select the three Northstar Notify files.
Permanently delete the selected files.
Confirm the three filenames no longer appear in the trash.

That completes the cleanup. Your fictional Northstar launch artifacts are no longer stored in your Google workspace.

Nice Work!

You did it! You rescued the fictional Northstar Notify launch with evidence-based decisions under schedule pressure.

You've learned how to:

Build a TPM command center in Google Sheets. Use objective evidence to show program health.
Map the critical path to a credible launch date. Separate active issues from future risks in a RAID log. Assign a mitigation to every entry.
Make a customer-protecting go/no-go decision from failed launch gates. Publish the rationale in Google Docs. Present the recovery plan in Google Slides. Defend it in a timed executive briefing.
Secret Mission: Reopened launch readiness after a failed rollback gate. Kept Day 15 at No-go. Set Day 16 as the conditional target based on Nina's retest evidence.

Ready to quiz yourself?