Quiz — Chapter 21: Workplace Reports

Target: 70%+ before moving on. Answers and explanations are hidden—try each before expanding.


Section 1 — Multiple Choice

1. The defining purpose of a workplace report is to: - a) Document how much effort the writer put in - b) Serve as an input to a decision the reader must make - c) Create a complete chronological record of the work - d) Demonstrate the writer's command of the subject

Answer**b.** The reader is busy and must *do* something—approve, escalate, reassign, decide. Everything in the report is structured around that need. (a) and (d) confuse the report with a performance review; (c) is the writer's-order narrative the chapter warns against—chronology is how the work happened, not how the reader needs it. See §21.1.

2. "Exception-based reporting" means: - a) Reporting only when something goes wrong - b) Making exceptions to the standard report format when needed - c) Spending detail on what deviates from the plan; compressing what's routine - d) Listing every exception thrown by the software

Answer**c.** You allocate words and the reader's attention to the items that need action (the exceptions), and reduce on-track items to a single line. (a) is wrong—you still report when things are fine, you just say so briefly; the worst cadence is "only report when something's wrong." (b) and (d) misread the term. See §21.3.

3. In RAG status, amber means: - a) The project has failed - b) At risk but likely recoverable without escalation; the reader should be aware - c) On track, no action needed - d) Waiting on someone else

Answer**b.** Green = on track, no help needed; amber = at risk but recoverable without escalating; red = needs a decision or resources from above you now. Amber is the early-warning signal—not an admission of failure. See §21.3.

4. The "watermelon report" problem is: - a) A report that's too long to read - b) A status that's green on the outside but red on the inside—reported green until it suddenly fails - c) A report with too many colors - d) An incident report that assigns blame

Answer**b.** When everything is reported green until the week it explodes, the reporting failed as an early-warning system long before the project failed—usually because no one wanted to be the bearer of amber. Green should mean "genuinely fine," not "I'd rather not explain a problem." See §21.3.

5. In an incident report, the timeline should contain: - a) Your analysis of why the incident happened - b) Factual, timestamped events with no interpretation - c) The corrective actions and their owners - d) An assessment of who was responsible

Answer**b.** The timeline is the *Results* section of an incident report (echoing [Chapter 13](../../part-03-academic-scientific-writing/chapter-13-lab-reports/index.md)): what happened, neutrally, before anyone argues about why. Analysis of *why* belongs in the root-cause section (a); corrective actions are their own section (c); and blame (d) belongs nowhere—incident reports are blameless. See §21.4.

6. "Blameless" in an incident report means: - a) No one is held accountable for anything - b) The report attacks the system that allowed a human error to cause harm, not the human - c) The report omits any mention of what went wrong - d) Mistakes are never discussed

Answer**b.** Blameless does not mean no accountability; it means the analysis targets the systemic gap ("the pipeline had no required approval step") rather than the person ("X was careless"). That framing is what produces durable corrective actions, because the next person at that keyboard makes the same mistake unless the system changes. See §21.4.

7. Which "Done" entry in a progress report is correct? - a) "Worked on improving the checkout flow" - b) "Spent time looking into the performance issues" - c) "Shipped the redesigned checkout flow; live to 100% of users Thursday" - d) "Continued making progress on the dashboard"

Answer**c.** "Done" is for finished outcomes, not activities. "Worked on," "spent time looking into," and "continued making progress" all describe motion, not arrival—a reader can't tell whether anything finished. Only (c) names a completed outcome with a concrete result. See §21.2.

8. The single most important property of a meeting-minutes action item is: - a) That it captures the discussion that led to it - b) That it has exactly one named owner and a deadline - c) That it's written in complete sentences - d) That it records who proposed it

Answer**b.** An action item owned by "the team" or due "soon" will not happen. Exactly one accountable human and a real date are what make it trackable. The discussion (a, d) is what minutes *discard*—minutes record outcomes, not the conversation. See §21.6.

9. A feasibility study must always include: - a) Only the recommended option, argued thoroughly - b) The alternatives considered, including a "do nothing" baseline - c) A complete budget for the recommended option only - d) The author's personal preference, stated first

Answer**b.** A study's job is to *compare* options against criteria so a decision-maker can choose. With only one option and no baseline, there's nothing to compare and no way to tell whether acting beats not acting—it becomes an advocacy piece ([Chapter 20](../chapter-20-proposals-business-cases/index.md)'s proposal), not a feasibility study. See §21.7.

10. The cardinal mistake of a trip report is: - a) Being too short - b) The travelogue—a day-by-day diary instead of takeaways and recommendations - c) Including a recommendation - d) Naming the people you met

Answer**b.** The reader didn't go and doesn't need your itinerary; they need what you learned that changes what the team should do. Lead with key takeaways and recommendations; offer the full notes only as an appendix for anyone who wants them. See §21.7.

11. "BLUF" applied to a status update means: - a) Bury the lede until further detail - b) Put the overall status / headline first, so a reader who reads only the first line still gets the one fact that matters - c) Brief, lengthy, unstructured format - d) Begin with a list of all activities

Answer**b.** BLUF—bottom line up front ([Chapter 4](../../part-01-writing-is-thinking/chapter-04-structure/index.md))—means the most important information leads. In a status update that's the "Overall" roll-up color; in an incident report it's the summary paragraph. See §21.1 and §21.3.

12. Why do incident-report corrective actions and meeting-minutes action items both converge on an Action / Owner / Due table? - a) Coincidence of formatting conventions - b) Because the table format is the accountability—an action without one owner and a date is a wish - c) Because tables are required by most software - d) Because prose is never appropriate in reports

Answer**b.** Both genres independently discovered that an action item only happens when exactly one person owns it by a specific date, and the Owner/Due columns enforce that. The moment an action lives in a sentence, it has no owner and dies. See §21.5 and §21.6.

Section 2 — True/False with Justification

For each, state True or False and justify in one sentence.

T1. A status update where every workstream is green every week is a sign of a well-run project.

Answer**False.** Persistent all-green is the watermelon warning sign: it usually means problems aren't being surfaced (or aren't being anticipated), so the report has lost its early-warning value—the very thing it exists for. See §21.3.

T2. The timeline and the root-cause section of an incident report can be safely combined into one narrative, since an expert reader can infer cause from the facts.

Answer**False.** Keeping facts (timeline) separate from interpretation (root cause) protects the report's authority: if a reader disputes your analysis, your *facts* stay trustworthy—the same Results-vs-Discussion discipline from [Chapter 13](../../part-03-academic-scientific-writing/chapter-13-lab-reports/index.md), which matters when an incident may end up in front of a regulator or lawyer. See §21.4.

T3. Meeting minutes should record enough of the discussion that a reader can reconstruct the debate.

Answer**False.** Minutes record *outcomes*—decisions, actions, owners, deadlines—not the conversation. At most, a one-line context note captures *why* a decision went the way it did, when that's non-obvious. The transcript habit produces long documents no one reads. See §21.6.

T4. A progress report and a status update are essentially the same document with different names.

Answer**False.** They differ in audience and altitude: a progress report (planned/done/next/blocking) goes to someone tracking *your* work closely; a status update (RAG, exception-based) rolls up *many* workstreams for someone scanning the whole. The status update is more compressed because its reader is further from the work. See §21.2–21.3.

T5. Naming who caused an incident makes the report more useful, because it tells the organization who to hold responsible.

Answer**False.** Blame is a dead end—"X was careless" implies the fix is "X should be more careful," which fixes nothing; the next person makes the same mistake unless the *system* changes. Blameless framing ("the process allowed...") points at a real, durable fix. See §21.4.

T6. The amount of detail in a workplace report should scale with how much work the writer did.

Answer**False.** Detail should scale with the reader's distance from the work and the stakes of the decision, not with the writer's effort. A VP overseeing twenty projects gets one line per workstream regardless of how much was done. See §21.8.

Section 3 — Short Answer

S1. In one sentence, state the threshold concept of this chapter.

Model answerA workplace report is read to make a decision, not to admire effort—so report the exceptions, not the routine, and the owner and the deadline, not the discussion. *Rubric: must capture both "decision/reader-not-effort" and "exception/owner-over-routine/discussion."*

S2. Give the four-part skeleton of a progress report, and state the verb rule for one of those parts.

Model answer**Planned / Done / Next / Blocking.** Verb rule for "Done": report finished *outcomes* ("shipped," "identified the cause"), never *activities* ("worked on," "looked into")—a reader can't act on motion. *Rubric: all four parts named + a correct outcomes-not-activities statement.*

S3. Name the five sections of an incident report, in order.

Model answer**Summary → Timeline → Root cause → Impact → Corrective actions.** (Impact is sometimes folded into the summary; corrective actions carry owners and dates.) *Rubric: at least four of five in correct order; corrective-actions-with-owners noted.*

S4. What four kinds of information do good meeting minutes capture, and what do they discard?

Model answerCapture **decisions, action items, owners, deadlines**; discard the **transcript / conversation** (keeping at most a one-line context note for non-obvious decisions). *Rubric: all four captured + "not a transcript."*

S5. Why must a feasibility study include a "do nothing" baseline?

Model answerWithout it, the reader can't tell whether *acting* beats *not acting*, and can't see what's being given up—the comparison that is the study's whole purpose collapses, leaving an advocacy piece rather than a decision document. *Rubric: must connect baseline to the act-vs-not-act comparison.*

Section 4 — Applied Scenario

AS1. Here is a narrative status item. Rewrite it as a single exception-based RAG line (color + tight note + a decision with owner and date if one is needed):

"The mobile app workstream is in a tricky spot. We integrated the new SDK but it's crashing on older Android versions, which represent about 30% of our users. We could either drop support for those older versions, which some stakeholders won't like, or spend about a week finding a workaround. We need to figure this out before the release, which is in two weeks."

Model answer + rubric**🔴 Mobile app — new SDK crashes on older Android (~30% of users). DECISION by [date, before the 2-week release]: drop support for older Android OR spend ~1 week on a workaround. Owner: [name].** *Rubric (grade against these):* - *Leads with a color and the core problem (not chronology).* - *States the decision as a clear either/or, not "we need to figure this out."* - *Has an owner and a date tied to the release deadline.* - *Cut from ~70 words to ~30 without losing the decision.* Strong answers read as a routable line a busy reader acts on in seconds; weak answers keep the narrative hedging ("tricky spot," "we could either... or...") without resolving it into an owned, dated choice.

AS2. A teammate wrote this incident-report root cause. Rewrite it to be blameless and to separate the fact from the interpretation:

"The outage happened because Jordan deployed an untested change on a Friday afternoon, which was a bad idea, and it broke the login service for two hours."

Model answer + rubric**Timeline:** *14:50 — change (commit [id]) deployed to production. 14:53 — login error rate began rising.* **Root cause:** *The deployed change contained an untested code path that failed under production traffic. It reached production without test coverage because the CI pipeline did not require integration tests to pass for this service, and there was no deploy freeze or review gate for high-risk changes.* *Rubric:* - *Fact (a deploy happened, login errors rose) lives in a neutral timeline entry.* - *Root cause names the systemic gaps (no required integration tests, no review gate / freeze)—not "Jordan" and not "bad idea."* - *No judgment words ("careless," "bad idea") survive.* - *The corrective action this implies (add the test gate / freeze) would prevent recurrence regardless of who deploys next.*

Scoring & Next Steps

Score What it means Do this
< 50% Core distinctions not yet solid Re-read §21.1 (shared spine), §21.2 (progress report), §21.3 (RAG/exception-based); redo Section 1
50–70% Partial grasp Redo Exercises Part B (Revise This) and the §21.4 incident-report material
70–85% Solid—proceed Move to Chapter 22; keep the decision-framework table handy
> 85% Strong command Try Exercises Part E (design a reporting standard; the blameless rewrite)