Coordinate a Website Launch in Trello

Create a Trello board to coordinate a website launch, risks, scope, and status.

Introduction

30 Second Summary

A website launch can look calm until one delayed approval makes every later date questionable. A coordinator earns trust by making that pressure visible before it becomes a missed deadline.

In this project, you will build a portfolio-ready Trello board that coordinates a simulated small-business website launch. You will turn a project brief into a visible plan that tracks delivery through launch readiness.

What You'll Build

Picture opening your finished board to see the whole website launch move from its brief through delivery pressure to a recorded decision.

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

A dated launch plan with clear task ownership across a visible workflow.
A documented blocker recovery plan that protects the launch date. It records scope control for the late request.
A stakeholder status update that turns the final board state into an interview-ready case study.
Secret Mission: Issue an evidence-based go/no-go recommendation from a launch criteria review.

Are there any prerequisites?

You only need a Trello account plus a web browser. No project coordination experience is required.

Before We Start

Before the hands-on work begins, this is your moment to commit to the launch you are coordinating. You will also connect that work to the project coordination skills you want to demonstrate.

Set Up the Launch Board

Every launch task needs one reliable place to show its current state. Trello gives this simulated launch a board where future work stays visible.

A fixed private board creates one source of truth before the project work begins. This shared structure keeps later tasks, blockers, and decisions consistent.

In this step, get ready to:

Create a private launch board in your selected Trello Workspace.
Add six empty workflow lists in the required order.
Reopen the board from the Trello home page to confirm its final state.

Create the private launch board

A Trello board can contain multiple lists. Each list will later hold cards at one stage of the launch.

In the Trello browser tab from earlier, select Create from the top navigation bar.
Select Create Board.
Enter Website Launch Coordination in the board title field.
Choose your Trello Workspace from the Workspace menu.
Set the board visibility to Private.
Finish creating the board by selecting Create.

You'll see Website Launch Coordination open as a private board in your selected Workspace.

The foundation is in place: your private board now gives the simulated launch one source of truth.

Board Not Opening as Private?

Confirm that the board title field contains Website Launch Coordination.
Confirm that you selected a Workspace before creating the board.
Change the visibility from Workspace visible to Private.

Help me fix my Trello board creation settings.

Build the empty workflow

Lists divide the board into visible stages. Their fixed left-to-right order gives each future card an unambiguous project status.

Select Add another list at the right edge of the board.
Type Project Brief into the list name field.
Press Enter to create the list.

You'll see an empty Project Brief list at the left side of the board.

Create To Do to the right of Project Brief with Add another list.
Create In Progress to the right of To Do with the same list control.
Create Blocked to the right of In Progress with the same list control.
Create Done to the right of Blocked with the same list control.
Create Reports & Decisions to the right of Done with the same list control.

Your board now shows the full route from the project brief to final reports. All six lists are empty and ready for the launch plan.

Reopen and verify the board

A reopen check confirms that the board is available from your Trello home page. It also catches a misplaced list before cards make the workflow harder to rearrange.

Select the Trello logo in the top-left corner to return to the Trello home page.
Locate Website Launch Coordination in your selected Workspace.

Before you reopen the board, what title and left-to-right list order do you expect to see?

Select Website Launch Coordination to reopen the board.
Scan the lists from left to right.

You'll see the board title Website Launch Coordination. The list order reads Project Brief, To Do, In Progress, Blocked, Done, and Reports & Decisions.

Each list is empty. You now have a clean launch workflow that later steps can fill with evidence.

Board Missing or Out of Order?

Confirm that you reopened the board named Website Launch Coordination from your selected Workspace.
Drag any misplaced list until the required left-to-right order is restored.
Remove any accidental cards so every list is empty.

Help me restore my Trello launch board.

✔️ Awesome, I've got everything!

Your private launch board is open from the Trello home page. Its six empty lists now provide the workflow for the rest of the project.

ⓧ I'd like to double check the final state

Confirm that the private board is named Website Launch Coordination.
Confirm that the board belongs to your selected Trello Workspace.
Confirm that Project Brief is the first list.
Confirm that To Do, In Progress, Blocked, and Done follow in that order.
Confirm that Reports & Decisions is the final list.
Confirm that all six lists are empty.

Your source of truth is ready. Next, you'll turn this empty workflow into a dated launch plan with visible ownership.

Build the First Launch Plan

Your Trello board now gives the launch a shared workflow. Its empty lists are ready to hold the plan.

A blank workflow cannot prove coordination. The project brief makes the launch scope visible.

Task ownership shows who is accountable. Due dates turn the cards into a launch sequence.

In this step, get ready to:

Create a brief that defines the launch.
Add seven cards that represent the launch work.
Turn every task into a dated assignment.

Create the project brief

A project brief gives every task the same destination. It also records the boundaries that protect the launch from extra work.

In Project Brief, select Add a card.
Type Project Brief: Website Launch.
Press Enter to create the card.
Select Project Brief: Website Launch to open it.
Select the card description area to start editing.
Enter Goal: Launch a small-business website on 2026-09-13. on the first line.

The card now has a fixed target date for the simulated launch.

Enter Success criteria: Approved homepage copy. A working tested contact form. Mobile-ready launch quality. on a new line.
Review the goal plus the three success criteria.

You should see one launch goal followed by three observable measures of success.

Enter In scope: Homepage. Contact form. Mobile QA. Launch coordination. on a new line.
Enter Out of scope: Additional pages. Post-launch enhancements. on a new line.
Review the two scope lines.

The description now separates launch work from additional pages or post-launch enhancements.

Enter Simulated stakeholders: Client. Content Approver. Website Builder. Project Coordinator. on a new line.
Use the confirmation control below the description editor to save your changes.
Use the close control in the card header to return to the board view.

That first artifact is in place. Anyone opening the card can now see the launch target plus its boundaries.

Brief details not staying?

Reopen Project Brief: Website Launch.
Check whether the description editor is still active.
Use the editor confirmation control before closing the card.

Help me check why my Trello project brief description is not staying on the card.

Add the launch tasks

Task cards turn the brief into work that can move through the board. Their order follows the path from planning to launch.

In To Do, select Add a card.
Type Approve sitemap.
Press Enter to create the card.
Type Draft homepage copy.
Press Enter to create the card.

You should see two cards in To Do.

Type Approve homepage copy.
Press Enter to create the card.
Type Build homepage.
Press Enter to create the card.

The list should now show four cards. Build homepage sits below its copy approval.

Type Test contact form.
Press Enter to create the card.
Type Run mobile QA.
Press Enter to create the card.

You should now see six cards in the work queue.

Type Launch website.
Press Enter to create the card.
Close the card composer.

You have turned the brief into a visible work queue. Seven launch tasks now sit in To Do.

Card entry field closed?

Select Add a card again in To Do. Continue with the next missing card title.

Help me compare my Trello To Do list with the seven required launch tasks.

Assign and schedule each task

An owner makes responsibility visible on every card. A date shows when that responsibility must produce a result.

Select Approve sitemap to open it.
Select Add below the card title.
Select Members.
Select your own member entry.

Your avatar should now appear on the card. This confirms that you own the task.

Select Dates.
Set the due date to 2026-09-07.
Confirm the date in the date panel.
Return to the board view using the card header's close control.

The Approve sitemap card should show your avatar plus a due-date badge.

Use This Launch Sequence

Draft homepage copy is due on 2026-09-08.
Approve homepage copy is due on 2026-09-09.
Build homepage is due on 2026-09-10.
Test contact form is due on 2026-09-11.
Run mobile QA is due on 2026-09-12.
Launch website is due on 2026-09-13.

Open the next card named in the launch sequence.
Reuse the member-assignment routine to assign yourself.
Set the matching due date using Dates.
Return to the board view after completing the card.
Confirm your avatar is visible on the card.
Confirm its due-date badge is visible.
Repeat this routine until all six remaining cards are complete.

Missing an Avatar or Date?

Reopen any card that does not show your avatar.
Reapply the member assignment from the Members control.
Reopen any card that does not show a due-date badge.
Reapply the matching date from the launch sequence.

Help me find which Trello task card is missing its owner or due date.

Before the final scan, which task should carry the earliest due date? Which task should carry the launch date?

Return to the board view.
Scan Project Brief to confirm that it contains one card.
Scan To Do to confirm that it contains seven cards.

Project Brief contains Project Brief: Website Launch.

To Do contains seven task cards. Every task shows your avatar plus a due-date badge.

Check the Date Sequence

Approve sitemap has the date 2026-09-07.
Draft homepage copy has the date 2026-09-08.
Approve homepage copy has the date 2026-09-09.
Build homepage has the date 2026-09-10.
Test contact form has the date 2026-09-11.
Run mobile QA has the date 2026-09-12.
Launch website has the date 2026-09-13.

✔️ Awesome, I've got everything!

Your first launch plan is ready. The brief defines the target while seven owned tasks show the path to launch.

ⓧ I'd like to double check the final state

Check the board and brief

Confirm that Website Launch Coordination remains private.
Confirm the lists remain ordered as Project Brief, To Do, In Progress, Blocked, Done, and Reports & Decisions.
Confirm that Project Brief: Website Launch records the goal plus the launch date of 2026-09-13.
Confirm that the brief records three success criteria.
Confirm that the brief records the in-scope work plus the out-of-scope work.
Confirm that the brief records Client, Content Approver, Website Builder, and Project Coordinator as simulated stakeholders.

Check the task schedule

Confirm that Approve sitemap is assigned to you with a due date of 2026-09-07.
Confirm that Draft homepage copy is assigned to you with a due date of 2026-09-08.
Confirm that Approve homepage copy is assigned to you with a due date of 2026-09-09.
Confirm that Build homepage is assigned to you with a due date of 2026-09-10.
Confirm that Test contact form is assigned to you with a due date of 2026-09-11.
Confirm that Run mobile QA is assigned to you with a due date of 2026-09-12.
Confirm that Launch website is assigned to you with a due date of 2026-09-13.

Your launch now has a visible plan from brief to delivery. Next, you'll test whether that plan still holds when the project changes.

Expose the Schedule Risk

Your Trello board now holds a dated launch plan with clear ownership.

This step turns that baseline into a schedule risk test. Card movement will show how the current state affects the plan.

The first plan assumes work will proceed smoothly. A delayed approval exposes whether the downstream dates still reflect reality.

A late request tests whether the agreed boundaries can hold. Together these pressures make the original schedule look unreliable.

In this step, get ready to:

Place the existing work in its current workflow lists.
Document the delayed homepage-copy approval as blocked.
Add a late Services page request without revising the schedule.

Move work to its current status

Workflow lists turn task updates into a visible project story. Completed preparation belongs in Done before the active build moves forward.

Drag Approve sitemap from To Do to Done.
Drag Draft homepage copy from To Do to Done.

You should now see both completed cards in Done with their original due-date badges.

Drag Build homepage from To Do to In Progress.

That first status update is in place. Your board now separates finished preparation from the homepage build that has started.

Record the delayed approval

Homepage copy approval is a dependency for the build. Moving the approval card makes the interruption visible to anyone scanning the workflow.

Drag Approve homepage copy from To Do to Blocked.

You should see Approve homepage copy under Blocked with its existing 2026-09-09 due date.

Select Approve homepage copy in Blocked.
Enter Issue: Client approval is delayed by one day. in the card description.

You should see the issue recorded on the card. The due date should still show 2026-09-09.

Before you return to the board, do you think the one-day delay is reflected in the downstream dates?

Return to the board view.
Compare the due dates on Approve homepage copy, Build homepage, Run mobile QA, and Launch website.

The Schedule Stays Unchanged

Approve homepage copy still shows 2026-09-09.
Build homepage still shows 2026-09-10.
Run mobile QA still shows 2026-09-12.
Launch website still shows 2026-09-13.

The board still presents the downstream schedule as viable even though required approval is delayed. This mismatch is the risk you needed to expose.

Add the late scope request

The project brief keeps additional pages outside the agreed scope. A Services page request adds work on the same day as launch.

Select Add a card under To Do.
Type Change request: Add a Services page before launch as the card name.
Press Enter to create the card.

You should see the new change-request card in To Do.

Select Change request: Add a Services page before launch.
Select Add below the card title.
Select Members.
Select your profile to assign yourself.
Select Dates.
Select 2026-09-13 as the due date.

Before you scan the full board, do you think the schedule can absorb both changes without moving another date?

Return to the board view.
Scan the workflow from Project Brief through Reports & Decisions.
Check the avatar and due-date badge on the Services page request.
Compare the blocked approval with the downstream build and launch cards.

You should see Approve sitemap with Draft homepage copy in Done. You should see Build homepage in In Progress.

You should see Approve homepage copy in Blocked with its 2026-09-09 date. Its description should record the one-day delay.

You should see the Services page request in To Do with your avatar and a 2026-09-13 due date. The downstream task dates should remain unchanged.

What Does the Board Reveal?

The delayed approval has no downstream date response. The Services page request lands on launch day without any schedule allowance.

Your original plan now visibly conflicts with the current project state. The board provides the evidence needed for a recovery decision.

You have made the schedule risk visible instead of hiding it. Next, you will categorize the risks and record a recovery decision.

Control the Blocker and Scope Change

The delayed copy approval has exposed a schedule risk on your Trello board. The Services page request has also pushed extra work into the launch window.

The plan now needs visible risk control. A recorded change control decision will protect the 2026-09-13 launch date.

In this step, get ready to:

Categorize the schedule risk with named labels.
Build a recovery checklist for the delayed approval.
Record a Phase 2 scope decision that protects the launch date.

Categorize the blocker and change request

Labels make each risk signal visible from the board view. Three named labels will distinguish the blocker from the affected QA task and the scope request.

Select the Approve homepage copy card in Blocked.
Select Add below the card title.
Select Labels.
Create a label named Blocked using an unused color.
Select Blocked to apply it to the card.

The approval card now carries a visible Blocked label.

Create a label named Risk using a different unused color.
Select Risk to apply it to the card.
Return to the board view.

You should see both named labels on Approve homepage copy in the Blocked list.

Select the Run mobile QA card in To Do.
Select Add below the card title.
Select Labels.
Select Risk to apply the existing label.
Return to the board view.

The Run mobile QA card now carries the Risk label. This connects the delayed approval to its downstream impact.

Select the Change request: Add a Services page before launch card in To Do.
Select Add below the card title.
Select Labels.
Create a label named Change Request using an unused color.
Select Change Request to apply it to the card.
Return to the board view.

That is your first control win. The board now separates the schedule risk from the scope request at a glance.

Missing a label from a card?

Open the affected card again. Check that the required label is selected in the Labels menu.

Confirm that Risk appears on both the approval card and the QA card.

Help me check the named labels on my Trello launch board.

Build the recovery plan

A recovery plan converts a blocked card into a response that someone can follow. Each checklist item gives the delayed approval a concrete next action.

Select the Approve homepage copy card in Blocked.
Select Add below the card title.
Select Checklist.
Enter Recovery Plan as the checklist title.
Select Add to create the checklist.

You should see an empty Recovery Plan checklist on the open card.

Why use a recovery checklist?

The checklist keeps the response beside the blocker that triggered it. Anyone reviewing the card can see how the team plans to recover.

Add request minimum viable copy as the first checklist item.
Add set a response deadline as the second checklist item.

The checklist should now show two unchecked recovery actions.

Add notify the builder as the third checklist item.
Add reserve the final QA window as the fourth checklist item.

The Recovery Plan now shows four unchecked actions. The blocker has a visible path forward.

Checklist items missing?

Confirm that all four items sit inside the Recovery Plan checklist on Approve homepage copy.

Help me compare my recovery checklist with the required launch actions.

Protect the launch date

Replanning gives the delayed approval a realistic response window. A written decision prevents the late request from slipping back into the current launch scope.

Select Dates on the open Approve homepage copy card.
Change the due date to 2026-09-10.
Return to the board view.

The approval card remains in Blocked. Its date badge now shows 2026-09-10.

Select the Run mobile QA card in To Do.
Select Dates.
Confirm that its due date is 2026-09-12.
Return to the board view.

The QA task already sits on the final pre-launch day. Its Risk label now makes that narrow window visible.

Select the Change request: Add a Services page before launch card in To Do.
Select the card description.
Enter Decision: Defer the Services page to Phase 2 to protect the launch date. in the description.
Finish the description edit using the control below the text box.

The card now records why the Services page leaves the current launch scope.

Return to the board view.
Drag Change request: Add a Services page before launch from To Do to Reports & Decisions.

The change request now sits with the board's formal decisions. Its original 2026-09-13 due date remains visible.

Select the moved change-request card in Reports & Decisions.
Confirm that its description contains the Phase 2 decision.
Return to the board view.

Before your final scan, which details should prove that the original launch date is protected?

Confirm that Approve homepage copy remains in Blocked with the Blocked and Risk labels.
Confirm that the approval date reads 2026-09-10.
Confirm that Run mobile QA carries the Risk label.
Confirm that the QA date reads 2026-09-12.
Confirm that the Services page request sits in Reports & Decisions with the Change Request label.

Approve homepage copy remains visibly blocked with two named labels. Its revised date gives the approval one additional day.

Run mobile QA remains scheduled for 2026-09-12 with a visible risk marker. The final QA window stays attached to the launch plan.

The Services page request now sits in Reports & Decisions with its scope label. Its description records the Phase 2 decision.

Board state does not match?

Check that each label was applied to the intended card. Confirm that the approval date update was completed before leaving the card.

If the change request remains in To Do, drag it into Reports & Decisions.

Help me compare my Trello board with the required blocker and scope-control state.

Your board now shows how you controlled the risk without hiding the trade-off. Next, you will turn this repaired plan into a stakeholder update and portfolio story.

Publish the Status and Portfolio Story

You have done the hard coordination work. Your Trello board now shows a controlled blocker plus a deferred scope request.

A repaired plan only helps when stakeholders can understand the change. Your portfolio also needs evidence that explains your decisions.

This step turns the board into two readable records. One serves stakeholders. The other serves your portfolio.

In this step, get ready to:

Publish an Amber stakeholder status update.
Write a portfolio case study supported by visible board evidence.
Align every task card with the two new reports.

Publish the stakeholder update

A stakeholder status update turns the board into a concise delivery report. It names the current status before summarizing the evidence behind it.

What the update needs to say

Overall status is Amber.
Completed work is Approve sitemap plus Draft homepage copy.
Work in progress is Build homepage.
The blocker is delayed client approval of homepage copy.
The approved scope decision defers the Services page to Phase 2.
The next action is securing minimum viable copy by the response deadline.
The required stakeholder help is client approval of homepage copy.

Select Add a card at the bottom of Reports & Decisions.
Enter Status Update 01: Website Launch as the card name.
Press Enter to create the card.

You can now see Status Update 01: Website Launch in Reports & Decisions.

Select Status Update 01: Website Launch to open it.
Enter the seven statements from the summary above in the card description.
Return to the board view after Trello records the description.

Why Amber fits this launch

Amber communicates that delivery can continue under active risk. The delayed homepage-copy approval still needs client action.

The status keeps attention on the blocker without discarding the protected launch date.

Reopen Status Update 01: Website Launch from Reports & Decisions.
Compare every statement with the visible cards on the board.

You should see an Amber update that names the completed work. It also identifies the active build, delayed approval, Phase 2 decision, next action, and required client help.

Does the status update contradict the board?

Check that Build homepage remains in In Progress.
Check that Approve homepage copy remains in Blocked.
Check that the Services page decision still records its Phase 2 deferral.

Help me reconcile my status update with my Trello board.

Write the portfolio case study

A portfolio case study connects the launch problem to your coordination decisions. Visible evidence makes the story credible as a project simulation.

How to structure the case study

The Challenge section explains how delayed homepage-copy approval exposed schedule risk.
The Actions section explains how labels plus the Recovery Plan checklist made the response visible.
The Actions section also records the Services page deferral to Phase 2.
The Evidence section points to the blocker, risk response, and recorded scope decision on the board.
The Outcome section states that the original 2026-09-13 launch date remains protected.

Return to Reports & Decisions on the board.
Select Add a card.
Enter Portfolio Case Study as the card name.
Press Enter to create the card.

Your second report card is now visible beside the scope decision plus the stakeholder update.

Select Portfolio Case Study to open it.
Enter the four headings plus the supporting points from the structure above in the card description.
Describe the work as a project simulation in the case study.
Return to the board view after Trello records the description.

Reopen Portfolio Case Study from Reports & Decisions.
Read each section against the visible board evidence.

The case study should connect the delayed approval to your labels plus recovery checklist. It should also connect the Phase 2 decision to the protected 2026-09-13 launch date.

Keep the evidence honest

Present this board as a project simulation. The case study demonstrates your coordination decisions without implying that the scenario was paid client work.

Does the case study feel disconnected?

Name the delayed approval in Challenge.
Reference the labels plus recovery checklist in Actions.
Connect the visible board state to launch-date protection in Evidence plus Outcome.

Help me strengthen my simulated project coordination case study.

Align the board with the reports

A credible report must match the source board. This review removes contradictions before you use the project as portfolio evidence.

What each list should show

The Done list contains Approve sitemap plus Draft homepage copy.
The In Progress list contains Build homepage.
The Blocked list contains Approve homepage copy.
The To Do list contains Test contact form, Run mobile QA, plus Launch website.
The Reports & Decisions list contains the Services page decision, Status Update 01: Website Launch, plus Portfolio Case Study.

Review every launch task card against the list reference above.
Move each incorrectly placed card to the matching list.

Check the dates and risk records

Approve sitemap is due 2026-09-07.
Draft homepage copy is due 2026-09-08.
Build homepage is due 2026-09-10.
Approve homepage copy is due 2026-09-10 with Blocked plus Risk labels.
Test contact form is due 2026-09-11.
Run mobile QA is due 2026-09-12 with the Risk label.
Launch website is due 2026-09-13.
Change request: Add a Services page before launch is due 2026-09-13 with the Change Request label.

Review every launch task card against the date reference above.
Confirm that your avatar remains assigned to each launch task card.
Correct any mismatched date.
Correct any mismatched label.
Correct any description that contradicts the status update.

Before the final review, do you expect the two new reports to agree with every visible card?

Return to the full board view.
Scan the six lists from left to right.
Confirm that Reports & Decisions contains the scope decision plus both new report cards.
Open Status Update 01: Website Launch.
Compare its description with the visible card states.
Return to Reports & Decisions.
Open Portfolio Case Study.
Compare its four sections with the visible risk response plus scope decision.

You should see the deferred Services page decision, Status Update 01: Website Launch, plus Portfolio Case Study in Reports & Decisions.

Strong finish. Your board now explains what changed, why you responded, and how the original launch date remains protected.

Secret mission

Run a Go/No-Go Review

Assess the visible board evidence against six launch criteria. Issue a CONDITIONAL GO recommendation with an explicit next action for every open criterion.

Clean Up Your Resources

Choose whether to keep your private Trello board active, leave it unchanged for later, or close it. This project costs $0 on Trello Free.

Resources you used:

A private Trello board named Website Launch Coordination containing the complete launch coordination record.

Keep everything running

No action is needed. Choose this if you want to continue using the board as an active coordination record.

Keep Website Launch Coordination private in its current Workspace.
Continue updating card statuses as the simulated launch progresses.
Retain the Go/No-Go Review as evidence of your launch recommendation.

Pause - I'll come back to this later

Leave the private board unchanged if you want to rehearse the scenario or improve the case study later. Trello keeps the board available without requiring any paid features.

Keep every list, card, date, label, checklist, status update, and decision record unchanged.
Close the browser tab when you finish.
Return to Website Launch Coordination from your Trello home page when you are ready to continue.

Delete - I don't want to use this again

Closing the board can feel final. Trello hides a closed board and prevents edits, but the board is not deleted and can be reopened.

Confirm that you are a board admin.
Open Menu on Website Launch Coordination.
Select Close board.
Confirm that Website Launch Coordination is hidden from your active boards.

Nice Work!

Congratulations! You've built a portfolio-ready Trello board for a simulated website launch. Its visible evidence supports every coordination decision from initial scope to a conditional launch recommendation.

What you learned:

Created a visible launch workflow across six lists. Defined the project scope in a detailed brief. Assigned task ownership. Sequenced the launch with due dates.
Exposed schedule risk through a delayed approval. Documented a Recovery Plan for the blocker. Applied change control by deferring the Services page to Phase 2.
Published an Amber stakeholder update that matches the board. Built a Portfolio Case Study that explains the challenge. Recorded the actions. Connected each decision to visible evidence.
Secret Mission: Assessed launch readiness against six criteria. Issued a CONDITIONAL GO recommendation using current board evidence. Added a next action for every open criterion.

Ready to quiz yourself?