Junior Project & Risk Ops: operational checklists for your first event

As a junior coordinator you're not paid to invent checklists: you're paid to apply them punctually and flag blockers. This guide teaches you how to adopt the team's standard checklist without over-engineering it, how to fill in the risk register handed to you by the senior, and how to recognize when a P0/P1 risk emerges that exceeds your autonomy. Three case studies (Atlassian Retrospective Play, Stripe Sessions logistics, Scalapay all-hands) and three first-year antipatterns.

TL;DR

Operational checklists are the most underrated asset of an event and - paradoxically - the L1 level is where their value is highest. For the junior coordinator the checklist is not a creative output: it's an input received from the senior, applied with discipline, updated punctually, shared in real time. Public data from PCMA Convene and Cvent show that events managed with standard checklists have a production fallback rate 3-4 times lower than events managed ad hoc. The three things that separate a junior who manages the checklist well from one who is overwhelmed by it are: blind adoption of a standard baseline (don't reinvent the wheel), the discipline of punctual updates (the status of every item is always consistent), and the sensitivity to recognize when an item that has been in progress for too many days is actually a disguised blocker. The framework anchors to the CMP domains Project Management (6%) + Risk Management (7%) + Site Management (10%) - together they account for 23% of the exam, a signal of the operational weight of this phase. You'll also find three case studies (Atlassian retrospective, Stripe Sessions, Scalapay), three antipatterns (the over-engineered checklist, the risk register closed at kick-off, the item in-progress for too many days) and an Event Brief 1-pager template that is the foundation on which to build the checklist.

When you need it / Prerequisites

This guide is useful from the moment you have the validated brief and the stakeholder map, and you need to translate that material into concrete actions with deadlines. The typical case is a single-BU event of 50-150 attendees with 3-4 weeks of preparation: you're the junior coordinator, you receive a standard team checklist (or an industry template) from the senior and you have to adapt it to your specific event, keep it updated during preparation, apply the tasks on the day of the event and produce a final operational report that the senior will use as input for the post-mortem.

There are five prerequisites, in order of importance. First: the brief has been validated by the senior. Without a brief you can't calibrate the checklist to the specific context of the event. Second: the stakeholder map exists (see L1-C2 direct-team stakeholders) and includes the critical vendors. Third: you have access to the team's standard checklist or, alternatively, to an industry template (Atlassian Team Playbook, Cvent operations checklist, PCMA event ops template). Fourth: you have a project management tool. Fifth: you have half a day free to do the first complete setup of the checklist.

What is not a prerequisite at L1 level is the ability to identify the event's P0/P1 risks on your own. That ability forms after 6-12 months of direct experience. At L1 level the risk register is an input received from the senior (with the list of risks already identified in the brief) and you update it punctually, flagging when a risk materializes or a new weak signal emerges. The difference between L1 and L2 on this point is sharp: the junior collects signals and passes them to the senior; the mid interprets the signals and proposes mitigation; the senior decides and implements. If you're asked to do the last two at L1, it's a sign of an organizational problem, not of your incompetence.

If one of the prerequisites is missing, stop and fix it first. A checklist built without a brief is a generic to-do list; a checklist without a stakeholder map has gaps in its owners; a checklist without a project management tool lives in a messy Excel file and gets lost after two weeks. Investing 4-6 hours of setup today prevents 30-40 hours of re-work in the following weeks.

Conceptual framework: the checklist as an execution tool, the risk register as a surveillance tool

The framework that guides this phase distinguishes two complementary but different tools. The operational checklist is an execution tool: it contains everything that needs to be done, with deadlines and owners, and is organized chronologically (pre-during-post). The risk register is a surveillance tool: it contains everything that could go wrong, with trigger signals and mitigation, and is organized by category (vendor risks, technology risks, attendance risks, financial risks).

The junior's frequent confusion is treating the two tools as if they were the same. The wrong pattern: the junior fills in a mega-checklist with 200 items that mixes high-certainty tasks (book venue) with risk elements (do a site visit to mitigate the risk of an unsuitable venue). The result is an illegible checklist in which it's no longer clear what is execution and what is surveillance. The correct pattern: two separate tools, managed at different cadences - the checklist is updated daily, the risk register weekly.

The operational checklist, according to the CMP Project Management framework and MBECS F. Operations, has three canonical phases. The pre-event phase contains 50-70 items for a BU event of 50-150 attendees: venue booking (date, contract, deposit, confirmation), vendors (quotes, contracts, briefs sent, confirmations received), invitations (distribution list, email send-out, RSVP tracking, reminder, final confirmation), materials (badges, printed programs, signage, swag), internal communication (reminders to the audience, brief to the sponsor), special-needs management (food intolerances, accessibility, simultaneous translation if needed). The during-the-event phase contains 15-25 time-intensive items: venue opening, registration, session time-keeping, break management, coffee station, photos, social posting if planned. The post-event phase contains 15-25 cleanup items: teardown, invoicing, survey, archiving, mini-report.

The risk register is organized by category, following the PCMA Convene framework that identifies eight canonical categories: speaker no-show, technology failure, attendance shortfall, budget overrun, vendor failure, weather/health emergency, security incident, brand/reputation hit. For a single-BU junior-level event, typically 3-5 categories are relevant (no-show, vendor failure, attendance shortfall, budget overrun, technology failure). For each one the senior identifies 1-2 specific risks, defines the trigger (which signal tells us it's about to materialize) and the mitigation (what to do). The junior updates the status of each risk weekly - monitored, materializing, materialized, resolved - and flags the status changes to the senior.

The operational principle for the junior is discipline beats creativity. Standard checklists are boring and perfect as they are. Resist the temptation to reinvent them. The value of the standard checklist is that everyone on the team knows it, knows what each item means, knows how to fill it in. If the junior overhauls it for personalization, the value of standardization is lost. The rule: take the standard checklist, add the 5-10 items specific to your event (e.g. check with catering for vegetarians > 20% of the total), don't touch the other 90 items.

Operational steps: six steps to build and manage the checklist

The six steps cover everything from the first setup of the checklist to the final post-event report. Times indicated are for an event of 50-150 attendees with 3-4 weeks of preparation.

Step 1 - Adopting the standard checklist (days 1-2)

The first task is to ask the senior for the team's standard checklist. It almost always exists. If it doesn't, ask the senior for a pointer to an industry template - the Atlassian Team Playbook has a Project Kickoff play with an attached checklist, the Cvent Blog publishes templates downloadable for free, PCMA Convene has public templates for corporate events.

Blind adoption of the baseline is an act of discipline, not of laziness. The junior who improves the standard checklist before having used it at least once is making a sequencing error. The operational rule: first event, apply the checklist as it is. Second event, after seeing how it works, propose 2-3 specific changes to the senior based on experience. Third event, you've developed the sensitivity to adapt it. Skipping the first two iterations produces a Frankenstein checklist that doesn't work well.

Typical times for adoption: 2-3 hours to read the checklist, understand every item, identify which items are not applicable to your specific event (in a single-BU event of 80 people maybe the partner sponsor brief item isn't needed), add the 5-10 items specific to your event. You save the checklist in your project management tool. You share it with the operational team that same day. In the following 24 hours the team flags any missing additions (rarely more than 2-3) and version 1.0 of the checklist is closed.

A useful sub-practice is the difference between checklist and template: the checklist is the list of actions; the templates are the pre-formatted documents that live inside the actions. When the checklist says send brief to the catering vendor, the template is the standard email you already have ready to personalize. The difference between an average junior and a good junior is the quantity of templates they have ready - the more templates, the less time spent rewriting every operational email from scratch. The Event Brief 1-pager template in the final section is the mother template to start from.

Step 2 - Adapting to your event + risk register (days 3-5)

The second task is to adapt the standard checklist to your specific event by adding the 5-10 unique items, and to receive the pre-filled risk register from the senior. For the items to add, typical examples: check with catering for vegan/intolerance requests (target ≥10% of total attendees), coordinate simultaneous translation with vendor X if overseas attendees > 5, check with IT facility wifi guest capacity for 100 simultaneous connections.

You don't fill in the risk register from scratch: the senior receives it from the brief (the risks section) and passes it to you for execution. Typically 3-5 pre-identified risks for a single-BU junior event: vendor failure (catering or A/V), attendance shortfall, budget overrun, keynote speaker no-show (if applicable), technology failure (projector or microphones). For each one the senior has already written the trigger and the mitigation; your job is to monitor the triggers and activate the mitigation when they emerge. Example: risk attendance shortfall, trigger at -10 days from the event, registrations < 50% of target, mitigation activate additional push via internal channel + Slack, reduce catering order.

A frequent error: the junior receives the risk register, files it in a sheet, never opens it again. The correct pattern: the risk register lives in the weekly calendar as a fixed 20-minute review point (e.g. every Friday 16:00). In that review the junior updates each risk with (a) current status, (b) triggers observed, (c) mitigations activated or to be activated. The review closes in 15-20 minutes if there's nothing new; it takes 30-45 minutes if a risk is materializing. Cumulative cost: 60-90 minutes over 4-6 weeks of preparation. Benefit: early capture of all weak signals.

A specific practice for the junior just starting out is the weak-signals notebook: during preparation, every time you sense something that smells off but you don't know exactly why, you write it on a dedicated page of your Excel sheet (date, source, feeling, severity 1-5). Example: 2026-05-12. Catering confirmed but didn't respond about intolerances. Feeling: 2/5 (a bit imprecise, but nothing serious). These signals are reviewed weekly with the senior. Three quarters of weak signals resolve on their own; a quarter materialize into a real problem. Capturing signals early is worth 10× more than capturing them late.

Step 3 - Daily update cadence (days 6-21)

From the sixth day onward the checklist becomes your main working tool. The operational cadence: 15 minutes in the morning (status check of today's items), 10 minutes in the evening (closing done items, escalating blocked items to the senior). Five days a week, four weeks, a total of 10-12 hours of operational discipline. It's the least glamorous phase of junior work, and the one that more than any other separates those who grow from those who burn out.

The daily format that works is a mini-review of the checklist in a tool like Notion, Asana or ClickUp. Each item has four statuses: todo (not started), in-progress (under way, with an estimate of completion), done (closed with verification), blocked (blocked, with an explicit reason). The blocked items are the critical ones: every block must be escalated to the senior within 24 hours. The operational rule: if an item stays in-progress for more than 3 days without visible progress, it's actually a disguised blocked. The good junior recognizes the disguise early.

A valuable practice for the junior is the daily 5-minute commit: every morning, after the status check, you write three things in chat to the senior - what I'm closing today, where I'm blocked, any risks I'm monitoring. It's more concise than a stand-up, it's asynchronous, and it builds progressive visibility of your work. The GitLab Handbook - Asynchronous Communication codifies this practice as a daily commitment: the async choice preserves the senior's focus time while maintaining alignment.

On timeboxing the items: some are fast (e.g. send reminder to attendees: 30 minutes), others slow (e.g. negotiate venue contract: 5-7 days elapsed with multiple touch-points). The standard checklist distinguishes the two natures with an expected elapsed time field. For the junior, a useful practice: at the start of the week you schedule the fast items in 2-hour blocks (e.g. Tuesday afternoon 14:00-16:00 = closing 4 fast items) to avoid scattering them into micro-tasks. The slow items stay in monitoring with defined touch-points (e.g. venue follow-up every 48 hours).

Step 4 - Week T-7: pre-event review with the senior (days 14-15)

At 7 days from the event the cadence changes. You move from the daily to multiple daily touchpoints, and you enter the contingency management phase. The pre-event review with the senior in week T-7 (a 60-minute meeting) is the critical check-point: you go through the entire checklist item by item, close the pending items, activate the mitigations for the risks showing signs of materialization, decide any scope changes (reductions if needed, additions if possible).

The format of the T-7 review follows a simple structure: 10 minutes for the numerical summary (X items done, Y in-progress, Z blocked; X risks monitored, Y materializing), 30 minutes for the review of the blocked items + active risks, 15 minutes for decisions and actions for the next 7 days, 5 minutes for alignment on the event-day logistics (who arrives when, who manages what, where you meet). The deliverable of the review is a go-live checklist: a list of the 20-30 items that absolutely must be closed before the day of the event, with owner and deadline.

A specific practice of the T-7 review is the go/no-go criteria: the senior and the junior decide together the three minimum criteria below which the event is cancelled or downsized. Typical examples: if registrations < 30% of target at T-3 days, we downsize from auditorium to classroom; if the venue confirms cancellation, we move the event by 2 weeks; if the keynote speaker confirms a no-show 48h before, we activate the backup speaker. The rule: three criteria maximum, explicit, written down. More than three criteria become unmanageable under pressure.

Step 5 - Event day: applying the run-of-show (day T)

On the day of the event the checklist becomes an operational document called the run-of-show: a chronological list of activities with precise times (e.g. 08:00 venue opening, 08:15 A/V check, 08:30 operational team arrival, 09:00 attendee registration starts, 09:30 BU sponsor greeting, 10:00 keynote starts). The junior arrives with the run-of-show printed (yes, printed - the phone can run out of battery), with a synchronized watch and a stopwatch.

The three operational rules of the day. First: arrive 2 hours early relative to the official opening of the event, to absorb the first surprises (vendor running late, room with lights not working, microphone that won't turn on). Second: the junior does not attend the sessions, they stay in operational control. Third: every 30 minutes a micro-check against the run-of-show to verify the alignment between planned and actual. If we're +10 minutes versus plan, recover in the next session. If we're -15 minutes (ahead), propose a longer break.

On A/V, a practice recommended by the Cvent Blog: 90 minutes before the start do the complete test - speaker microphone, moderator microphone, Q&A microphone, projector, sound system, any streaming. A complete test, not just the microphone works. The difference between a partial test and a complete test is the difference between the microphone works on standby and the microphone works with the voice of the person who will actually speak, at the real distance, with the background noise of the event.

On technology risks: plan B is worth more than plan A. If the primary projector breaks, there must be a backup projector in the room. If the wireless microphone runs out, there must be a wired microphone ready. If the guest wifi goes down, there must be a 4G hotspot from the A/V vendor. The Cvent Blog cites a figure: 14% of corporate events had a technology fallback in production, and those that had run a simulated test had an average recovery time of 4 minutes versus the 23 minutes of those who hadn't tested.

Step 6 - Final operational report (days T+1 to T+3)

Within 72 hours of the event the junior produces a final operational report of 1-2 pages as input for the senior's post-mortem. It contains: numerical KPIs (attendees registered vs present, actual costs vs budget, percentage variance), three things that worked (with rationale), three things that didn't work (with identified cause), any action items for the next similar event (with suggested owner and priority).

The report is not the complete post-mortem - that's the senior's job and covers more aspects, see L1-C5 post-event survey. The junior's operational report is the raw-data foundation on which the senior builds the post-mortem. The writing rule: facts before interpretations. If the budget variance is +12% versus the quote, the report says variance +12%, main cause: additional venue cost for extended hours. It does not say we overran the budget because the venue is expensive (rhetorical interpretation).

A useful practice is the fact-finding archive: together with the report, the junior archives in a folder all the raw documents (signed invoices, vendor confirmation emails, screenshots of the post-event run-of-show, photos of the venue setup, any audio of the sessions). This archive is precious for the senior doing the post-mortem (they can consult the evidence directly) and for the juniors who will manage similar future events (they inherit a real baseline instead of reconstructing from memory).

On the final report, a less obvious sub-practice is the diff vs standard checklist: if the junior added items specific to their event (the 5-10 adaptation items from step 2), the final report declares which of those additions proved useful and which didn't. Example: the item 'check guest wifi 100 simultaneous connections' that I added proved fundamental (5 attendees reported problems in the first 2 hours before the solution); the item 'check company banner is ironed' turned out to be useless (the banners were shipped by the vendor already ironed). These feedback observations become input for the senior who decides whether to add/remove those items from the team's standard checklist at the next iteration. It's the way a junior contributes to the team's shared asset without inflating it arbitrarily.

A useful by-product of the final report is the KPI vs target matrix in compact format: three columns (KPI, target from brief, actual measured), 3-5 rows for the primary KPIs declared in the brief. This visual format makes the event's performance immediately readable, and allows the senior to build a portfolio dashboard if they manage multiple events per year. For the junior, the discipline of filling in the KPI matrix teaches you to always keep your eye on the declared targets, not just on operational execution. It's a first step toward the mid-level mindset that measures to build a plan, not to justify a final tally.

Real case: Atlassian Retrospective Play, Stripe Sessions logistics, Scalapay all-hands

Three case studies that cover three dimensions of junior project & risk operations: the structured Atlassian retrospective as a learning tool, the maximalist logistics management of Stripe Sessions, the adaptation to the Italian scale-up context of Scalapay.

Atlassian covers the dimension of the structured learning loop. Stripe Sessions covers the dimension of maximalist logistics for large events.

For the IT scale-up context the useful reference is an Italian fintech that has publicly recounted its own internal events.

Three additional sources: PMI Learning Library has articles on applied project management; Cvent Blog has the Event Operations category with templates; MIT Sloan Operations Management has academic articles applicable to operational contexts.

Anti-patterns: the three most frequent mistakes on checklists and risks

The junior antipatterns in project & risk operations are distinct from those in stakeholder management: here they concern operational discipline, not psychological dynamics.

Templates, checklists and next steps

The most useful template for the junior just starting out is the 1-pager brief, because it's the foundation from which the operational checklist is derived. The brief defines objectives, audience, scope, budget, risks - the checklist translates those requirements into actions.

The personal growth path along the Project & Risk Operations axis (C3) goes from applying-the-standard-checklist at L1 level to adapting-the-checklist-to-the-available-budget at L2 level. The critical transition is the moment when you start to recognize which items can be compressed / skipped in events with a budget < €10k and which are inviolable even at that scale. See the next step L2-C3. On the other L1 skills, project ops connects to: L1-C1 single-BU ownership, L1-C2 direct-team stakeholders, L1-C4 internal communications, L1-C5 post-event survey. The cornerstone contains the extended framework applied to all levels.

Three readings for the project & risk operations skill. Crystal Clear by Alistair Cockburn (Addison-Wesley 2004) is the most useful technical project management book for the junior - it makes explicit why small projects require different practices from large ones. The Checklist Manifesto by Atul Gawande (Metropolitan Books 2009) is the definitive popular book on checklists applied to complex contexts (medicine, aviation, construction, and events); anyone who thinks checklists are trivial should read it. The Atlassian Team Playbook is free online and has plays specific to each phase of the project. For the Italian context, the LinkedIn posts of the people ops teams at Scalapay, Bending Spoons and Musixmatch are a continuous source of real operational practices.

What I learned writing this