Selecting the right vendor to solve security problems is no simple task. Larger challenges often require us to use a formal request for proposal (RFP) process to make a better choice. This forces us into a sometimes confusing, awkward process with unfamiliar templates. Sometimes these experiences accidentally turn into requests for problems, grinding the effort to a halt.
To avoid creating a bigger problem, invest in clarifying the problem we’re trying to solve and what success looks like before drafting the RFP.
Learning from the accidental request for problems
A few years back, I got called in to help salvage an RFP gone horribly wrong. When I got involved, the chosen vendor and security team were at an impasse — and were exceptionally angry with each other. People were upset. Calls turned into shouting matches, accusations, and ended with more confusion.
When I asked to see the RFP, they handed me a six-page document — including the cover sheet — with a blend of jargon and confusing language. It turns out the company had a junior team member write the RFP because “they had time in their schedule.”
Friction erodes value and destroys trust
By the time I got engaged, they lost about six months and over a $100,000 with nothing to show for the time, money or effort from this million dollar contract. The vague RFP got an ambiguous response that probably looked and sounded good during a quick review, but collapsed under pressure.
The lack of clarity of the problem to solve and expected results created an enormous amount of friction that eroded value, destroyed trust, and burned people out. The more they continued to press forward without circling back to clarify, the more friction they created. You could feel it, too.
And everybody was just tired and fed up of dealing with this, but they knew we needed to get some sort of solution.
What problem were they trying to solve?
So we stepped back and asked: “What problem are you trying to solve?”
It turns out the answer wasn’t as clear as everyone expected. Through the process, though, we determined at least two distinct, related problems. As we focused more on the problems, we naturally explored potential solutions. People screaming at each other a few weeks ago now shared excitement at what was possible.
We were precise and clear in a way that worked for everybody who was involved and anybody that we thought could or would be involved.
Clarity is the fuel for acceleration
What started with asking about the initial problem blossomed into four- to six weeks of diving deeper into what we needed for success. As we worked, the six-page RFP grew into a 43-page description of the problem and the work required to solve it. We replaced fuzzy concepts and jargon with simple terms and examples.
Note: this is not a suggestion to create a 43-page RFP. Here, the mutual desire was to work together, so we moved beyond what a successful RFP addresses and crossed into what we needed to clarify the situation and get the ball rolling.
Normally projects with this much friction end up stalled or failed. In this situation, the vendor and client discovered they needed additional options and services. Clarity not only got the project back on track, but eliminated friction and sped up the effort.
Avoid problems and speed success by clarifying your RFP
If you need to use an RFP to select the right vendor for your situation, consider investing time upfront to clarify your situation. Focus on the problem you need to solve and what success looks like. Pick out a few examples you can offer to better explain what you’re looking for.
Considering your needs before drafting a word helps you make a better decision faster without creating bigger problems.