A hospital's network team plans to open a new outpatient annex in three months and wants to tune the existing main campus WLAN for better performance beforehand. Before changing any RF or QoS settings, the team spends a week capturing coverage, throughput, and roaming data across the current wards. Why is capturing this data before making any changes the right first step?
Select an answer to reveal the explanation.
Short Explanation
Think of it like a doctor taking your vitals before starting treatment: without that first reading, nobody can tell if the treatment actually helped. A baseline is that starting reading for the network — capture it before you touch anything, or you'll be guessing whether your changes made things better or just feel different.
Full Explanation
A baseline is a measured snapshot of how the network is behaving right now, taken before any tuning changes are applied. It matters because 'better' is a comparison, not a feeling — without a documented starting point for coverage, throughput, retransmissions, and roaming behavior, the team has no way to prove a later change actually improved anything versus simply coinciding with a quiet day on the ward. The compliance-only framing misses the point: while documentation habits matter, the operational reason to baseline is measurement, not paperwork. Treating the baseline as a stand-in for the annex's own site survey confuses two different exercises — the annex is new construction with its own RF environment, materials, and layout, so it needs its own predictive survey regardless of what the existing campus baseline shows. And skipping post-change validation is backwards: the baseline is only half the comparison, the whole point is to measure again after tuning and hold the two data sets side by side. A concrete check the team can perform: pull the same coverage heatmap and roaming-latency report using identical test devices and walk paths both before and after the change, so the comparison isn't skewed by different tools or routes.