Prioritizing a Maintenance Need

You have 45 minutes before the event starts, and eight reported problems: a double-clicking mouse, a station needing a game update, a broadcast PC nearly out of storage, a missing spare headset, a broken decorative LED strip, an unexplained switch outage yesterday, a damaged cable connector, and outdated team wallpaper. You can realistically address three. Go.

Maintenance is prioritization

There's no unlimited time, so you need a repeatable way to compare issues instead of picking whichever one someone complains about loudest. Use five factors: impact, urgency, dependency, backup, effort.

Impact. If this fails, what actually happens? A broken decorative LED has low impact on competition. A failing network switch potentially has high impact.

Urgency. When does the problem matter? A game update due before match start is urgent. A cosmetic cable label can probably wait.

Dependency. How many functions depend on it — the blast-radius idea from Week 15. One mouse is a very different case than one switch serving six stations.

Backup. If it fails, is there another option? A mouse failure with five spares on hand carries much lower operational risk than the same failure with zero spares.

Effort. Can the response reasonably happen before the system is needed? Swapping a mouse takes two minutes; rebuilding a broadcast PC takes hours. Effort doesn't mean "always do the easiest thing first" — it means building a realistic plan given the time you actually have.

Skip the fake formula

You could assign numbers to all five factors and calculate a precise priority score — please don't. "7.43 priority points" isn't more rigorous, it's just false precision. Use high/medium/low and real reasoning instead.

Priority matrix

Build a table with issue, impact, urgency, backup, and priority as columns — for example, a double-clicking mouse (medium impact, high urgency, spare available), a broken LED (low impact, low urgency, not applicable), switch instability (high impact, high urgency, backup unknown), and low storage (medium impact, medium-to-high urgency, maybe recoverable). Defend the final priority for each, don't just fill in the boxes.

Priority is contextual

Station 08's mouse failing is normally a medium issue. But if Station 08 is the only caster station, there's no spare mouse, and the event starts in ten minutes, the priority changes completely — same failure, very different context.

Event requirements shift priority too. A broadcast PC might be nonessential during ordinary classroom practice and absolutely critical during a livestreamed championship. Maintenance priority depends on what the system actually needs to do right now, not on some fixed importance ranking.

Maintenance debt

If small maintenance needs keep getting postponed, they can accumulate — one outdated PC becomes two, then five, then event-day update chaos for eight machines at once. Call that maintenance debt: not a perfect technical term, but a useful model for work you're deferring that may get harder the longer it waits.

But not every deferred task turns into a disaster — a broken decorative light might be safe to defer indefinitely. Priority means deliberately choosing "not now" for some real work, and that's a legitimate decision, not a failure to keep up.

Prioritization lab: Robotnix Arena Lab B

Upcoming event: Friday, 3:30 PM. Current maintenance reports:

Station 01 is ready — no problem, don't invent work where none exists. Station 02's headset microphone cuts out intermittently, and a spare headset is available. Station 03 needs a game update, expected to take twelve minutes. Station 04's Ethernet cable connector is visibly damaged, but the connection currently works. Station 05's mouse scroll wheel is broken, though the mouse otherwise works, and one spare mouse is available. Switch-A disconnected four player stations for about twenty seconds yesterday, with no confirmed cause. The broadcast PC is at 95% storage, and the event will generate new recordings. The team banner's decorative lighting has failed.

You have 45 minutes. Sort every issue into P1 (attention before the event), P2 (schedule soon), or P3 (monitor/lower priority). Not everything can be P1 — if everything is critical, nothing actually is.

For each issue, record: function, impact, urgency, shared dependency, backup, effort, priority, and why.

Switch-A is a good test case: high impact, potentially high urgency, but the cause is unknown, and freshmen shouldn't attempt to fix it themselves. The maintenance action here is to document the pattern, verify current status, escalate to authorized staff, and prepare a contingency — planning doesn't require students to personally repair the switch.

Broadcast storage is another: the computer still works, so it might look low priority, but the upcoming event needs recording storage, which makes this an availability risk worth preventive attention before it becomes a failure.

The mouse wheel depends entirely on the system's goal — if the game doesn't require scroll input for anything critical, it's lower priority; if a player's configuration depends on it, that changes the answer completely.

Disagreement is fine

Your group might land on a different priority order than another group. That's fine — the goal isn't guessing a hidden correct answer, it's using evidence. "I rank the damaged cable above the mouse because the cable shows physical damage and no backup path is documented" is a defensible claim someone else can push back on with their own evidence.

Build the maintenance board

Sort every issue into P1 (before event), P2 (schedule), or P3 (monitor). Every P1 item also needs an owner, an action, and a verification step — a P1 with no owner just becomes "somebody should probably do this," and that never actually gets done.

Example: issue — Station 03 game outdated; priority — P1; owner — station technician; action — complete approved update; verify — launch the required game and confirm expected version; follow-up — return station to ready status.

Before you leave

Complete:

1. The issue our group ranked highest was __________ because __________.
2. The issue we intentionally deferred was __________ because __________.

That second decision matters just as much as the first one.

Source note

This lesson applies Middle Township Unit 5 expectations involving reliability, maintenance, repair, tradeoffs, cost/benefit thinking, and system constraints.

The five-factor priority model, the maintenance-debt concept, the P1/P2/P3 board, and the fictional Robotnix Arena maintenance cases are original Robotnix Academy instructional components.