Episode 55

“What were they thinking?!” A not uncommon question that we ask ourselves when reviewing RFPs. Public institutions do their best to offer opportunities to vendors with a process that is both fair and transparent. It is a hard task to ensure that the right vendor or solution is selected, a fair opportunity is given to all vendors, and the whole process is timely and efficient. At best you can pick two, but realistically a compromise between the three will be made. I have seen several RFPs with response requirements that are impossible to meet with the information given, then adding insult to injury, responses to questions were equally unhelpful. More troubling are invites late into the bidding process with clear indication that few vendors have shown interest. Technology relevance is a moving target, but procurement is the easiest step. The purpose of this blog is to highlight what we look for in RFPs to help us determine how we write our response.

If I were to broadly categorize all RFPs they would fall into three buckets. The first is a need for strategy and/or architecture expertise. This is most common with organizations that are of a size that do not warrant an architect or Chief Technology Officer (CTO). Though it is not uncommon for organizations to still make this request with the above resources. What naturally follows is the second category which is implementation support. A direction has been set and now it is time to execute. It is perfectly acceptable to procure expertise to implement a particular solution, whether that is custom development or an off-the-shelf solution. The danger in this category is when combined with strategy and/or architecture services. If a vendor sells hammers, everything is a nail. Asking for architecture or strategy advice from such a vendor will lead to the predictable result of your organization owning a hammer. The final category is resources. An organization might have all the above but needs more bodies or a specialist to work on a particular problem. This is an increasingly common request, especially as the demand for technology talent seems to ever increase.

What problem are you trying to solve? This is the question we ask every time we review an RFP or engage with a prospective client. It is a simple question yet answering it can be very challenging. Modern organizations are a mix of people, processes, and technology. Much like the vendor that sells hammers, technology companies are biased towards viewing every problem as a technology problem. But is the problem you are really trying to solve a technology problem? Are your staff willing, capable, and able to undertake the processes your organization has established? Have your processes adapted over time, or is this the way it has always been done? External consultants do not “fix” people, your leaders do. All the external training and workshops in the world will have little impact if the willingness to internalize this information is not mutually shared by both the leadership team and staff. If a consultant develops a process, it will yield value, firstly if it is used, secondly if it is used within the frame of reference it was designed for. One critical piece left to consider is where does the institutional knowledge lie after the job is done? If the knowledge walks out the door with the vendor does this leave your organization in a more resilient state than before the project started? If the answer is no, your vendor will be more than happy to arrange a managed service contract to ensure that the knowledge your organization invested in continues to be available.

Time to write an RFP: what can be done from the vendors perspective? Specify the solution upfront at your own risk. If this approach is taken, I would strongly suggest revisiting the last two paragraphs. What problem are you trying to solve? If the solution does not address the real problem, the solution will create another problem. Was the solution suggested by the vendor who sells hammers? Is there good leadership behind the strategy and architecture plans? Red flags for us are when organizations are asking for a replacement of a product that is relatively new, a request for a specific solution or product with no mention of previous effort or rationale for selection, or a long chain of procurement requests for tasks that could have likely, from our point of view, been handled internally. These red flags will give cause for hesitation in responding or add to our risk modifier for the project.

Another common challenge when responding to RFPs is being given little to no context. Providing your organization’s mandate will help us structure our response to match the tone and language set of your organization; however, there are a lot of dots to connect between a mandate and providing a technology solution. Some RFPs will have little detail on the current state of the technical environment, with no guidance to help vendors determine magnitude. How many total and concurrent users, applicants per period, or data size, location, and store and transfer requirements. A web application for ten users is very different from one for 10,000 users. Likewise, if the request is to replace a paper process with a technology solution, consider the marginal benefit of the replacement. Technology can be great, but it is possible to see no net benefit. Some automation projects could have the cost of development and maintenance exceed the time savings through replacing the old process. If the project’s magnitude is difficult to determine we will have to estimate based on worst case scenarios and if the request is fixed price, the lack of clarity is enough for us to decline to respond.

In a similar, view with magnitude is risk. Some tasks are riskier than others. Replacing a highly interconnected custom developed application is very different from starting with a blank slate. With greater complexity should come greater detail in the description in the current state of your IT environment. If the project seems “off”, we must adjust our risk weighting appropriately, especially for fixed price opportunities.

Consider right-sizing the RFP response requirements with the size of the opportunity. A targeted and well documented proposal can easily take two weeks to write. If the RFP ask is mismatched with the opportunity size, vendors have no choice but to provide a cookie cutter response and inflate the rate to match the perceived risk. On the extreme end if the RFP asks for too much we will not respond.

While this might be a rant more than a blog, I would like to balance the discussion with ending it with an RFP request that I thought was very helpful from the vendor’s perspective. A challenge for organizations is ensuring that vendors can do what they say they can do, with technology changing so rapidly it is difficult to remain technology relevant even for seasoned practitioners. Assuming that your RFP has been able to avoid some of the major landmines from earlier here is a suggestion. Find a very specific problem that your team is looking to solve and ask vendors to provide a short video demonstrating a solution. What I like about this approach is it makes sure that the RFP issuer has spent some time breaking down their high-level problem into consumable pieces that will give vendors valuable insight into the issuers current state environment. Likewise, it forces the vendor to directly demonstrate competency, but also demonstrates that their knowledge and expertise is transferable. This exchange can help both organizations get an understanding of what it would be like to work together. Getting a feel for how working together could be like is invaluable for vendors, as the unfortunate consequence of the RFP process is the sterilization of a relationship into the diluted form of contractual obligations.