We were recently commissioning a system for a large government organization. The project had been going on for years with no end in sight. They brought on a 3rd-party commissioning agent to not only confirm they received what they paid for (in the $10M+ range of AV technology), but also to address the finger-pointing issues that created this never-ending nightmare for the users. The GC was blaming the EC. The EC was blaming AVC. The AVC was blaming the users’ changing needs. The users were blaming everyone. You know…just your average, run-of-the-mill government project.
Because the project had gone on for so long, and because the users’ needs had indeed evolved over the years, there was no functional narrative that nailed down what the systems were supposed to do. We were lucky to get an equipment list and a “NapkinCAD” drawing from the major manufacturer supplying the system under test. It was a building-wide training room recording system.
Evidently, the idea behind the system was to outfit every training room with a streaming camera and microphone connected to the camera. When motion was detected in the instructor area by the camera, the recording started automatically on a server in the IT closet. When there was no motion, the recording stopped automatically. The system itself looked like a decent lecture capture system with very little user interaction required for recording control. It seemed straightforward enough, until we started testing.
There were several glaring issues. First and foremost, the camera angles were terrible. They were not zoomed into the instructor area, and the rear end of the ceiling projector took up a significant part of the image, while at the same time cutting off the top half of the presentation. I would not be a happy camper, if I had to review the lecture looking at this shot the whole time. Secondly, the automatic start and stop for the recording wasn’t very robust. Sometimes a person could walk across the instructor area and not trigger the recording, unless they threw their hands in air and waved like they just don’t care. Sometimes during a video presentation (where they might be very little motion from the class), the recording would just stop in the middle, until the presenter got back up at the podium. Sometimes the screensavers on the desktop computers in the computer classrooms would keep the recording going all day, even though no one was in the room. If the users wanted this to record their lectures, so people could study at home…again, they would have lots of unhappy campers on their hands.
I raised my concerns to the project champion, and he was not phased at all. He said the recording system wasn’t really in place for participants to review lectures. It was mostly in place in case someone brought up a law suit against the organization. So, as long as the system recorded when an instructor was walking and talking (or running and yelling, as the case may be), the requirement was satisfied, and the system could be considered a success. The terrible camera shot and recording drops during video presentations were acceptable. He said it would be nice if it were better, but it wasn’t that big a deal.
I took two lessons away from this.
- It is so important to nail down the true needs of the users. So much money and so many resources are spent providing quality systems, when they might not even be needed. I’ll never understand how so many projects are completed without some sort of formal document explaining what the system will do from the user’s perspective (a functional narrative), but it is the most overlooked document in design packages IMHO. We see this all the time with designers and installers implementing incredible conferencing systems with the newest microphone and video codec technologies in rooms where people just want to watch TV during breaks.
- Despite our best efforts, system performance excellence is not always a requirement to provide an exceptional experience for the user. I suppose this is yet another case of the engineer in me battling with the solution provider. The engineer is screaming, “THAT’S A TERRIBLE, USELESS SHOT! MOVE THE CAMERA DOWN 12″, AND IT’LL BE SO MUCH MORE EFFECTIVE. LET’S HOOK THE RECORDING CONTROLS UP TO A BETTER ROOM OCCUPANCY SENSOR AND LINK IT TO THE ROOM SCHEDULING SYSTEM! WHATSAMATTAYOUHEAD?!?!” And the solution provider is just sitting there, smiling, sipping some sweet tea, saying, “Oh, bless your heart, Engineer. Did you forget to listen to what the users really need the system to do again?”
It is a constant battle. Unfortunately, typically at the end of the project, whoever provides the cheapest next step wins. Fortunately, in this case, the existing systems, with their terrible camera angles and shoddy recording trigger, gave the users exactly what they were looking for. (Note: This is usually not the case.)