New website projects almost always begin with excitement and a launch date. They rarely begin with a written list of ways the launch could go badly. This primer introduces a short exercise called a pre-mortem, shows how to apply it to a website or CMS project, and ends with a mini-glossary so unfamiliar jargon never stalls the meeting. No experience is required, only a willingness to spend an hour being usefully pessimistic.

What a pre-mortem is

A pre-mortem is a planning meeting with one unusual rule: everyone assumes the project has already failed. Instead of asking “what could go wrong?”, which tends to produce shrugs, you say “the site launched and it was a mess; what happened?” People then write down causes as if reporting on events that are already over. Because the failure is treated as fact, the discussion becomes specific and a little more honest.

Why it suits website work

A website has many moving parts that belong to different people: design, copy, hosting, plugins, domain settings, analytics and the content editors who use it daily. Each owner usually assumes the others have checked their part. A pre-mortem puts all the owners in the same room and invites them to name what they are quietly worried about.

It is also cheap. Changing a page structure in planning takes a conversation. Changing it after launch means redirects, lost search visibility and confused visitors.

Step-by-step for a website launch

1. Set the scene. Write one sentence: “It is one month after launch and the new site has hurt the business.”
2. Gather everyone who touches the site. Include the person who will edit content, not only the developers.
3. Write silently for five to ten minutes. One cause per note.
4. Group the notes into themes such as content, technical, people and timing.
5. Vote on the biggest few. Choose those that are both likely and costly.
6. Assign actions. Each action gets an owner and a date, or it does not count.

The usual suspects

When teams run this for a site project, the same suspects appear often enough that you can use them as prompts.

• Missing pages. Visitors cannot find pricing, contact details or key service information. A guide to which pages a business site needs to have makes a useful checklist for this theme.
• Old addresses breaking. Pages from the previous site vanish without redirects, and search traffic drops.
• Content not ready. The design is finished but the text is placeholder, so launch day slides or ships half-empty.
• Plugin or extension conflicts. A late update clashes with another component.
• Nobody trained the editors. The people who will maintain the site have never used the admin screens.
• Weak planning upstream. The goals were never written down, so success cannot be measured. A walkthrough on planning a business site before development begins covers those early decisions.

Do not forget the delivery chain

Many modern sites are built through an automated process: code is stored, tested and pushed to the live server by a pipeline. If that process fails or is misused, the site can break or be altered in ways nobody intended. DevSecOps Now publishes a blog that mostly covers securing CI/CD pipelines, and is a decent place to see why engineers fret about that link. For a small project, the pre-mortem question is plain: “If a bad change reached the live site, how would we find out and who could stop it?”

Mini-glossary

These terms come up in most pre-mortems for web projects. Keep them handy.

• Pre-mortem: a meeting where the team imagines a project has failed and lists the reasons.
• Post-mortem: the real review held after something has actually gone wrong.
• Launch: the moment a new site or feature becomes visible to the public.
• CMS (content management system): the software editors use to create and update pages without writing code.
• Redirect: a rule that forwards anyone requesting a retired page to its replacement.
• Staging site: a private copy of the website used for testing before changes go live.
• Pipeline: an automated sequence that tests and delivers changes from developers to the live site.
• Owner: the single named person responsible for a task. Shared ownership usually means no ownership.
• Mitigation: an action that reduces either the chance or the damage of a risk.

Turning notes into actions

Suppose your notes say “old pages were not redirected.” A practical mitigation is to export a list of existing pages before building, decide where each should go, and test the redirects on staging. If the note says “editors were not trained,” schedule a short session before launch and give editors a simple page-editing guide. If the note says “launch content was unfinished,” set a content freeze date earlier than the launch date.

Not every risk can be removed. For those, decide in advance what you will do. A rollback plan, for instance, lets you restore the previous version of the site if something serious appears. Make sure the plan is written down and that someone has actually tested it.

How the notes should look afterwards

A good outcome is a one-page list with five to eight items. Each item has a plain description, an owner and a date. Put it in the project folder and review it at three points: when the design is approved, when staging is ready, and the day before launch. Cross off completed items and add new ones as the work reveals them.

Resist the temptation to make the list exhaustive. If it grows to forty items, nobody will read it. Keep the ones that matter and let the rest go.

Pitfalls for beginners

• Treating it as a complaint session. Keep the tone practical and move quickly to actions.
• Leaving out the client or editor. The people who live with the site often see problems first.
• Running it too late. Hold it while the plan can still change.
• Stopping at the list. The list is a means. The follow-up is what changes outcomes.

Where to go from here

Try the exercise on your next small task, such as a landing page or a redesign of one section. The first session will feel slightly awkward, and the second will go faster. Over time, you will notice that your ordinary project plans begin to include the checks you used to find only in the pre-mortem. That is the real aim: not a ritual, but a habit of thinking about failure early, while it is still cheap to prevent.