In the AV industry, the end users are typically represented by two separate yet equally important groups: the designers, who specify the systems; and the integrators who install them. My company acts as a third party to commission these systems. These are our stories.
Checklist Item Under Test: 6.69: Prepare document report, certifying that the product, performance and practices are in compliance, and noting any exceptions. Distribute accordingly.
Reasoning: In many areas of the construction industry, especially AV, reports are required to transfer information to the team. Oftentimes, these reports are generated from a group of people. It would be beneficial if input from all the players could be combined into a single document in real time, and without an internet connection. Not only would this shorten the time it takes to compile the report, but it would also help in maintaining continuing status updates from the rest of the team, even when there is no network or cellular reception available.
The Story: It was a dark and stormy night. The commissioning had gone well, and everyone involved was looking to get on the road as quickly as possible. The rain was coming down in sheets, and the traffic was only going to get worse from here on. The test equipment was packed up. Hands were being shaken and goodbyes were being passed around. And then it hit me. We missed something that we knew had to be taken care of before we left for the night, but had delayed actually doing it due to the high level of annoyance, tedium and time that was attached to it.
We never combined our commissioning reports.
When AVR commissions a large system, we typically divide and conquer. One specialist will tackle inspecting the installation practices. One will take care of the system performance measurements. And, when possible, a third commissioning agent will go through the control system button-by-button to make sure it operates as expected. Then, when all the checklist items are completed, we combine the status of the checklist items, as well as the report of our findings, into one document that can be distributed to the project team. There are a few methods to do this, and none are ideal.
The first method uses a dedicated scribe to capture all items onto the master report right off the bat. If anything is noticed that has to be captured in the report, it is relayed to the scribe immediately. This works great because there is no need to combine separate files at the end of testing. However, either the scribe doesn’t do any actual testing and just authors the report, or does some testing but is constantly interrupted with other team members’ findings. Either way, it is not an efficient approach.
Another method is to just have everyone keep their own checklists and reports as they continue to test, and combine them at the end. The testing aspect goes pretty smoothly, actually. The different commissioning teams can act autonomously. However, after the testing is completed, someone has to combine all the different reports into one. Then they have to go through the final report to make sure there are no duplicated items. They may also have to edit items so the report has a single voice, instead of sending a report with a variety of reporting or documenting techniques.
For example, when reporting control system issues, should they be captured as “TelePresence Menu -> Dialing Submenu -> Keypad: The pound and asterisk are swapped” or as “The pound and asterisk buttons are swapped in the keypad of the dialing submenu in the TelePresence Menu?” Both ways get the same information across well, but have different voices. Only one should be used in the report sent to the client. Additionally, the project team has to wait around while this document compiling is happening, because the final report should be reviewed with everyone onsite to confirm its accuracy and that everyone is on the same page. So, although this method allows the testing to go through like strained peas through a baby, combining the reports at the end leaves a lot of people eager to go home, impatiently tapping their foot at the end of the day. Again, this is not ideal.
A method we settled on uses online collaboration tools. There are many available, such as Google Docs, Microsoft One Note, Evernote, Dropbox, etc. Some allow the entire team to edit a single document in real time, which is great. Actually, the team members can see each other typing in various cells, so it is easy to have several people creating a single document. The team leader can keep tabs on the voice of the items in the report to maintain consistency, and the team can use a consistent method of describing difficult items. Another benefit is that notes and placeholders can be left in the document for other members, regarding questions or reminders, almost like a chat session within the file itself. This allows the team to have continual status updates regarding where the other members are in the process. This method is pretty ideal.
Unless there’s no internet.
Access continues to get better, however. I think there was only one time in the last year where our team was not allowed on the network and/or the cell reception was so poor that we couldn’t get out to the “interweb-tubesnet.” So, this collaboration stuff that everyone’s been talking about is actually pretty powerful. Go figure.
However, if we can’t get out to the internet, we are forced back to the dark ages of combining reports at the end of the day…at 6:00pm…when it’s raining…on a Friday. I don’t want to go back there. In my ideal world, there would be a standalone edition of Google Docs that could run on a Raspberry Pi server. So, when the team is deployed, we set up that special server and a wireless router (without an internet connection), but still get all the collaborative functionality between the connected laptops. I haven’t seen anything like that yet, but maybe I’ll ask Santa. My boy just reminded me that it’s only 84 days until Christmas.