If you sell equipment as part of your business, those six words, “Just tell me what to buy!” are probably welcome. The client is interested and willing to spend money. For me, as a consultant and design engineer, they are a bit disheartening. Not because I don’t sell equipment, but because they tell me that this client is not aware of the big picture.
Except in the simplest of cases, any kind of media or AV project requires investigation, planning, and discussion. Hardware and software may be a big part, but sometimes the client thinks that’s the whole game. Perhaps this is because it’s something concrete, not abstract.
Anyone who has been doing this a while realizes that a “holistic” approach is usually best. We can help the client to step back and examine what they really need. And what they’re getting themselves into. Many systems have been sold, built and abandoned because they didn’t really do what was needed, or because they could not be maintained.
Holistic means looking at the conditions where the system will be deployed, who will be using it, what is required to keep things running, and what might happen in the future.
Discovery
Sometimes I wonder if I prefer more or less technically savvy clients. The truly knowledgeable ones, like other broadcast or media engineers, are great. They are peers, we can communicate at the same level and have had similar experiences. The truly naive may have some unrealistic ideas but are likely to take good advice. The most difficult might be clients with a bit of technical knowledge, who read product advertising, and don’t fully understand key concepts.
But no matter the client, I almost always have to dig for what they really want. In most cases that means walking back the initial request to find out the intent. What are they actually trying to accomplish? What’s the desired end result? This is particularly true when the client has been doing their own research and already has ideas about products and methods. They may be right, but often there are holes in the plan, or there’s a better way.
There really is a process of interrogation, sometimes called discovery, where those initial ideas get put to the test and lots of blanks get filled in. Some clients get frustrated with this process, which might be when I hear, “just tell me what to buy!” But even if I have a pretty good idea of what they need I’d prefer to finish the process rather than build the wrong system.
Whether discovery happens before money is discussed, or is part of a paid job, depends on how business operations are structured. In many cases I can get some ballpark numbers and do a proposal from a quick assessment. Other times, estimating the project costs will require more work than I’m willing to do “on spec” and discovery should be a paid consulting phase.
If the client balks at that or says that the sales guy at Vendor X already put together a nifty equipment list, you can build what they think they want or maintain that real discovery will get a better result. Or you can decide if it’s worth pursuing at all.
The Basics
As an example, a client says they want a videowall with nine screens. Of course I need to know about the size, the location, and where viewers will be. Is there appropriate power available where the wall will go? What device(s) will provide the content? Where will that equipment be?
But perhaps a nine-screen wall isn’t even the right approach. Maybe a projector would work better. Or direct-view LED. Or the wall should use OLEDs instead of LCD displays. The only way to answer these questions is to understand the intended purpose and expectations. What is the client trying to accomplish overall?
Along with the immediate application, what might change down the road? Can we build in functionality that will be ready for future needs? It can be difficult for clients to imagine what they might want to do, so it’s helpful to offer suggestions about possibilities, based on what you’ve learned thus far.
On the other hand, sometimes the client says, “We don’t know what might come up, so give us everything!” Even if they are willing to pay the price, this almost always results in a project loaded with functionality that will never, ever be used. It may take some work to talk them down, but it’s usually a good idea.
Occasionally I’ll be asked to work on jobs where the potential client has already purchased some gear. That situation may mean finding out what they really want and trying to tailor a design around what they already bought. This is not a situation I like! On the other hand, if they already own some items that can be reused without much difficulty (power amps, for example), I may try to include those rather than suggest buying new.
Beyond The Basics
One of the biggest mistakes I see is when there’s money to build a project, but no budget for upkeep. Sometimes that’s because the client must move from CapEx (capital expenditures) to OpEx (operating costs). Raising money to build something is easy for people to grasp, and easy to explain to stakeholders. Projecting ongoing costs is speculative and not much fun. Sometimes the issue is simply overlooked or forgotten in the rush to do something new.
From my perspective, as someone who does not generally suggest service contracts, the ongoing operational costs for a well-designed system, using good products, are actually quite low. Nevertheless, things do go wrong and the client should be prepared for service and support costs, parts and replacements, if necessary. Even when equipment is under warranty, they may need to pay for my time to troubleshoot and resolve the problem.
Plus, some equipment really should be under an ongoing support contract from the manufacturer. This is especially true for mission-critical or high demand devices (like media file storage). And while extra years of support might be purchased up front, eventually it will need to be renewed. Will the client be ready for that?
(As an aside on factoring upkeep into projects, I offer this excellent article on undersea fiber cable maintenance at https://www.theverge. com/c/24070570/internet-cables-underseadeep-repair-ships. The industry that keeps the whole internet working has the same problems with ongoing costs and a shrinking workforce…)
Personnel are the other critical piece to address. In professional environments this is usually understood and accounted for, but not always. Some organizations may have expertise in certain areas, but nobody ready to take on a new role or technology. For example, a business that primarily has camera operators and editors may not have anyone ready to handle the file management or administration tasks that come with shared storage.
For non-pro projects I want to find out who will be operating the system, what they are expected to do, and whether that’s realistic. Despite manufacturer claims about “ease of use” everything has some level of learning curve. Even the simplest installation can seem difficult to some people, while others may simply have the right kind of mind for understanding technology and will pick it up easily.
Those latter people might be recruited as technical managers, who have some responsibility for the system. In many cases it is critically important that one or more people on site become minor experts. They can help others, keep tabs on conditions, and work with support services. It makes me crazy to get a call for help on something I did not build, and then find that nobody knows anything. Are there drawings? Manuals? When did the problem start? Does anyone know how this normally behaves? Too many things left to chance and the sands of time!
Unfortunately, institutional knowledge often fades when people change positions or leave. It would be nice if an assigned Technical Manager made sure to pass on what they know, but that’s rare in my experience. There isn’t much we can do to ameliorate this, other than providing good documentation and making managers aware of it. Including time for staff training, with anyone interested, can be worthwhile. Engraved rack panels or stickers with your company name might help.
Taking this further, to some degree a system really should be tailored for the expected level of operator ability. More capability usually means more complexity, which means more sophisticated users. Putting a lot of effort into a control system might mitigate this issue in some cases, but it opens another area of potential trouble; bad control system design is one reason for client dissatisfaction and systems falling into disuse.
In other cases, such as running video or audio for a live event, the operators have to be hands-on. So I may look for equipment that’s more intuitive to use and/or with a smaller learning curve. This might mean hardware control panels instead of KVM operation, making use of scenes or presets, choosing reduced menus and control sets, and other options (see my article on Production Switchers at svconline.com/author/eric-wenocur). I have even moved away from some products by favored manufacturers because they were too difficult to use in real life (designed by engineers for engineers). Let’s just say that poor interface design needs its own article.
Moving into the realm of IP-based technology is a big leap for everyone, and it’s particularly risky for clients without sophisticated technical support. Users experienced with many kinds of digital equipment are unlikely to know much about networking, unless it’s what they do. And IT departments within larger organizations may not be ready for the specialized requirements of IP-based transport. If they are used to typical office networks, the bandwidth demands and file sizes of AV can be a surprise, not to mention the reliance on less common protocols, like multicast.
If we—designers, installers, integrators—are capable of building systems using Dante, NDI, and other AVoIP protocols, we may provide amazing functionality, but can it be maintained? Should we think twice about using AVoIP in some situations?
Strategies
What can we do to minimize problems from the start? Here’s a summary list of concepts and actions to keep in mind:
• Put some effort into discovery with the client. Don’t be afraid to challenge their ideas, offer alternatives and explain complications.
• Consider suggesting a paid discovery phase if the project is large or complex.
• Explore future needs and possibilities, but don’t suggest a system with more than the client will ever use (or remember).
• Discuss who will be operating and supporting the system, and keep these in mind when making design decisions and equipment choices.
• Discuss ongoing and future needs for support, upgrades, consumables (batteries, etc.).
• Engage with IT people early if the project will use their networks, or if IT will be expected to provide support.
• Provide thorough documentation to help current and future operators and technicians.
• Factor orientation and training time into the project cost.
