Choosing Hardware for a School Media Lab
A school is refreshing a 20-seat media lab used for video editing, 3D modelling and general office work. The business manager proposes 20 identical mid-range desktops with 8 GB RAM, integrated graphics and 256 GB solid-state drives, plus a three-year warranty. The head of department notes that video files for a single project can reach 40 GB and students often work on the same machine across lessons. The network drive has 2 TB free and is backed up nightly. Two staff members currently administer the lab, and their workload is already full. The budget is fixed and cannot be increased, but the split between machines and other items is negotiable.
1. Evaluate whether 8 GB RAM and 256 GB storage are adequate, and recommend how to reallocate the budget.
Read the worked answer
Both specifications are marginal for the stated workload.
- RAM: video editing and 3D modelling are memory-hungry, and 8 GB leaves little headroom once the operating system and an editor are open. The symptom students would see is stuttering playback and long render times, not a clear error message, which makes it hard to diagnose in class. 16 GB is the sensible floor for the editing seats.
- Storage: a 256 GB drive holds the operating system and applications, leaving perhaps 150-180 GB. A single 40 GB project plus its cache and exports can consume a large share of that, and students working across lessons will leave files behind. Since the network drive has 2 TB and nightly backups, local storage does not need to hold projects at all, provided a clear save-to-network policy is enforced.
Reallocation: buy fewer high-specification editing machines and keep some cheaper general-purpose seats, since not every lesson needs video work. Spend the saving on 16 GB RAM for the editing seats and on a simple asset-tagging and login policy so students can find their work. Do not spend the whole budget on identical machines when the workload is not identical.
2. The business manager argues identical machines are cheaper to support. Assess that claim in this context.
Read the worked answer
Standardisation genuinely reduces support cost: one image, one set of drivers, one spare-parts pool, and staff who learn one machine. That argument is valid in general and should not be dismissed.
But the benefit is smaller here than it appears. The lab already has two distinct workloads, so a single mid-range specification is a compromise that is adequate for neither the editing nor the cheap office tasks. The support saving is also limited by the fact that two already-full staff administer the lab, so any support burden is a real constraint, not a theoretical one.
A middle path preserves most of the standardisation benefit: standardise within tiers, so all editing machines are identical to each other and all general machines are identical to each other. That gives two images rather than twenty unique machines, keeps spares simple, and matches spend to need. The judgement is that standardisation is a means to lower support cost, not an end in itself, and it should be traded off against fitness for purpose when the workload is heterogeneous.
3. Recommend a policy for where student project files are stored, and justify it against the risks in the scenario.
Read the worked answer
Store all project files on the network drive; treat the local disk as disposable working space and the network as the record.
Justification:
- Capacity: the network has 2 TB free and is backed up nightly, which resolves the 256 GB limit without buying larger local drives.
- Shared machines: students move between machines across lessons, so files tied to one desktop are effectively lost to them. A network location reachable from any seat solves this directly.
- Backup and recovery: local drives are not described as backed up, so a failed machine would destroy work. The nightly network backup gives a recovery point.
- Cost: this uses existing infrastructure, which matters under a fixed budget.
Implementation details matter: give each student a named folder with quota, set the editor's scratch or cache directory to a local temp folder that is cleared at logout, and teach an explicit save-and-close routine. Add a weekly check that no project files sit on local disks. The residual risk is that a student loses up to a day of work between backups, which is acceptable for school projects but should be stated openly.