What do we mean by a winning Request For Proposal? Any successful systems acquisition starts with a good RFP. Conversely, a lot of project disasters can be traced back to a less-than-stellar one. When you need a new system, it is the prospect of getting that system up and running that gets you excited. The RFP is laborious grunt work, right?
It is important to realize that an RFP may be grunt work, but it does four crucial things:
• Clearly defines what the system needs to do and why;
• Defines the problem in a way that makes comparing the responses possible;
• Lays out the bid environment in a way that makes the competition fair; and
• Ensures that the specification is broad enough to invite a sufficient level of competition and minimize “no bids.”
While you might be tempted to throw together a quick document and get on with the project, the most likely outcome will be ugly. All too often, the project will have either too few bidders or worse, a project with so many misunderstandings and overlooked items that delays and overruns are the norm.
Here are 12 key points to help ensure your RFP leads to a successful project:
1. No matter who writes it, it is your RFP.
Often, companies will hire a consultant to write the RFP for them. There is nothing wrong with that since most likely this is something your staff does only occasionally, and the consultant does it every day. They bring a great deal of specialized knowledge to the task. That said, remember this is your RFP. When it is all done, the RFP needs to clearly define your goals and needs. Your staff needs to be deeply involved in the process, and not just accept a consultant’s “boilerplate” or standard system specification. The quality of the bids you receive will be directly related to the quality of the RFP that goes out.
2. Do not just say what you need, but why you need it.
Far too many RFPs specify the equipment to be bid without any real insight into your situation, why you need a new system or what you are hoping to achieve. Give your potential vendors that understanding and they may suggest alternatives that provide real value. At the very least, you will give the best vendors a chance to explain why their solution goes beyond the spec to solve your problem.
3. Do not try to redesign the system.
Yes, it is OK to specify the functionality you want in a system. But you need to keep those requirements at a very high level. It is easy to slip into specifying the operational details, and that’s when you move from buying an off-the-shelf product to a fully custom one. For example, I have seen RFPs that specify the functions that get displayed on a right mouse click, or the way the LEDs must work on an access control reader. The impact of that kind of detail is significant; it eliminates some suppliers who would otherwise be qualified, and drives up the costs of the ones who choose to bid. If the vendor changes his product to comply, it increases your project risk — both cost and schedule — and can create real problems down the road as you try to upgrade.
4. Do not write the spec around a single product.
Manufacturers publish A&E specifications for one reason: they hope you will take the easy path, copy their spec and lock the bid in for them. While it might be easy, it is not in your best interest. The writers of these specs may start with a generic description of the product, but they are never done until they have found a series of unique features that only they do and have written them into the spec. If you really need one of those features, great. Otherwise, use their specs for inspiration and write about what you really need, not what they can do.
Of course, the exception to that rule is for add-ons to an existing system. If you have a preference to stay with the existing manufacturer for compatibility reasons, or just because you have had good experience so far, say so. But always structure the RFP to allow a vendor to bid an alternate but compatible solution if they wish. You might just find your preferences are overruled by the advantages of a new product.
5. Forget performance at your peril.
It is amazing how many RFPs go out without a mention of performance. You need to identify the factors that are critical to you, such as alarm response rate, video frame rates and report generation times. You should demand a demonstration on either a test bed or an installed customer site for any spec you believe is important to your mission.
One of my personal pet peeves is the manufacturer that lists its product capacity as “unlimited.” At best, this vendor thinks this is a great marketing ploy to make the system look as big as the market leaders; at worst, it is a deliberate attempt to ignore the clear limits all systems have. In either case, you should never accept that kind of answer in a bid process. Instead, ask for a demonstration. If, for example, you need to store six months of video online, an answer like “limited only by disk capacity” ignores that the system may take three days to run a simple search on that video. If the performance is important to you, find a way to have it tested as a part of the bid process.
In our industry, many component specs are difficult or impossible to compare. One example that comes to mind is the low-light
performance of cameras. Just because you spec a .001 Lux level device, does not mean that all of the proposed devices will meet your intent. There are no accepted industry standards for this specification, and there are so many ways to make a camera spec well (lower the signal output, open the lens iris completely, slow the shutter to the point where an object in motion is unrecognizable, etc.) Instead, insist on a shoot off and test to be sure the device gives you the results you want. Of course it’s not just cameras; there are real differences in the image quality of monitors, the speed of computers, the read distance of RFID badges and the reliability of wireless links. If it’s critical, test it out.
6. Support costs are crucial.
Most major systems come with the option of a support contract. Modern electronic products are pretty reliable, often making the case for a maintenance contract a difficult one. The exceptions are any devices with moving parts, such as hard disks, pan/tilt/zoom mechanisms and door hardware. The other major exception is software. While it is very tempting to pass on a software maintenance contract, it is rarely a good idea for two reasons: First, unlike hardware, software is always a “work in process” — some level of bugs are a given, and there is no guarantee that the important ones will surface during a warrantee period. Second, and more important, software is perishable — it has to be kept up to date with the latest changes in operating systems, other software and computers, or it becomes a liability on the network.
With all of this in mind, there is a good case to be made to ensure that your department budget does not take a big maintenance hit some year by locking down those support costs as a part of the contract.
7. Tie down the expansion costs.
As a rule of thumb, any device in the proposed system that could be sourced from multiple vendors in the future will likely decrease in price as time goes on. Not so with the proprietary gear that forms the heart of many systems. If system expansion is likely over the next few years, you should be able to negotiate a price ceiling for those items for a reasonable period of time. Done now, it could save your company a huge sum as the system grows.
8. Ease of use will be an ongoing expense.
One area that often gets little or no attention is the ease of use of the proposed system. Some are so painfully difficult, that you will forever be paying for additional training, mistakes and low productivity. Any proposed system should get more than a quick demo by the salesperson. They know what not to show you. Instead, plan on your spending at least a few days with a working system without a salesman in sight. Another good source of information will be the references you will ask for from the finalist vendors.
9. Experience is key.
There is no need for you to be a guinea pig, or your project be a platform for on-the-job training. Ask for references of both the installer and system manufacturer for similar sized jobs and with similar equipment. Nothing makes a project go smoother than having done it before.
10. Define your requirements in a manner that makes comparison easy.
When all of the bids are back on you desk, the tough work begins. How do you compare them in a way that is fair? There will be a lot of data to go through, and unless you structured the RFP to make that comparison easy, you could have a huge job in front of you. Try to structure the responses — especially the availability of your desired features — into a yes/no/partial or a numeric response. Do not forget to give the vendor the ability to add comments or clarify a response. They will often have a differentiated product that they need to be able to explain to you.
11. You have to define the pricing model.
Every vendor has its own pricing model: different products, options, license fees and service models. If you do not structure the format of the line items you are looking for, the result will be a mess that is impossible to compare. You must define a table that all bidders will fill out in the same way. Ask for as much detail in the pricing as you think is practical. Forcing a breakout of the various devices and labor items not only gives you some flexibility for scope changes, but it also makes any questionable items obvious and open for discussion. Additionally, give the vendors the ability to add extra charges and explanation, if they feel there are missing items.
12. Put yourself in the vendor’s shoes.
When you have that final draft of the RFP complete, do yourself a favor. Read it again as if you were a vendor that knows nothing about your company or project. Odds are, you will find all sorts of missing information: acronyms that only you know the meaning of, missing basic company data or data about an existing system. You will often also see incomplete descriptions of the desired features or assumptions based on knowing how your company processes work. When that review is complete, you should hand the whole package to someone else in your company, preferably in another department, that has had nothing to do with the RFP process. The questions they come up with will likely save you a lot of pain when you send out the package.
Rich Anderson is the president of Phare Consulting, a firm providing technology and growth strategies for the security industry. A 25-year veteran of high tech electronics, Mr. Anderson previously served as the VP of Marketing for GE Security and the VP of Engineering for CASI-RUSCO. He can be reached at [email protected].
