Developer Quick Start

1. Read the workflow

Where: Curriculum Development Overview

What to use: Workflow diagram, required outputs (module-level and course-level).

What you’re doing: Orienting so you know what each phase produces and what the next phase needs.

2. Complete kickoff

Where: Project Kickoff and Intake

What to use: Intake agenda, project charter template, UCI guide, meeting notes.

What to submit / document: Intake notes, charter (or equivalent), module list, SME roster, initial simulation scope.

Gate: Kickoff is complete when:

• Intake notes are documented
• UCI is assigned or confirmed
• Module list is finalized
• Development path is chosen (custom / vendor / hybrid)
• Simulation scope is drafted
• Stakeholders and timeline are confirmed

3. Build the planning document

Where: Planning

What to use: PS ID Companion (Gemini) , planning example (Module 134), Planned Doc Example (linked on page).

What to submit: Planning handoff package: planning doc, source links, module list, simulation frame, open issues.

Gate: Planning is complete when:

• Objectives are approved
• Assessment map exists
• Simulation frame is defined
• Source materials are linked
• Activity map is complete
• Open questions are resolved

4. Choose dev path

Where: Developing

What to do:

• Custom: No usable source content; build from scratch. → Custom Development
• Vendor: Content is solid; main work is adaptation and framing. → Vendor Development
• Hybrid: Part reusable, part new build; use both Custom and Vendor pages for the relevant sections.

5. Create required assets

Where: Custom or Vendor

What to use: Naming prefixes, lab/SBA structure, approved software list, Companion for scenarios and prompts.

What to produce: Per module: blueprint, lessons, labs, KBAs/SBAs, slides, facilitator guide; simulation context in materials.

Gate: Development is complete when:

• All required assets are built
• Naming conventions are correct
• Links work
• Facilitator guidance exists
• Simulation context appears in materials
• Self-QA is done

6. Run self-QA

Where: Quality Assurance Process

What to use: QA Worksheet & Rubric , PS ID Companion .

Before you submit, check: Objectives match assessments; instructions complete; simulation context affects the task; timing realistic; facilitator notes actionable; naming and links correct.

What to submit: QA submission package: slides, labs, assessments, facilitator guide, notes for reviewer, unresolved questions.

Gate: Ready for QA when: Worksheet complete, self-review done, package assembled and labeled.

7. Submit for review

Where: Product Development Dashboard  and QA workflow on the QA page

What to send: Per QA submission package (see step 6). Label files clearly; include notes for reviewer and any open questions.

What happens: First-round QA → you address feedback → second-round → final approval.

8. Support implementation

Where: Instructor Training and Support

What to hand off: Final assets, instructor-facing materials, Canvas setup notes, simulation support assets, known issues and escalation contacts.

What to do: Ensure training scheduled, materials in place, and instructors know how to facilitate the simulation (not just deliver content).