Planning
Define the target role and objectives, choose evidence, plan pre-work vs in-class activation, and produce a planning handoff so the dev team can build without guessing.
What you need before starting
- Completed Kickoff: intake notes, UCI, module list, initial simulation scope, development path.
- Access to PS ID Companion (Gemini) .
What you need to produce
Planning handoff: planning doc (overview, objectives, assessment map, activity map with pre-work vs in-class), simulation frame, source links, module list, open issues.
Repeatable model: Flipped + activation
Design every module so it’s repeatable and efficient:
| Pre-work (before class) | In-class (activation) |
|---|---|
| Content: readings, short videos, knowledge checks | Doing: stand-ups, labs, scenarios, discussions, exit tickets |
| Learners arrive with baseline knowledge | Instructor facilitates and coaches; minimal lecture |
Target: ~75% of class time is activation (doing), not passive delivery. This matches our Flipped Classroom approach and maximizes job-ready practice.
Content outside class → class time for application. Proven for retention and efficiency; aligns with Workplace Simulation (learners “show up as the role” and work tickets).
What to do (6 steps)
Step 1: Define target role and job tasks
Do: Name the role learners will simulate. List 3–5 primary tasks, tools, constraints, KPIs.
Output: Target role, tasks, tools/platforms, time constraints, KPIs in planning doc.
Example: Junior IT Technician at TechCorp — identify hardware, follow safety, troubleshoot; tools: ticketing, KB; KPIs: resolution time, accuracy.
Review: Could a developer build a day-in-the-life scenario from this alone?
Step 2: Write 3–5 measurable objectives (Bloom verbs)
Do: Write 3–5 objectives with observable Bloom verbs (analyze, create, troubleshoot, configure); workplace-relevant, assessable in ~30 min.
Output: 3–5 objectives with Bloom verbs in planning doc.
Example: “Identify core computer hardware components by sight and function.”
Review: Can we observe and assess each one?
The PS ID Companion can help you generate objectives, simulation scenarios, and assessment ideas from your target role and tasks.
Step 3: Choose evidence for each objective
Do: Map assessment types to objectives: KBA for concepts, SBA for hands-on, case/deliverable for complex tasks. Note scoring (rubric/checklist).
Output: Assessment map: which assessment(s) prove which objective(s).
Example: KBA for component ID and safety; SBA lab for hands-on inventory; case for client consultation.
Review: Can we defend that passing these = objective met?
Step 4: Map activities — pre-work vs in-class (activation)
Do: For each objective, plan pre-work (content: what they read/watch/check before class) and in-class (activation: what they do — labs, scenarios, stand-ups, discussions). Time-box and list materials. Aim for ~75% in-class = doing.
Output: Activity map with pre-work vs in-class, durations, activity types, materials.
Example: Pre-work: video on hardware + short knowledge check. In-class: inventory lab, safety scenario, then client ticket (identify + document).
Review: If a learner does this pre-work and these in-class activities, are they ready for the assessments?
Step 5: Define the simulation frame
Do: Draft the workplace simulation: team lead rotation, stand-ups, ticket source, KPIs, escalation. This runs throughout the module.
Output: Simulation frame: workplace context, team structure, stand-ups, ticket source, KPIs, escalation.
Example: Teams of 3–4; daily stand-up; shared ticket queue; KPIs: tickets closed, client satisfaction.
Review: Does the frame change what learners actually do each day?
Step 6: Package the planning handoff
Do: Assemble planning doc (overview, objectives, assessment map, activity map with pre-work/in-class, simulation frame, source links). List open issues. Share with development team.
Output: Single planning document (or doc + linked sources), module list, simulation frame, open issues. Use Planned Document Example as structure reference.
Review: Can the developer start building without asking “where’s X?”?
Example: Module 134 (Hardware Components and Safety) — flipped + activation
Same module, framed as inquiry-led and repeatable: situation/question first, concepts in pre-work, activation in class.
Module 134 — flipped + activation
Pre-work carries content; in-class is doing. Repeatable pattern for any module.
Stage 1 — Role and objectives
- Role: Junior IT Technician at TechCorp. By the end: identify hardware, follow safety, troubleshoot.
- Objective example: Identify core hardware components by sight and function — so you can audit a workstation and document what's there.
Stage 2 — Evidence
- KBA: component ID and safety (before touching anything).
- SBA: hands-on inventory in a scenario (e.g. ticket: audit due Friday).
- Case: client calls with a hardware issue — what do you check and document?
Stage 3 — Pre-work vs in-class
- Pre-work: Short video + reading on components and safety; knowledge check (component ID, safety rules).
- In-class Day 1: You're on the shift; inventory is due — what do you identify and document? (lab + stand-up).
- In-class Day 2: Safety concern on one component — what do you do before you proceed? (scenario + discussion).
- In-class Day 3: Client ticket — slow machine, possible hardware. First move and handoff (case application).
Content format planning
Before you hand off, decide which formats best serve each learning objective. Don’t default to “slides then lab” for everything.
When to use which format
| Format | Best for | Example |
|---|---|---|
| Slides (Lesson) | Introducing concepts, visual explanations | TCP/IP fundamentals, component identification |
| Video walkthrough | Complex tool setups, multi-step procedures | Configuring a firewall, setting up a CI/CD pipeline |
| Guided Lab (GLAB) | First exposure to a hands-on skill | Step-by-step: verify connectivity with ping and traceroute |
| Assignment Lab (ALAB) | Independent practice with scenario framing | ”Client ticket #2089: new office can’t reach the internet” |
| Case Study (CS) | Analysis, judgment, research beyond rote steps | ”MedTech Corp DNS outage — analyze logs and determine root cause” |
| Discussion (DISC) | Peer learning, reflection, trade-off analysis | ”What was your troubleshooting process and what would you do differently?” |
| Code Sandbox / Interactive | Live coding, experimentation | CodeSandbox embed for React component props |
A strong module uses at least two different formats beyond slides. See Non-Negotiables & Standards for full guidance and worked examples.
Exit criteria
Planning is complete when: objectives approved; assessment map exists (each objective has evidence); simulation frame defined; source materials linked; activity map complete with pre-work vs in-class; open questions resolved or documented.
Common mistakes
Common mistakes
- Objective too broad or not observable; assessment checks recall instead of performance.
- Simulation context decorative, not task-affecting.
- Too much lecture; not enough activation — aim for ~75% in-class doing.
- Activity map doesn’t split pre-work vs in-class; activities don’t build toward assessments.
- Handoff missing source links or open issues.
Related tools/templates
- PS ID Companion (Gemini) — Step-by-step planning; reasoning and prompts.
- Planned Document Example — structure reference.
Next step
Developing — Choose custom, vendor, or hybrid and build the required assets.