Technology Maintenance Project

Final technical challenge: you have an esports lab that mostly works, a tournament tomorrow, and a maintenance backlog — with no unlimited time to clear it. Welcome to operations.

The lab: Robotnix Esports Arena

Eight player stations, one caster station, one broadcast station, two switches, one router/shared uplink, two spare mice, one spare headset, and one spare Ethernet cable.

Event requirement

Tomorrow's event requires all eight player stations, the caster station, the broadcast station, network access, game service access, voice communication, and local recording. Every one of those matters.

Current maintenance reports

Station 01: no issues. Station 02: headset microphone disconnected twice during the last practice; a spare headset is available. Station 03: game version is behind the current event requirement. Station 04: Ethernet cable connector is visibly damaged, but no connection failures yet. Station 05: mouse scroll wheel is unreliable. Station 06: no issues. Station 07: free storage is below the instructor-defined lab threshold, though no recordings are required on that player station. Station 08: no issues.

Shared infrastructure. Switch-A serves Stations 01-04 and had one brief unexplained outage this week. Switch-B serves Stations 05-08 with no reported issues. The caster station is working. The broadcast station's storage is nearly full, and tomorrow's event requires local recording.

Spare inventory. Two mice, one headset, one Ethernet cable.

Maintenance history. Two weeks ago, Station 02's headset reported low microphone volume. One week ago, Station 04's cable was reseated after a connection problem. Three days ago, the Switch-A stations lost connectivity briefly. Yesterday, Station 02's microphone disconnected twice. A pattern is forming here worth noticing.

Your resources: 60 maintenance units

Not literal minutes — think of these as limited maintenance capacity. Each action has a fictional cost: swap approved mouse (5), swap headset (5), replace approved Ethernet cable (10), complete game update (15), approved storage cleanup (15), verify switch status and document/escalate (10), full player-station readiness test (5 each), broadcast function test (10).

You can't do everything, and that's the point. The unit costs force real tradeoffs — this isn't a math exercise, it's a forcing function for the same kind of reasoning as Lesson 2, just with harder numbers behind it.

Step 1: identify event-critical functions

Before looking at any individual issue, write down what must be available tomorrow: player input, display, game, network, voice, broadcast, recording. Now maintenance has an actual target instead of a vague sense of "everything should work."

Step 2: map dependencies

Which equipment supports each critical function? Recording depends on the broadcast PC, which depends on storage. Suddenly the broadcast storage issue matters a lot more than "storage is a little full" makes it sound.

Step 3: prioritize issues

Classify every report P1, P2, or P3, and explain why for each one.

Step 4: spend your maintenance capacity

You have 60 units. Build the action plan — for example: 15 to update Station 03, 10 to replace Station 04's cable, 10 to inspect/document/escalate Switch-A, 15 to clean approved broadcast storage, 10 for a broadcast function test, totaling 60. Is that the right allocation? Maybe, maybe not — what happened to Station 02's headset? That's exactly the debate this exercise is designed to produce.

If you use the spare headset instead, that only costs five units — worth considering — but then something else in your budget has to move. There's no perfect plan; that tension is the actual lesson.

Step 5: create contingency plans

For every P1 item, answer: what if the maintenance action doesn't work? Example: swap Station 02's spare headset, retest, and if it's still failing, move the player to an approved alternate station or escalate. This is what connects maintenance to availability instead of treating a fix as automatically successful.

Step 6: verification

Every action needs a way to know it actually worked. Not "update finished" but "required version launches." Not "headset replaced" but "output and microphone input both function in the required application." Not "cable replaced" but "expected network connectivity remains available after replacement." Not "storage cleared" but "sufficient approved free space exists for the planned recording."

Step 7: leave a maintenance record

For each issue: priority, action, result, verification, follow-up, owner. Not every issue has to be resolved before the event — some become scheduled maintenance instead, and that's a legitimate outcome, not a failure to finish.

Your final artifact: the Esports Lab Maintenance Plan

1. Lab readiness goal. What does tomorrow's event require?

2. Current condition summary. What's ready, what needs attention?

3. Maintenance priority board. P1/P2/P3, every reported issue included.

4. Dependency reasoning. At least three priority decisions explicitly tied to system dependencies.

5. Maintenance budget. How your 60 units were spent.

6. Action plan. For each selected action: owner, action, verification, failure response.

7. Escalation. At least one issue that should be escalated rather than repaired by students.

8. Deferred maintenance. At least two items intentionally scheduled for later, with reasons.

9. Final readiness status. Ready, ready with known limitations, or not ready — defended with evidence.

You're allowed to conclude not ready. If your evidence actually supports that, it's the professional answer — don't claim "ready" just because it sounds better than the truth. A known-limitation example: "Station 05's mouse wheel remains unreliable, but the required competition controls don't use that input, and a spare mouse is still available" — that's a defensible "ready with known limitations," if you can actually back it up.

Group roles

Keep it simple: Systems Lead tracks dependencies, Maintenance Planner builds priorities, Evidence Recorder documents reasoning, Readiness Lead checks whether the final plan actually meets event requirements. Four roles, no invented titles.

Challenge card

After your group finishes the plan, draw one surprise and update accordingly: the spare headset becomes unavailable; the event now requires higher-quality recording, raising the broadcast storage requirement; Station 05 becomes completely unavailable; Switch-A passes inspection with no root cause identified, so how do you classify the remaining risk; or the event is delayed thirty minutes, which may or may not change any priorities.

Maintenance plans exist inside systems that keep changing — a useful plan is structured, but not frozen. Same idea as Week 17: repeatability plus adaptation, not repeatability instead of adaptation.

Final defense

About three minutes per team: what was your highest priority and why, what did you intentionally leave unresolved and why, which dependency affected your decisions most, and is the lab actually ready? Don't narrate every slide — defend the plan.

Suggested format

Google Slides plus one maintenance table works well. A ten-slide structure: event requirement, lab condition, dependency map, priority board, maintenance budget, P1 actions, verification and contingencies, deferred maintenance, the surprise change, and the final readiness decision.

Final project requirements

Your Esports Lab Maintenance Plan needs: event requirements; a maintenance condition summary; every issue prioritized; dependency reasoning; a 60-unit maintenance allocation; an owner, verification method, and failure response for each action; at least one escalation; at least two deferred issues; a maintenance record; one change-card revision; a final readiness decision; and evidence supporting that decision.

Before you leave

Complete:

1. The issue we chose not to fix before the event was __________ because __________.
2. The issue we refused to defer was __________ because __________.

Those two answers say more than "we fixed stuff."

Source note

This project synthesizes Middle Township Unit 5 concepts involving technology maintenance, repair, reliability, system dependencies, network operation, usability, constraints, and tradeoff-based decision-making.

The Robotnix Esports Arena simulation, the 60-unit maintenance constraint, the maintenance priority board, the change cards, the readiness classification, and the Esports Lab Maintenance Plan are original Robotnix Academy instructional components.