Increasingly, organisations are choosing to outsource some functions or activities rather than develop the necessary capabilities in-house. This outsourcing might take a number of forms—at one end of the spectrum it might involve procuring an off-the-shelf cloud-based software package rather than attempting to build a similar solution from scratch. At the other end of the spectrum it might involve outsourcing a whole function or team to a managed service provider. On projects that implement this type of outsourcing, the artefacts that we’ll need to produce will vary, but it is common for a Request for Information (RFI) and Request for Proposal (RFP) to be issued. These documents help the client organisation to assess which vendors are interested and potentially suitable, whilst also providing the vendors with the opportunity to understand the client’s need so that they can put together a compelling and relevant proposal.
When writing an RFP, there are many considerations that need to be kept in mind. The document needs to outline the high-level solution requirements in a way that is succinct and digestible yet sufficiently detailed so that a vendor can provide a meaningful response. The client organisation will be interested in knowing to what extent their requirements can be met, and will be particularly interested in any areas where vendors may be lacking. For this reason, quite naturally and understandably, many RFP documents focus heavily on requirements.
However, I would argue that the best vendors don’t merely sell products or satisfy a long laundry list of requirements—the best vendors help solve business problems. They work in partnership with their clients to adjust and adapt their offering, and they help anticipate changes in the business environment, which the client may need to respond to. This ethos makes it easier for the client organisation to buy from them as their solution seems more relevant, tailored and future proof. There is a lot we can do to instil this ethos from the very beginning of the relationship, long before any contract is negotiated or signed. By instilling a focus on the root problem and context, the vendor will be able to put forward a more compelling pitch, and the solution is much more likely to deliver the client’s required business outcomes.
Take the RFP document itself. While it is crucial that a list of concise and precise requirements are included, it is also essential that the document includes a relevant introduction and preamble. In particular, there can be a significant benefit in stating precisely what business outcomes are being pursued. This may sound obvious, but I’d bet we’ve all seen RFP or tender documents where this has been inadvertently omitted. Perhaps the real outcome that the client organisation is looking to achieve is to lower costs or to improve service—by stating this, the vendor will know what they are aiming for and can ensure that they show how their solution can help it be achieved.
Ensuring that both parties know these outcomes can help foster a more collaborative relationship from the very beginning. It can help ensure that the right trade-offs are made and help avoid future misunderstandings and misgivings. Including a simple and concise problem or opportunity statement can be instrumental in creating this shared understanding.
As well as having a problem or opportunity statement available, it can also be beneficial to include a succinct summary of the context of the required change and any relevant longer-term business aims. Having this available allows each vendor to illustrate how their solution will deliver today’s required outcomes as well as how the businesses potential future needs can be met. For example, if an organisation is anticipating international growth, a vendor that can illustrate a global presence may have an advantage. Having these factors out in the open provides an opportunity for vendors to answer questions that the client organisation didn’t know they needed to ask.
Summary: What This Means for Business and Business Analysis
As business analysts, it’s likely that we’ll be directly involved in the RFP process—whether we’re on the client-side or the vendor-side. We can add even more value by ensuring that the business outcomes are clearly stated and understood from the outset, and avoid the temptation to reduce the RFP to a silod list of requirements. Ensuring that the document includes enough information about the context of the business and the problem or opportunity being addressed will help ensure that all parties achieve a favourable outcome. If we’re working on the vendor-side, we should have the audacity to ask for this context—it may just clinch the sale!
What are your views on ensuring the RFI and RFP process run smoothly? I’d love to hear from you. Please add a comment below.
If you’ve enjoyed this article don’t forget to subscribe.
This post was brought to you by IBM for MSPs and opinions are my own. To read more on this topic, visit IBM’s PivotPoint. Dedicated to providing valuable insight from industry thought leaders, PivotPoint offers expertise to help you develop, differentiate and scale your business.
I do agree with you. A lot of clients and vendors do not have BA in place which lead to miss leading requirements and vague solutions. In addition, many vendors just sell license instead of solutions.