Workplace Simulation

Every Per Scholas classroom runs as a workplace. Learners hold job titles, work in teams, handle tickets, run daily stand-ups, and deliver professional output. This isn’t a framing device or an add-on — it’s how class operates from day one.

Simulation shapes how we build curriculum (developers design for it), how instructors deliver it (class time mirrors a real work environment), and how support staff reinforce it (coaching, feedback, and accountability all happen inside the simulation).

What Monday morning looks like

A traditional classroom starts with a lecture. A simulation classroom starts with a stand-up.

	Traditional classroom	Simulation classroom
Start of day	Instructor lectures, students take notes	Team stand-up: what I did, what I’m doing, blockers
During class	Individual work on generic exercises	Teams work tickets framed as client requests
Learner identity	”Student in row 3"	"Junior Cloud Engineer at CloudOps, Team B lead this week”
Assessments	Quiz at the end of the unit	Deliverables: incident reports, inventory audits, config docs
Collaboration	Optional group work	Required: shared KPIs, peer reviews, handoff notes
End of day	Pack up and leave	Update ticket status, write handoff notes for tomorrow

The goal: when a learner walks into their first real job, nothing about the daily rhythm should feel new.

Core components

Every simulation has five parts. If any are missing, it’s not running correctly.

Job roles

Every learner gets a job title that matches the target role for the course. A cybersecurity cohort produces “Junior Security Analysts.” A healthcare IT cohort produces “Medical Billing Specialists.” The title isn’t decorative — it defines what’s in scope for the learner and when to escalate.

Team structure

Learners work in pods of 3-4. One person is team lead each week (rotating). The lead runs stand-up, assigns from the queue, and is the first point of contact for the team. This mirrors how most entry-level tech roles actually function.

Daily stand-ups

Every team, every day. Format: what I did yesterday, what I’m doing today, what’s blocking me. Instructors observe but don’t run it — the team lead does. This builds communication skills and surfaces problems early.

Ticket-based work

Labs and assignments are framed as work coming in from clients, supervisors, or the queue. Not “configure a firewall” but “Client ticket #4472: suspicious outbound traffic detected. Investigate and resolve.” The framing changes how learners approach the task — they think about impact, documentation, and handoff, not just completion.

KPIs and accountability

Teams track shared metrics: tickets closed, documentation quality, assessment scores, participation. ICP (In-Class Participation) scores enforce preparation and engagement. If your name is on the ticket, your updates need to be clear enough for someone else to take over.

What simulation is NOT

Not role-play or improv. Learners aren’t acting. They’re doing real technical work inside a professional structure.
Not optional. Every class runs as a simulation. It’s not a module you can skip or an enrichment activity.
Not just a framing device. If the simulation context doesn’t change what learners actually do — if you could remove the company name and nothing changes — it’s not working.
Not separate from the curriculum. Developers build simulation into the content. Instructors facilitate it. It’s not layered on top after the fact.