7 Ways an RFP Fails
Why is it that an industry focused on communications technologies is sometimes so poor at communicating?
On the surface, it appears we are communicating more than ever. We are overwhelmed by the sheer numbers of emails, tweets, announcements, newsletters, webinars, blogs, etc. It often amounts to so much noise that we don't hear the important stuff, or we shut down the inflow just to obtain some level of productivity.
How each of us filters through the cacophony to get what we need becomes a business survival skill. By necessity, we eventually learn to invest our precious time on those sources that have the most to offer. It reminds me of the wonderful catch-phrase used by Business Communications Review (which spawned No Jitter when it ceased publishing): "The best signal-to-noise ratio in the industry."
More concerning is the poor quality (or the absence) of direct communications that seems to permeate some of the industry's structured processes. This may not be unique or even new, but each of the following contributes toward less than satisfactory results during the RFP and proposal phase:
- Using a generic RFP -- It is ok to base an RFP on a template that provides structure, but if the requirements are copied from some other source as a means of saving time, it will only lead to a poor solution fit and potentially significant confusion that has to be cleared up later.
- Defining requirements that no longer fit the current industry realities -- Why are vendors told they must provide guaranteed on-site response times when almost all issues are fixed from behind a keyboard, which can be anywhere? Even when a physical component failure requires site-work, it is usually a plug-in device replacement, often pulled from client inventory or drop shipped.
- Defining requirements that are based on old ideas and don't represent actual client need -- This includes calling out for features no longer used, such as direct inward system access (DISA), serial calling, or auto-callback calling. Although surely someone out there will have an exception to the rule, asking for unneeded features detracts from determining the best solution fit.
- Requesting enhanced features even though there is no business requirement -- Using a "just in case it is needed later" approach only complicates the design and likely adds costs that could easily be deferred until a true need arises.
- Vendors that don't ask questions -- Assumptions are bad for everyone, leading to over- or under-designed solutions. Especially when a consultant is involved, vendors should ask pointed questions about the opportunity. (Why waste time submitting a proposal that has no chance of winning?)
- Vendors that don't answer questions -- This can be frustrating for the evaluation team, although it ultimately will impact the vendor's chances of winning the award. If the customer makes any assumptions, the unanswered questions can become the subject of scope revisions, change orders, and even contract disputes if not addressed up front.
- Proposals that fail to define a statement of work for the proposed services -- If the first step after award is negotiating from scratch an SOW, it invariably slows down the project and leads to surprises. It is far better for everyone when the vendor submits an SOW that describes the plan, outlines the services included (and, thus, those not included), and the assumptions or conditions of the proposal.
Of course, not all of the communications breakdowns are directly related to the formal RFP / proposal documents. We hear from the vendors all the time that the single most frustrating thing is the lack of feedback, good and bad. The only way proposals and implementations can improve is with knowledge. Just as importantly, the feedback needs to reach different levels of the organization. We had one project where the sales team insisted to their management they had submitted a quality proposal and could not understand why they lost. In reality, the proposal was one of those that failed to address the questions asked, provided irrelevant references, and was under-designed. Such feedback is vital; otherwise, the vendor will blame the results on the wrong things (that darn consultant doesn't like us!) and future proposals may suffer from the same problems.
Many project implementations conclude with a "lessons learned" session. Even when these are conducted without looking to place blame (which seems to be the purpose with some of the participants), it is apparent that the lessons are not always being used to improve the process for the next project. And most "lessons learned" analyses rarely go back to the original RFP and proposal documents. As an industry, we sometimes are very good at repeating the past rather than developing new procedures.
At the same time, vendor feedback to consultants or others writing RFPs can be helpful. Even the consultants can get stuck in a rut, not recognizing in advance a new way of meeting the client's requirements or adding value beyond the initial RFP request. A quality RFP open to alternatives will encourage new ideas instead of defining a prescriptive solution that limits improvements or creative options.
There are many other examples of how ineffective communications hinders the ability to get things accomplished. We could write an entire article just on the challenges of interacting with carriers. However, if we invest the time and effort in improving the quality of our communications, we will improve the end results for both current and future projects.
"SCTC Perspectives" is written by members of the Society of Communications Technology Consultants, an international organization of independent information and communication technology professionals serving clients in all business sectors and government worldwide.