On October 8, 2026, MIT News published a report describing course 6.C31, Hack Yourself, a joint venture with the Experimental Study Group developed by EECS Senior Lecturer Ana Bell, ESG Visiting Instructor Carter Jernigan, and ESG Senior Lecturer Paola Rebusco. According to the report, instructor Carter Jernigan describes a practice called the pre-mortem: a group imagines a project has already failed, lists everything that could have gone wrong, and works backward to prevent those problems. The article also notes that no single intervention emerged as universally best, and it does not claim a measured effect size for pre-mortems specifically.

The following meeting format adapts that reported idea for group coursework: a shared report, a lab write-up, a presentation, or a semester-long build. These steps are IvyClaw editorial suggestions, not official MIT guidance. The report does not establish access to the course for outside students, and this exercise carries no promise about grades. Adjust the meeting to your assignment, available time, and team members’ needs.

Why run a pre-mortem at all

Consider a few possible problems: a teammate cannot attend the agreed meetings, two people draft overlapping sections, or a dataset needs more cleaning than the schedule allows. These are hypothetical risks to discuss, not findings about how often student projects fail. Try setting aside thirty to forty-five minutes at the kickoff to examine them. That duration is a suggested starting point; a smaller assignment may need less discussion. The purpose is to identify actions while there is still time to change the plan.

The prompt changes the tense of the discussion. Ask, “Imagine we have reached the deadline and the project has failed: what went wrong?” Treat the answer as a hypothetical account, not a prediction. Invite concerns about the plan without treating them as criticism of a person. If the framing makes someone uncomfortable, explain the purpose and agree on wording the whole team can use.

Step one: write one specific failure scenario

Before the meeting, the team lead or whoever called the kickoff writes a single, concrete failure scenario and sends it to everyone. Vague prompts produce vague lists. "The project goes badly" is useless. "It is two days before the deadline and the final report is missing its analysis section because the data cleaning took three weeks instead of one" is useful, because it points at a cause you can act on.

Keep the scenario to two or three sentences. Name the deadline moment, the visible symptom, and one plausible chain of events. You are not trying to predict the future; you are giving the team a shared object to react to. If your course has multiple deliverables, you can run the exercise once per major deliverable, but for a first attempt, one scenario is enough.

Step two: gather causes independently, then compare

Before anyone speaks, offer five quiet minutes for each person to note possible causes. This gives every member a chance to contribute an initial view before hearing the others. Allow a written contribution or another accessible format if reading aloud is difficult. The exercise needs a range of concerns, not a contest to find the most confident speaker or the longest list.

As a starting prompt, ask for several causes, including unglamorous ones: scheduling conflicts, unclear division of work, a dependency on an instructor’s reply, incompatible file versions, or one member carrying the writing while others wait for instructions. Let each person contribute while someone records the ideas in a shared document. Collect first and discuss afterward. Repeated concerns deserve attention, but frequency alone does not establish their importance; an issue raised by only one person may still threaten the whole project.

Step three: choose three actionable risks

Rather than trying to address every possibility at once, begin with three risks that seem plausible, could seriously affect the deliverable, and allow a practical response. Three is a suggested limit, not a researched optimum. You cannot control a change to the grading rubric, but you can agree who checks official announcements and asks about unclear requirements. Distinguish the outside event from the action your team can take in response.

Look particularly at dependencies: work that must happen in sequence or requires something from outside the team. Examples include access to data, learning a required tool, obtaining feedback, or booking an approved presentation space. For each dependency, ask which later tasks would stop if it were delayed. Record unconfirmed access as unconfirmed, and consider an alternative that still satisfies the assignment rather than assuming the resource will arrive.

Step four: assign an owner, a prevention step, and an early warning

For each of the three risks, record three things in the shared document: one owner (a named person, never "everyone"), one prevention step, and one early warning sign. The owner does not do all the work; the owner is accountable for watching that risk and raising it.

Here is a hypothetical planning entry, not a student case: risk — cleaning the dataset takes longer than the plan allows. Owner — the teammate the group selects to coordinate data checks. Prevention — load an approved sample and document any problems before the next agreed checkpoint. Early warning — the sample cannot be loaded, a required field is missing, or the check is not completed by the agreed time. Response — discuss the obstacle and ask the instructor before changing any required scope. Choose warning thresholds appropriate to your data; “a few bad rows” is not a universal test.

A second hypothetical entry: risk — two members draft overlapping sections. Owner — the teammate coordinating the outline. Prevention — share a one-page section plan before drafting and ask everyone to confirm their responsibilities. Early warning — a section remains unassigned at the agreed checkpoint, or two drafts cover the same material. Response — resolve the overlap together and update the outline. The team should agree on actual names and dates in its own document.

Step five: agree on when to revisit

A pre-mortem document that is never reopened is theater. At the end of the meeting, agree on a specific revisit trigger and write it down. Two possible options: a fixed checkpoint, such as the first ten minutes of every second team meeting, or an event trigger, such as any early warning firing. Also decide where the document lives — the same shared folder as your drafts — and who pastes the three risks into the meeting agenda each time.

Finally, respect your course's actual rules. If the assignment requires instructor approval of team roles or milestones, route your plan through that process. A pre-mortem supplements your course requirements; it never replaces them.

Your next action

At your next group-project kickoff, try the sequence in one sitting: send a specific failure scenario, offer quiet time to list causes, collect everyone’s concerns, choose three actionable risks, and record one owner, one prevention step, and one observable warning for each. Before ending, agree on the first review date and where to find the record. Leave with a short set of decisions that your team can actually use.

中文摘要

2026年10月8日，MIT News 在课程6.C31“Hack Yourself”的报道中介绍了失败预演：先假设项目已经失败，列出可能原因，再考虑预防措施。本文提出的小组作业会议流程属于编辑建议：独立列出原因，讨论依赖关系，选出三个可应对的风险，为每项约定负责人、预防措施和可观察的预警，最后设定回顾时间。数量和时长只是起点，不代表经过验证的最优安排；计划应遵守课程要求，也不保证消除风险或提高成绩。