A request for proposal (RFP) can be a tricky feat to manage for both the specifier (client) and the bidder (contractor). The objective seems straightforward. The client hopes to receive competitive pricing for the requested hardware and/or services and the contractor looks to provide a bid that will award them the project at a profitable price point where they can be successful.
The Anatomy of an RFP
If we look at a typical RFP for an AV system, there two distinct parts. One consists of the tangible items that can be easily identified like equipment, cables, connectors, rack building, wire pull, and terminations. These are fairly straightforward for contractors to assess in a proposal and equally straightforward for clients to evaluate when receiving the bid responses.
However, when it comes to approaching an RFP involving system programming whether audio DSP or control, it can be much more challenging for contractors to provide an accurate response due to subjective nature of the deliverable. Difficulties arise in defining the requirements and establishing expectations, especially for intangible items like system functionality, user experience, device setup and configuration, audio performance, and support. These difficulties are often a result of the challenge in conveying expectations and requirements during the bid process, which can be in part due to lack of access or input from technology managers and users who can provide the necessary insight.
In principle, both the client and contractor want to achieve a similar outcome. They both strive to satisfy the organization’s need and fulfill the objective for which the system, equipment, or services are intended. And, for the most part, the intentions of the client and contractor are consistent (presuming that each party is upstanding). The client looks to find a reputable contractor who can balance a competitive price point with quality workmanship, reliability, service, and support. The contractor wants to clearly understand the requirements, responsibilities, and expectations of the client in order to provide accurate pricing that they can stand behind for effectively completing the project.
It’s About Trust
This process inherently involves risk and a need for trust on both parties. Many times, when the project goes smoothly and produces successful outcomes for both parties, the result is a fruitful relationship yielding mutual benefit and future opportunities. Unfortunately, there are also times where this process leads to unsuccessful results leaving both the client and contractor at a loss and dissatisfied. This outcome not favorable for either party nor a good reflection on the industry.
How can we approach the RFP process differently to increase the rate of favorable outcomes for both clients and contractors?
As mentioned previously, the traditional approach to the RFP process can be somewhat adversarial. A misalignment in expectations can lead to the agreed upon price misrepresenting actual requirements. This means that each party would then be in a position to vie for their own interest. Rather than working together to achieve the desired results, each party ends up on opposing sides.
Returning to the challenging areas in an RFP that were identified earlier, we should focus on how to address the intangible items, such as system functionality and user experience, and how they would likely yield higher degree of success. Accounting for the “intangibles” will also create a more effective bid process for both clients and contractors. Specifically, these intangible items include device configuration, audio DSP programming, and control system programming.
By addressing the intangible portions of a project and possibly separating the RFP into two independent parts: one for tangible items, e.g, hardware and installation, and one for intangible items, many of the pitfalls of typical RFP and concerns of the contractor could be resolved. A hardware and installation RFP could be provided to contractors whose focus is in that area and different RFP for system functionality could be issued to firms specializing in programming services. The result being a more comfortable, effective process and increased the likelihood of a successful outcome. All parties can work together to focus on their area of expertise and provide give and take rather than finding ways to protect their own interest due to discomfort or misunderstanding.
Regardless of whether programming services are included in a RFP with the entire system or handled separately, it is still important to identify criteria for yielding an effective result.
Specific Requirements
For audio DSP programming, requirements can be defined by specifying the number and types of microphones, echo cancelling for audio and video conferencing, voice lift requirements, presets for room combining, reconfiguration, or specific features, and control points for user operation. Additionally, quantifiable performance criteria can be defined and measured for audio levels. However, the ability to predict room acoustics and environmental conditions and the subjectivity of how the room sounds to others can be challenging to anticipate and assess.
On the other hand, the requirements for system operation and control programming can be a lot harder to define, evaluate, and ensure an effective RFP. There are ways to outline the system operation requirements ranging from a narrative of system operation to a button-by-button description of the user interface design, flow, and system functionality. In the first instance, the narrative can be provided with a reasonable effort by a knowledgeable client, but it remains open interpretation by the programmer who is tasked with implementing it. This could a good thing by leaving the responsibility of how to implement the solution to the experts who can add their insight and experience.
Providing a button-by-button description results in a much tighter scope, but requires the client to have an in-depth understanding of the system functionality and the responsibility that comes along with it. Not only does this require a significant effort and expertise on the part of the client, but it also holds them accountable for spelling out all of the details. In this case, the party defining the description is taking on the lion’s share responsibility of the control programming effort leaving the programmer only the task of coding the defined instructions. With that said, it is more likely that a narrative will be provided than the detailed description, leaving the requirements open to interpretation — and the bid responses significantly varied.
Furthermore, with the rise in IoT functionality and automation, the ability to spell out all of the detailed requirements becomes more critical. However, it also becomes more challenging as functionality is not as much assigned to physical triggers as they are a result of conditions.
The difficulty in spelling out requirements for customized services is clear. Whether programming services are handled in a separate RFP for system functionality or included with the tangible items of hardware and installation in a standard RFP, the challenge of effectively defining and communicating the details still remains an issue.
New RFP Approaches
There is another possible solution to be considered that can address the difficulties in defining requirements for system functionality in an RFP. Through the use of a two-phased approach, with one phase being a consultative arrangement and the other being a implementation phase, a third-party can work directly with the client to define the requirements, specifically spell out the functionality, and receive approval on the programming specification in the initial phase. Once the phase one is complete, the critical deliverable of a defined and approved set of functionality requirements would be available to be used as a basis for an RFP for the second phase of implementation. At this point, a client can decide if they want to continue to work with the provider with whom they worked for the consultative phase or receive competitive pricing for the implementation phase with confidence that the bidding parties have the information they need to provide a confident, accurate proposal.
The two-phased approach provides a collaborative method to defining the functionality details, clearly communicating requirements, and establishing expectations for both the client and party responsible for the implementation. A relationship with a third-party resource, such as an independent programming company, would effectively provide a client with an option for one or both phases. Independent programming companies specialize in interpreting needs, offering solutions, and documenting system functionality details that can provide a basis for accountability for the desired outcome. Additionally, independent programmers can help process the client’s intent, think through all of the options, confirm that the system design and equipment will in fact support their needs, and offer innovative solutions to achieve the outcome for both short and long-term objectives and efficiencies. Programmers are trained to think many steps ahead and can visualize and plan now for what may be needed or requested in the future.
Steve Greenblatt In the end, although the RFP process is meant to provide the client with competitive bids and options for selecting their preferred contractor, there are challenges that can stand in the way of a successful engagement. With an increased effort to focus on defining and communicating requirements for system functionality and programming services, the likelihood of a positive outcome will be greatly increased. Whether it is treating programming services as its own RFP, using a two-phased approach to establishing requirements, and/or working with an independent programming company, the risk for clients and contractors will be lowered, resulting in an arrangement that will be less adversarial and more productive.
Steve Greenblatt, CTS, is president and founder of Control Concepts, a leading provider of specialized software and services for the audiovisual industry. Steve is currently a member of the InfoComm Leadership Search Committee and has served on the InfoComm Independent Programmers Council, Audiovisual Systems Energy Management Performance Task Force, and AV Systems Implementation Best Practices Task Force, and co-authored the white paper Modern Approaches to Control Systems Design.
