By Cathy Dew
We started this series with an overview with Winning Big with the Right Business Process Analysis Templates: Start Here. Then we provided a handy matrix to determine what business process analysis templates work best based on your project type. From website to Intranet, this article explains Which Business Process Analysis Template Works for What Type of Project.
From there we moved on to focus on specific templates:
Now we are close to wrapping up this initial series with a discussion to put all of this together into a document that will assist you with a purchase of off the shelf software. Of course, we are talking about the Request For Proposal (RFP) in the case where you are looking to purchase a solution from a vendor.
Creating a Solid RFP so You Can Compare Apples to Apples
Let’s start with the assumption that you are going to solicit proposals from software vendors that have existing software solutions for your project focus. Wikipedia says this and a whole lot more about the RFP.
“A request for proposal (RFP) is a document that solicits proposal, often made through a bidding process, by an agency or company interested in procurement of a commodity, service or valuable asset, to potential suppliers to submit business proposals. It is submitted early in the procurement cycle, either at the preliminary study, or procurement stage.”
One of the main purposes of the RFP is to have provide a clear and comprehensive description of your requirements that can be used to evaluate vendor responses in a consistent manner. Ideally you are able to compare and contrast the individual vendor responses to the same set of features, questions and requirements. You want to be able to compare apples to apples. (In case you were wondering, this term was reference as early as 1670.)
Depending on the organization, you may have started your vendor search by issuing an RFI in advance. This is a much more general document and process whose purpose is to collect written information about the capabilities of various suppliers. Learn more on Wikipedia here. The RFI can help you better understand the breadth and depth of vendors in the solution space. Another very effective way to identify possible vendors is to ask colleagues what they are doing – is their solution home-grown? Is t a vendor and if so which one? Ideally you will get three or four good proposals to compare and contrast.
There are lots of variations of the RFP depending on your project focus. For large public agency projects (including government), there is quite a bit of boiler plate language dealing with legal requirements and forms that must be completed. Remember that public agencies must document their process completely so that it is demonstrable and defensible. We’re not going to spend time on these parts of the RFP as it’s a pretty easy copy-paste from previous RFP documents for the organization. Another aspect of the RFP that we are going to skip is technical requirements. These are important and in many cases, will be dictated by your IT department. You can also probably leverage a previous RFP for this section.
The point is to spend the bulk of your RFP energy on functional requirements.
What we are going to focus on is the Requirements section of the RFP. We actually laid the groundwork for this in last week’s blog Business Process Analysis Template #6: Roll up Your Sleeves, Let's Write Requirements. We included several columns to track vendor responses for each detail requirement line item.
Included: Is this feature included in the base product? This means that no special work to configure this capability, it comes out of the box. Ideally the bulk of your features have Yes checks.
Configuration: Does the feature require configuration? Check boxes here indicate that some information must be provided as part of the implementation. This is planned modification by the vendor and means that the feature can be delivered without any changes to the source code. Knowing this can help you plan implementation and may trigger a request to see a demo of the configuration if this vendor makes it that far.
Programming Required: Does the feature require customization, meaning custom developed programming that is just for your situation. Axios Systems posted a good blog “Buyer Beware - Know the Difference Between Customization and Configuration” describing the difference and the potential impact of one versus the other.
You may want to add a column for the vendor to add notes, especially in the case where customization is required. This can help you understand the level of customization.
Another critical component of the RFP is the timeline. Make sure it’s easy for everyone to understand key milestones in the process. This typically includes deadlines for intending to respond, submitting questions, a pre-proposal conference call or in-person meeting, deadline for submitting the RFP, timeframe for evaluation, and target dates for notifying short-listed vendors, interviews and final selections. If you have hard dates for implementation and go live, those should be included in your RFP. The big one for our discussion is the date that the proposals are due. This is the beginning of the evaluation period.
Using the Request for Proposal to Narrow in on a Few Good Vendors
Now that you have the responses to your RFP it’s time to evaluate those responses. Depending on the type and size of your organization the evaluation process can be semi-formal or extremely formal. For large organizations, there will be a scoring sheet, which could be considered another business process analysis template. Public agencies must comply with significantly more stringent processes to ensure that review and selection is fair and defensible. For this discussion, we are going to describe the review and rating of functional requirements for a large complex organization embarking on an enterprise software solution.
Remaining impartial and treating each submission equally requires that you have a dedicated team that will review all proposals.
Ideally you conduct this first level review or all submissions within a week. This helps the review group be as consistent as possible in their scoring. Start by eliminating the proposals that did not meet the minimum requirements – which have been clearly spelled out in the RFP This might include legal requirements or even the format of the response. One of the reasons for highly structured RFP is to make responses as easy as possible to compare. Anyone that doesn’t meet the basic obligations is eliminated.
Most RFPs divide the RFP into section and allocate points per section – with the total point adding to 100. Functional requirements typically count for up to 50% of the overall points. Depending on how complicated you want your scoring algorithm to be you might weight certain features or groups of features more heavily than others. We have seen the full spectrum of schemes, from simple to complex schemes, to allocate points. For reference, other sections include Technical Requirements, Implementation & Support and Contract - Business Terms which account for the remaining 50% of the points.
Once you have a Short-list
Additional due diligence includes reference checking and most likely a structured demonstration of the product. The demo can be directed with a specific set of features that must be demoed or it might be open for the vendor to demo the product in whatever they deem is the best light. Either way, leave ample time for answering specific questions that you have. Ideally the same team that reviewed the proposals will participate in the reference checks and the system demo, which is ideally in person.
Following due diligence, your review team will conduct one final evaluation and hopefully come to a unanimous conclusion on which vendor has the best solution for your project. With a rigorous process that is well-documents you will have confidence in your decision and can to defend any challenges – which sometimes happens with large public projects.
Good luck – may the best party win!