Validate the RFP & Selection Process
Bias, conscious or unconscious, is inherent in all of us, and in every decision that we make. Even our decisions to become better informed about a topic are effected by our biases. The places we seek information and the sources we use reflect those biases, so it’s hard to even know how to overcome them. But try we must.
In our long experience with reviewing or responding to RFPs for IT, it is apparent that they are typically highly biased to an apparent solution to the business problem and are merely seeking the provider best equipped to deliver it. And to most people, including senior IT staff, that’s what the RFP process is about. Often the calculus is even more simple: it’s about finding the lowest cost solution. Believing that you know what the solution is, and seeking the lowest price, are two of the many reasons why IT projects fail.
If you have performed the preceding steps properly, you are in possession of highly valuable information: you know what problem your business needs to address. What the RFP should then do is seek out the best solution to that problem. The RFP must, therefore, define the business problem, not the technology problem.
We recognise that we are dealing with heresy here, but even describing the existing technology environment will limit and colour the responses which you receive. This can lead to disaster.
Several years ago we were asked to perform a project review of a major government department relocation, which involved a major IT component. The IT department’s lack of engagement in the project steering committee was itself a red flag. More significantly, we quickly discovered that they were now negotiating with their third vendor – the previous two having declined to continue under the prescribed technology limitations. Had the [CEO] not interjected at our suggestion, the relocation would not have met its politically mandated start date.
Much earlier in our career we saw RFPs which, while appearing to be technology neutral, defined the requirements in such a manner as to preclude an innovative technology which we were representing. Many established businesses limited their next generation growth by committing themselves to what would quickly become obsolete and inflexible solutions while more nimble upstarts were hitching their wagons to a new technology paradigm. Some failed completely, sunk by under-performing technology platforms, struggling to perform beyond their design parameters.
Technology prescriptions are not the only things to be avoided in the RFP. Unnecessary mandatory requirements should be carefully weeded out of every draft of the RFP document. Avoid demanding arbitrary deadlines. Aim for flexibility. Encourage innovation, suggestions and new ideas. Government departments bedevil themselves with legal and regulatory prescriptions, in efforts to be fair and transparent, but they do themselves no favours.
Focus on the business needs, not on how they must be met.
Assuming that the RFP is indeed technology neutral, and the business asks are reasonable, or at least not totally prescriptive, then the issuance and response evaluation process must be equally un-biased. This is most easily accomplished by ensuring that the process is managed by a business executive, not necessarily the chair of the Project Steering Committee.
Mid to senior-level business people should have some idea about industry trends, extant industry solutions and knowledge of how the competition is solving similar issues. Industry magazines will feature articles and advertisements. Trade shows and conferences will likewise identify potential solution providers. While we don’t advocate wasting vendors’ time, it is in your best interest to spread as wide a net as possible to seek viable solutions.
Of course, you will only get responses from vendors who recognise that you are open to considering their solution. (Occasionally some bold vendor may propose a non-conforming solution – these should be carefully reviewed for nuggets of gold.)
The IT department will, of course, be represented on the evaluation team. The viability of the technology must be evaluated. Its impact on the department must be considered. But IT should not have a veto. Lots of good technology solutions exist outside of IT’s ambit. Again, this flies in the face of orthodoxy and should not be done lightly, but neither should it be proscribed.
Establishing a scoring mechanism, in advance, by which to evaluate and compare proposals is essential. It is also an art. Elsewhere in our blogs we have opined on the issue of Who Should Write the RFP, and the scoring mechanism. Regardless of how you approach this issue, remember that cost and value are entirely different things. Much more important are the strategic advantage that the solution will deliver to the business and how flexibly it will potentially meet future, unknown, needs. Your enterprise and the prospective vendor will be embarking on a partnership, hopefully for a long time – the size of the dowry should be of minor consequence.
The primary purpose of this series of blogs is to eliminate risk from IT projects. An effective RFP process is an important part of that process. But it is only a part. Assigning too much importance to risk in the RFP evaluation exercise is counter-productive. It may eliminate better solutions and it may provide a false sense of security later on. Select the solution which promises the best business benefits, then negotiate and manage a contract which will ensure its delivery.
Again, while IT contracts require some specialised knowledge, the process of negotiation should be led by a business executive, not a technician. It is a good practice when issuing an RFP to ask the vendor to provide a pro-forma contract as part of their response. Do not sign anything resembling it. Seeing what the vendor would like in the contract provides some sound guidance of the problems they have encountered in the past. These are issues which should be discussed and dealt with in the negotiation process, and in subsequent project and contract management.
The RFP and the chosen vendor’s response will form the foundation of the contract management process. They, along with the contract itself will define the relationship with the vendor. May it be long and harmonious.