I was an AV integrator in the residential space.  I had a client who wanted a projection screen in their media room.  I called my screen provider and related that I needed a 147”, 16:9, electric projection screen.  I was given a quote and a part number, let’s say it was XYZ123.  I ordered XYZ123.  Upon installation of the screen, we pressed the button and lowered it into the room.  The screen was in a 4:3 format.  I called the screen provider and related the situation.  They asked me for the part # on the box and I replied XYZ123.  They verified the part # on the PO was XYZ123.  They then told me I received what I asked for.  However I did not.  The screen provider translated my needs into a different language, one of parts and SKUs, which I did not speak.  I trusted that translation in placing my order.  Then when I received the wrong part, I was held accountable for their mistranslation of my stated needs into the proper parts under the guise of “you got what you paid for”.

I recently heard a showdown between a prominent AV integrator and a consultant that discussed the advantages of the “Design Build” model where one company designs and builds an AV system and the “Design Bid” model where a consultant designs the system and then puts it out to bid for an integrator to build.

Over the course of 40 minutes, it was apparent that the two participants disagreed on much and agreed on little.  However, one thing they did agree on was the potential value of a “third party verification” system.

Consider if you will a common scenario in the AV integration world.

An AV integrator is engaged to do the installation of an AV system.  They create a detailed scope of work including a hardware list, labor estimates, project timeline, and define system training and handover deliverables.  They then proceed to do the work.  They finish the job and proceed to the handover phase to walk the customer through the system and its operation as well as establish a basis for final sign off and payment.  The customer at this point expresses some type of dissatisfaction with the system, its performance, or its operation.  The integrator’s perspective is that they provided everything within the scope of work.

Enter the third party verification process.

The argument is that if an AV consultant was involved, there is a neutral third party who can come in and mediate.  The consultant comes in and verifies all the equipment, tests the system, and reviews its operation and performance.  This secures the integrator’s final payment, in that there is an objective basis for determining that the system was completed, and the client’s satisfaction in that they get the system that they indeed contracted to receive.

That’s the theory.  The problem is that theory and reality don’t always coincide due to the problem of translation.

There is a great wisdom in the phrase “People don’t buy a drill because they want a drill, they buy one because they need a hole in the wall.”  It is in this wisdom that I suggest third party verification does not assure customer satisfaction.

An AV consultant can come in and verify that a system is performing to specification.  The audio is at 95dB.  The variance in coverage is +/- 3dB.  The projection screen is netting 50 lumens per foot of brightness. And so on.  They can then point back to the specification and the scope of work, showing that these are the parameters that were defined, and that these parameters have indeed been met.  They can show the customer all of these figures on paper in advising them to pay their integrator, and the customer may still be rightfully dissatisfied with the system and its performance.

Why?

They didn’t ask for a system with 95dB, +/- 3dB and a 50 lumen/ft. image.  They asked for a system that would adequately convey the information they needed to communicate in their meetings.  The AV designer (consultant or integrator) translated that into a specification and got a sign off from the customer.

The problem is that the translation of the customer’s needs into the proper parts may have indeed been incorrect to begin with.

A third party verification can never rectify this.

It will only create an opportunity for the integrator to make a case for final payment despite the customer’s dissatisfaction.  The integrator then gets annoyed with the client for not being happy with the end product, the client begrudgingly pays their final bill and is stuck with a system that does not meet their needs and tells everyone who will listen about how their integrator did a poor job.

Mario Porto put his thoughts on this subject in his blog “This System Sucks”.  It’s a good take on part of the problem, including “value engineering”, but it dismisses any accountability on the part of the integrator.  At the end of the day however, integrators are responsible for the results.  You can blame the consultant for a poor specification.  You can blame the budget for value engineering.  You can blame the client for not knowing what they wanted.

When all is said and done, despite all of these issues, the integrator took the work.  They contracted to build the system at the price bid with the information provided.  If the spec is wrong, correct it.  If the budget is too low recommend raising it.  If there is incomplete information, collect it.   If none of these things can be accomplished, decline the job.  That’s it. There’s no complaining afterwards that the keys for success never were provided.

We can’t take the revenue and not take the responsibility.  Not all revenue is good revenue.  Not all jobs are good for all integrators.  We need to be aware of where we will be successful and where we will struggle.  Our goal in any job we take should be a satisfied customer at the end of the project and not justification to get our final check.

We can build technically elegant systems, executed perfectly and they can still be functionally bankrupt.  

A job well done cannot be determined by a third party, but only by one party, the client.

Am I off base?  Tell me I’m right or pick a fight, (you won’t win), in the comments section below.