Project coordination turns an agreed outcome into visible tasks, owners, dependencies, and decisions. Learn to plan a small piece of work, track progress honestly, and raise blockers with enough context for someone to act. This roadmap coordinates a fictional community reading event. The deliverable is a practical project pack and a simulated status cycle, not a claim that a task board alone guarantees delivery.
Define the outcome and the boundary
The fictional team must prepare a two-hour reading event for twenty guests. The agreed deliverables are a confirmed room, a programme, a participant-information page, and a checked event setup. Fundraising and a permanent membership system are outside scope. Write what completion means for each deliverable so “done” is not merely someone saying they worked on it.
Atlassian’s project-planning guidance discusses defining scope, tasks, resources, and schedules Source 1. Use those ideas at a scale appropriate to this exercise. Name the person who can approve changes to the event plan. A coordinator keeps work visible, but should not silently expand the scope or commit resources beyond their authority.
Break work into owned tasks and dependencies
Create tasks for room enquiry, room confirmation, programme draft, programme approval, information-page publication, equipment check, and final readiness review. Give each a single accountable owner and a due date. Several people may contribute, but an owner clarifies who will provide the next update and resolve uncertainty.
Record dependencies. The information page cannot honestly publish a confirmed venue before room confirmation. The programme can be drafted in parallel, but its final version may depend on speaker availability. Do not make every task sequential simply because a list is displayed from top to bottom. Identify which work can proceed while a dependency is unresolved.
Use a small board with planned, in progress, blocked, and done states. Define done with evidence, such as a confirmation email reference or an approved programme file. The Scrum Guide discusses transparency and inspection within its specific framework Source 2. A simple board can support those habits without claiming the team is practising Scrum merely because it uses columns.
Run a fictional status cycle
Assume room confirmation is due on Tuesday but remains unanswered on Wednesday. The programme draft is complete, and the equipment list is in progress. Write a status note: the venue decision is blocked, the public information page depends on it, and the owner will contact the venue by noon. Ask the authorised decision-maker whether to hold a backup room if no answer arrives by the agreed cutoff.
Distinguish a risk from an issue. A possible late venue response is a risk before it happens; the missed confirmation deadline is now an issue. Record the impact, owner, next action, and review time. Avoid a red status label with no explanation, because it tells the reader that something is wrong without helping them decide what to do.
If the backup room requires a different setup, update the equipment task and the information-page draft. Keep a decision log showing what changed and why. GOV.UK’s cross-organisational collaboration guidance highlights the need to work across teams in a wider journey Source 3. Here, venue and programme owners need the same current information rather than separate contradictory plans.
Check readiness and close the loop
Before the fictional event, run a readiness review against the deliverables: room confirmed, programme approved, participant details accurate, equipment tested, and responsibilities understood. A task marked done without evidence should be checked. Record any accepted limitation and who accepted it; do not hide unresolved work to make the board appear green.
After the exercise, write a short retrospective: the venue dependency was identified early, the escalation cutoff was useful, and the information-page task should have included a pre-publication fact check. Choose one change to the next project’s planning process. A retrospective should produce a practical improvement rather than a blame list.
Submit the brief, task board, dependency sketch, risk and issue log, two status updates, decision log, and closeout note. Keep names and dates fictional. The skill demonstrated is reliable coordination: people know what is expected, what is blocked, who owns the next action, and what evidence supports completion.
- AgreeDefine outcome, scope, and decision authority.
- PlanAssign tasks, owners, dates, and dependencies.
- TrackUpdate evidence, blockers, and next actions.
- CloseReview readiness and capture one improvement.
| Checkpoint | What to produce | How to review it |
|---|---|---|
| Scope | Room, programme, information page, setup | Out-of-scope work is explicit |
| Dependency | Venue confirmation before public details | Drafting can continue without false publication |
| Blocker | Room response overdue | Owner, impact and next action recorded |
| Completion | Evidence for each deliverable | Green status does not replace review |
- Risk
- The venue might not confirm in time.
- Issue
- The agreed confirmation deadline has passed.
- Decision
- An authorised owner chooses the backup-room action.
Common questions
Is a coordinator responsible for doing every task?
No. The coordinator helps organise and communicate the work, while task owners remain responsible for their deliverables. Clarify roles at the start. Taking over every delayed task can hide capacity problems and create a new bottleneck. Make ownership, dependencies, and escalation routes visible so the team can act appropriately.
How detailed should the task list be?
Break work down until each task has a clear owner, outcome, and manageable update. Avoid tiny entries that create more administration than value. “Prepare the event” is too broad, while every email keystroke is too detailed. Use the level that helps the team detect delay and understand what completion requires.
What is the difference between a dependency and a due date?
A due date states when work is expected; a dependency states what must be available or completed before another activity can proceed. Both matter. The information page may have a Friday deadline, but it still needs confirmed venue details. Ignoring that relationship can produce a schedule that looks complete while being impossible to follow.
How should I report a blocker?
State the blocked task, the cause, the impact, the owner, and the next action or decision needed. Include a relevant time for follow-up. Avoid simply writing “waiting” or assigning a red colour. A useful update lets the reader understand whether they need to intervene and what information would unblock the work.
Can a task be partly done?
You can describe progress, but distinguish it from completion. A programme draft may be written while approval is still pending. Either show those as separate tasks or make the remaining acceptance step explicit. Marking the whole deliverable done too early hides work and can mislead other tasks that depend on it.
When should a risk become an issue?
When the uncertain event has actually occurred and is affecting or threatening the work in a concrete way. Before the venue deadline, a late response is a risk; after the missed deadline, it is an issue to manage. Keep the owner and response current rather than leaving both records unchanged indefinitely.
Do I need specialist project-management software?
A shared document, spreadsheet, or simple board can support this small exercise. Choose a tool the team will update and understand. The important elements are clear outcomes, ownership, dependencies, evidence, and decisions. Sophisticated software cannot compensate for vague tasks or a status process that nobody trusts.
What should the final coordination case study show?
Show the project brief, plan, a meaningful blocker, the status communication, the decision made, and the closeout review. Label simulated events clearly. Explain how your coordination changed the team’s next action. A screenshot of a fully green board is less informative than a short account of how an actual uncertainty was handled.
Continue your learning
Requirements Gathering Roadmap: Turn Stakeholder Needs into Testable Statements. Process Mapping Roadmap: Document a Workflow and Find Improvement Opportunities.
Sources and further reading
- Atlassian: project planning — Scope, tasks, resources and schedules in planning.
- Scrum Guide — Transparency and inspection in the Scrum framework.
- GOV.UK: cross-team work — Collaboration when a journey crosses team boundaries.
Skills & Learning Desk
MP Job Hub’s organisational byline for sequenced practice, course evaluation and useful learning habits.
Skill roadmaps · Learning resources · Practice projects
View profile →Read our research process or request a correction.
