Two sessions, one week apart. Hands-on in the platform from day one.
By the end of this session, participants will:
Participants will be in the system doing things alongside the facilitator. Come with Jira open and ready to follow along.
Welcome the room and introduce facilitators. Set the tone - this is a pilot, honest input is the goal.
Where this came from: 12 interviews, 5 workshops, 4 alliances, 2 operators. The problem was consistent - no shared source of truth, too much coordination by email.
State today's outcomes clearly: by the end of this hour they will have seen the platform, know the six rules, and know exactly what to do from tomorrow.
Open Jira and jump straight in. Participants follow along in their own Jira as the facilitator walks through each step.
Quick orientation
Show the board - columns are workflow stages, cards move left to right.
Point to: the board, the For You page, and search. That is all they need right now.
Name the structure: Epics contain Tasks, Tasks contain Sub-tasks.
Scenario walkthrough Scenario to be confirmed
A brief has landed. Monday morning. Works near Tottenham.
Set up the Epic first. In List view, create a new item, select Epic, and name it — e.g. "Tottenham Works - Community Update." This is the container everything else will sit under.
Create the task under the Community Update epic. Fill in the required fields.
Move to In Progress. Add a sub-task for internal review and assign it.
Sub-task complete. Move the parent task to External Review. All contact with the external party is logged as comments - the task stays with the internal owner.
Approval comes back. Move to Done. Show the closed task - date, assignee, comment thread all intact.
The platform only works if everyone uses it the same way. Consistency is what makes the board reliable - for your team, for other alliances, and for anyone who needs to find information six months from now.
Jira is the record. If it is not logged, it did not happen. Approvals, decisions, and correspondence all live in the task - not in email.
Every task has an owner. Unassigned tasks are invisible. If no one owns it, no one is accountable for it.
Stay current. Update your tasks within 5 days. Stale tasks create noise for everyone at the weekly check-in.
Use the fields. Dropdowns exist for a reason. Consistent data is what makes the board searchable and reports accurate.
Comments are the paper trail. Every decision, approval, and external contact gets logged as a comment on the task. The task is the file.
The board is the meeting. The weekly check-in runs from the board. If it is not on the board, it will not be discussed.
Show a quick board demo: apply an alliance filter, point to a stale item. "This is what the weekly check-in exists to resolve."
The expectation from today
From today, participants are expected to be using Jira for their real work. Not when they feel ready - now.
The ask is simple: get one project into the platform. It does not need to be perfect. Mistakes are expected and that is fine - the goal is to start using it, not to use it perfectly.
One Source is the self-guided training resource - everything they just saw, broken into short modules. It is a living resource and will be updated as real use surfaces gaps.
Opposite is available short term for questions about setup and workflows. IT will be the long-term support contact once handover is complete.
Feedback from the room
Go around the room - one observation each. What made sense, what raised a question.
Note anything that signals a workflow conflict or a content gap. These feed directly into Session 2.
Three resources are available to support participants as they start using Jira for real work. Note anything that does not match how you actually work — that is what Session 2 is for.
Self-guided training site covering the platform and all common workflows in short modules. Go through L1 and L2 at your own pace.
A one-page guide covering the six golden rules, statuses, hierarchy, and step-by-step how-tos. Keep it open while you work.
Common questions are answered within each module in One Source. If something is not covered, raise it at the weekly check-in or bring it to Session 2.
Participants have worked through One Source independently. This session is specifically about the training content - does it reflect how they actually work, what does not apply to their workflow, and what needs to change before go-live.
Open debrief of the self-guided week with One Source. Two questions to the room.
Ask: "Did you get through the modules?" - gauge how much time people invested and whether the ask was reasonable.
Ask: "One thing that felt accurate to how you work, and one thing that did not." Go around the room and note themes.
Go through the One Source modules together as a group. Focus on the scenarios in L2 - these are the most likely to surface workflow conflicts because they model specific processes.
Open each L2 module in turn: Community Update, Works Notice, Engage Vic. For each one, ask: "Does this match how your team actually handles this type of work?"
Where someone says no - probe: what is different? Is it the review chain, the status, who owns the task, something else?
Note each conflict clearly: which module, which step, what the real process is. This is the content update list.
Triage the list of workflow conflicts captured in the previous segment. Keep it practical - not everything needs to change before go-live.
Read back the conflict list. For each item: must fix before go-live / update after launch / won't change. Facilitator calls it, room confirms.
For must-fix items: note what the correct process is so the content can be updated accurately.
Document the final list with a committed turnaround date for updates.
Confirm the must-fix list and who owns each item.
Set a date for changes to be in by - participants need to know when the final version is available.
Confirm go-live date and what onboarding support looks like beyond the pilot.