Plain English Site Survey Reports

Following a wireless site survey, many organisations are sent automated wireless site survey reports in excess of 80 pages.  These tree-unfriendly documents are the result of a click of a button on site survey software which spits out a colourful but massive report in a few seconds.

For a business however, they are about as readable and interesting as a dot matrix printout of line items at a warehouse.  Everyone remember dot matrix printers?

Essentially, an automated site survey report is raw data.  Factual, accurate and…Unhelpful.  It doesn’t tell the business anything.  A business without wireless specialists (the majority) will look at it and still have fundamental questions:

  • The heat maps are all green, so why is my WiFi rubbish?
  • What are your recommendations?
  • Should I be worried, is this normal?
  • Is -50dBm bad?  It sounds bad.
  • What is Channel Overlap? Do we need more of it?
  • This is unintelligible.

It is nice marketing by wireless survey software vendors, to say ‘Hey, just press this button and your job is done; report generated. You can even put your own logo/branding in.’  It sounds good in theory and it actually is a real time-saver.  But, does your doctor hand you a blood analysis report – composed of fun latin names – and leave you to interpret it on your own?

Myself, I created a template in MS Word.  Each survey report is written in plain english, removing jargon wherever possible and customised to address the reason for the site survey in the first place.  For example: to troubleshoot poor performance or to prove a new service works as designed or, a pre-deployment survey of the current environment.

The report’s content is supported by adding screenshots/tables from the survey into the body of the document or as an appendix.  It also avoids sending a 20MB attachment of irrelevant data to my client.

This is my personal way of doing things and so far, customer feedback has been good.

In summary, I think if automated reports are going to be used and sent to customer IT managers, then at minimum they should be accompanied by a separate document. A summary in plain english that offers analysis, findings of interest and (if requested) recommendations.






When upgrades are not about technology

While at a customer’s slightly unusual site (let’s just say, heavy machinery with very custom hardware and applications) they suggested upgrading their wireless installation to the latest technology.  Suddenly foretelling an unanticipated event while upgrading – and subsequent disruption to production, a brief look of alarm crept out.

Actually, similar to the somewhat alarmed look my wife gives me when I reach for another piece of cake.  A look that urges one to ‘reconsider’.

The existing solution works fine, quite well in fact.  The known cost and unknown consequences (for now) of such an upgrade activity were a little alarming considering the as yet unproven benefits of a new solution working with their existing custom devices.

Turns out however, the upgrade had nothing to do with improving the WiFi.  Bigger things were happening; which would impact the wireless network.  And while not near end of support, the existing wireless network in some parts is four years old.  So, End-of-Life in accounting terms.  We all know that the bean counters love to have expensive new items to depreciate.

All the customer needed from me at this time was to call out anything they might be missing.  I noted a couple of things for consideration and then basically, got out of the way.

Reminder to self: technology upgrades may not always be about the technology.  They may be just be a side impact of bigger commercial decisions that are going ahead.

As for the wireless installation, don’t know what I was worried about.  Might have some cake to celebrate.