Module-by-Module ICA Library
Seven in-class activities presented in course order rather than date order. Each entry identifies the concept, student task, instructor controls, delivery format, current status, and live links.
In-Class Activities
The sequence mirrors the course modules. Live links are retained throughout so this page can function as both an instructor launchpad and a shareable OER.
Change in 180
Seven Ideas. Three Minutes Each. One Crash Course in Leading Change.
Rapid synthesis of foundational change-management ideas; responsible AI use; verification; executive communication under time pressure.
Research one assigned topic and build six 30-second slides: what it is, how it works, why leaders care, an example, limitations/misuse, and the one MBA takeaway.
Assign topics; choose solo/team delivery; enforce the 15–20 minute preparation window and 30-second slide timing; ask one random AI-accountability question.
Google Slides rapid-presentation exercise. Classroom-ready. No password.
DEV Notes
Architecture: HTML-based launch structure connected to seven prebuilt Google Slides templates stored in the instructor's Google account. The web page itself does not generate slides; it routes teams to the correct template, where the six-slide/30-second structure is already baked into the deck.
Why this design: Google Slides provides the collaborative editing and presentation layer while the HTML/OER page provides a stable, reusable course entry point. Keeping the topic decks separate also makes it easy to revise one topic without rebuilding the activity shell.
Maintenance: Preserve the Google Slides share permissions and deck URLs. If a template is duplicated or replaced, update the corresponding link rather than redesigning the ICA. No database or server-side application is required.
Root Cause Analysis — The Training Gap
Investigate the apparent problem before prescribing the solution.
Root-cause analysis, symptom versus cause, evidence testing, and turning an RCA into audit questions.
Investigate SingTech evidence, test competing explanations, formulate a defensible root cause, and identify evidence needed for the audit.
Facilitate evidence review and debrief; reveal the model-answer page after discussion.
Standalone HTML exercise + protected answer page. Classroom-ready.
DEV Notes
Architecture: Standalone HTML/CSS/JavaScript interaction hosted directly on the OER server. Student navigation, evidence reveals, prompts, and state changes are handled in the browser rather than through a separate application server.
Instructor answer: The model-answer/debrief is maintained as a separate HTML page so the student experience can remain inquiry-first. The access control is a lightweight classroom gate, not a high-security content-management system; therefore sensitive credentials or genuinely confidential data should never be stored in the page source.
Maintenance: Because the activity is self-contained, it is portable and inexpensive to host. Future changes are primarily edits to the HTML content and JavaScript interaction logic. Keep the student and instructor-answer pages together when moving directories.
Stack the Deck
Live stakeholder analysis through influence roles and evidence-based judgment.
Stakeholder analysis, informal influence, change-agent roles, and evidence-based role assignment.
Review stakeholder evidence and classify people as Opinion Leader, Connector, Journalist, or Counselor, then justify the choice.
Open/close voting, advance stakeholders, reveal results, monitor participation, and debrief trade-offs.
Live student + instructor HTML application. Instructor authentication required.
DEV Notes
Architecture: Two browser-based interfaces—student and instructor—connected through Google Firebase. The pages use the Firebase JavaScript SDK, Firebase Authentication, and Firebase Realtime Database to synchronize the live classroom state.
Authentication: Students authenticate anonymously so they can participate without account setup. The instructor uses Firebase Email/Password authentication. Database security rules distinguish instructor permissions from student permissions rather than embedding an instructor password in the HTML.
Realtime data: Voting state, current stakeholder, participation, individual votes/rationales, and public aggregate results are stored/synchronized in Realtime Database. Security rules restrict students to their own writable records while allowing the instructor to manage rounds and read the full class state.
Deployment: The HTML files are hosted on kurtstuke.com while Firebase supplies the backend services. Authorized domains must include the production domain. If this activity is cloned, review the Firebase project configuration, Authentication providers, Realtime Database rules, and instructor UID before deployment.
The Fun Day Decision
Judgment first; structured decision analysis second.
Decision quality, weighted decision matrices, criteria weighting, trade-offs, and disciplined managerial judgment.
Rank seven employee-event options intuitively, then build a weighted matrix and compare the structured result with the first-pass choice.
Facilitate the contrast between instinct and structured analysis; debrief the difference between tool output and managerial judgment.
Standalone HTML decision lab. Classroom-ready.
DEV Notes
Architecture: Single-page HTML/CSS/JavaScript decision lab. The activity uses staged screen sections and client-side JavaScript to move students from the brief, to intuitive ranking, to criteria weighting, to the calculated decision matrix and final recommendation.
Calculation logic: Matrix scoring is performed in the browser from the student's selected weights and the embedded option data. No external database is required, which makes the interaction easy to copy, archive, or run from ordinary web hosting.
Design feature: The exercise intentionally captures judgment before exposing the structured matrix. Future revisions should preserve this sequence; otherwise the matrix can anchor the student's first answer and undermine the comparison between intuitive and analytical decision-making.
SingTech LEAN Value Lab
Redesign work around customer value and eliminate Muda.
LEAN, value add (VA), business-required NVA (BNVA), NVA/Muda, current-state and future-state process design.
Analyze a current workflow, classify activities, redesign the future state, remove or combine waste, and defend the revised process.
Facilitate classification debates and future-state design; use the dashboard to compare current and future totals.
Standalone multi-screen HTML lab. Classroom-ready.
DEV Notes
Architecture: Standalone multi-screen HTML/CSS/JavaScript application. Process cards, classifications, future-state edits, the LEAN Trash/Muda behavior, and dashboard calculations are managed client-side.
State model: The current-state process is embedded as structured data in the page. Student classifications and future-state changes are tracked in JavaScript and then rolled into the dashboard so VA, BNVA, NVA/Muda, step counts, and other process totals remain internally consistent.
Maintenance: There is no external database dependency. When changing the workflow, update the underlying process-card data and the calculation rules together. Validation around deleting a step is pedagogically important because it forces students to distinguish true elimination from simply hiding work inside another step.
Leadership Lab — TEAM ↔ TASK
Leadership models interpreted through the central TEAM-versus-TASK tension, followed by rapid application to a contemporary leader.
Leadership models, situational emphasis, strengths and limits of each model, TEAM-versus-TASK judgment, and evidence-based application.
Complete the Leadership Lab as a class, respond to examples and polls, then move into Leadership in 180 to analyze an assigned contemporary leader through six leadership lenses.
Advance synchronized Leadership Lab content, open reflections/polls/survey, view aggregate responses, reveal model interpretations, then assign teams/leaders for the 180-second application.
Two-part leadership sequence: live instructor/student Leadership Lab plus a standalone team-based Leadership in 180 activity.
Leadership Lab
Build the conceptual foundation around TEAM ↔ TASK and the major leadership lenses.
Leadership in 180
Apply those lenses to an assigned contemporary leader in a fast, evidence-based team analysis.
DEV Notes
Leadership Lab architecture: Separate student and instructor HTML interfaces use the Firebase JavaScript SDK. Firebase Realtime Database synchronizes the current instructional stage, open/closed audience activities, poll responses, and survey aggregates. Students use anonymous authentication; instructor controls use Firebase Email/Password authentication.
Shared backend: The Leadership Lab was built using the same Firebase service pattern as Stack the Deck, reducing setup overhead and allowing the same authentication/database infrastructure to support another live classroom interaction.
Privacy/design: The student survey produces an individual TEAM ↔ TASK reflection result while the instructor view emphasizes aggregate class data rather than publishing individual survey results. The instrument is explicitly framed as a classroom reflection tool rather than a validated psychological assessment.
Leadership in 180: This second component is intentionally simpler: an HTML launch/activity layer connects students to prebuilt presentation materials for rapid team application. Keep the two components conceptually linked but technically separable so either can be revised or used independently.
The Change Game
Manage the change. Protect the people. Live with the consequences.
Applied change management decision-making, balancing organizational performance with employee buy-in, and recognizing how choices can simultaneously affect outcomes and stakeholder support.
Work through a series of change-management decisions in which each choice affects both the team’s performance score and employee support. Students must weigh short-term gains against the human side of change and manage both dimensions across the full simulation.
Facilitate the activity and debrief the trade-offs embedded in each decision. Emphasize that effective change leadership requires attention to both results and employee commitment rather than optimizing only one measure.
Standalone multi-round HTML simulation with a running score and employee-support indicator. Classroom-ready.
DEV Notes
Architecture: Browser-based multi-round simulation built with HTML/CSS/JavaScript. Scenario choices are mapped to point values and employee-support consequences, and JavaScript maintains the running performance score and heart/support indicator across rounds.
Game logic: The two measures are intentionally independent: a choice can improve the performance score while costing employee support. Some later choices can restore support, subject to the five-heart ceiling. This dual-state logic is the core teaching mechanism and should be preserved when scenarios are revised.
Maintenance: Keep scenario text, point awards, heart effects, and any recovery rules together in the decision logic so the visible feedback and cumulative totals cannot drift apart. The activity is designed to run from standard web hosting without requiring an LMS-specific package.