By Ed Cartier, xAssets
ITAK V5 I3
In a recent interview, I was asked if knew of a good Request For Proposal (RFP) template that applied to the selection and acquisition of enterprise IT asset management systems. I told the interviewer that unless any number of companies or organizations have exactly the same needs, budgets and organizational structures, such a template would have no value. I was then asked if I could write an article on how to write an RFP, as it seems to be a task that a number of people struggle to accomplish. Having worked on more RFP’s than I care to remember, and having some thoughts on how to make the process more effective, I agreed.
How to Start
Writing an RFP is not difficult. It is time consuming and requires input from a number of sources. A well constructed RFP will represent a holistic view of your organization’s needs, reflect reality and point you toward a solution that will solve current and future problems. With that in mind, how do you start? The answer is, it starts with the decision to go forward and the commitment of funds to make the acquisition.
Too many organizations skip this step. Preparing an effective RFP, particularly for a comprehensive ITAM solution, will require the input and participation of the IT, purchasing, contracts, finance and logistics organizations. Even an RFP for a simple IT asset discovery and inventory solution will involve groups outside of the IT department. At a minimum you will need to coordinate with the purchasing group. Leaving them out in the beginning will only cause problems in the end.
Beyond that, be considerate of the vendors you want to approach. Each respondent will devote somewhere in the neighborhood of 200 staff hours in preparing a response, and can spend significant resources in creating the documents you may require. Before you start a multi-organizational project, and get a dozen or so companies to devote their resources to your project, get a firm commitment that the funds for the acquisition are in the budget and that purchasing has bought into the project. I have seen too many instances where literally thousands of staff hours were expended, just to find that no funding was available when the RFP review process was begun.
Get Some Buy-in
Once you have the funds committed, figure out exactly what problems or requirements you need to address, and which other departments can benefit from the acquisition. Form a small team to discuss what benefits you all expect to realize from the solution. Have the representatives make a list of the desired functionality and benefits, organized in order of importance, and ask them to identify the really critical requirements. However, just as important as what your team wants the system to do are what it must not do. If not impacting the network, or not installing agents, not being on on-premises application or not requiring a dedicated server are important issues, then those points should be on the list of requirements.
This is also the time to think about how much you want to spend. Although a target cost point is never included on the RFP, think about what you want to pay for the ideal system, how much you want to pay for professional services, maintenance and operating costs. Cost factors such as cloud-computing versus installed software, the level of staffing required to operate the solution, other software requirements, operation on a virtualized or dedicated servers and overall operating and maintenance costs should be considered as applicable.
Next you need to create a master list. Look for common requirements or points of interest, and put them at the top of the consolidated list. Next include the points listed as critical items on your master list. Add optional or “nice to have” requirements that would add value. Get buy-in from the other groups for the master list as they the sine qua non for your RFP. These are the features that any solution considered for purchase must provide.
Do a Reality Check
Before actually writing the RFP, do a little research. Perform some web searches using the critical points on your list as key words and see what comes up. It is easy to ask for a feature that doesn’t exist, or which would require significant customization to implement. If you can’t find any information in a search using your requirements as key words, look at the web sites of companies that show up using a related broader search criteria. Keep track of the potential vendors that seem to meet many of your requirements, you’ll need that list later. If you can’t find some of the features you have listed, then you can either drop them from the master list or give them a low priority in your RFP review. These features also serve as a reality check; if a vendor doesn’t show them on the website, but promises them in an RFP, you may want to see the features demonstrated in a trial period before moving forward.
Creating the RFP – Don’t Go It Alone
This is when it is good to have friend in the purchasing department. Although you may be the end user of the solution and will be responsible for squeezing every dime of benefits from the software, the purchasing person is expert in developing and issuing RFPs. Work with him/her to format the document and include all of the “boilerplate” language. Purchasing can also manage the pre-review details, such as setting timetables for statements of intent to respond, getting the non-disclosure agreements signed and helping you set timetables for the RFP response and review.
That said, don’t make life difficult for yourself when constructing the evaluative questions for use in the vendors’ RFP responses. Use your master list as a guide for creating the requirements, presented as statements such as “The software performs agentless discovery.” Then allow the vendor to commit if they fully comply, partially comply or do not comply, and assign a weight to each. (You do not have to disclose your weighting formula). Remember, the more prose answers you ask for, the more you are going to have to read and the less empirical your evaluation may be.
Some other points. Be clear that you own all of the RFP responses, if this is not already a standard practice. You’re not there to hand back homework. Expect the vendors to have questions, so set a deadline for questions to be submitted and a date that you will respond with answers. Supply all of the vendors with all of the answers, but keep all answers anonymous with regard to origin. Do not feel compelled to disclose who is responding. Be clear that a “short list” will be compiled based on vendor responses, and that not all respondents will be on that short list. Insist on an extended live evaluation of all of the products that make your short list.
Meetings between representatives of responding vendors and your staff or team prior to the RFP review period should be prohibited. Don’t be shy about asking for references and get a D&B report on each of the short list candidates. If they are public look up their 10-K reports on line.
It is more than likely that your purchasing contact will have an approved vendor’s list that you will be expected to use. Past that, remember the “reality check” exercise? Match that list against the approved vendor’s list and work with the purchasing contact to add some likely candidates to the list.
How Long Should The Process Take?
As I mentioned in the preface, no two RFPs are alike, so each one will have different life-span. However, for general planning purposes for an IT asset-related acquisition for a non-governmental entity, figure 8 to12 weeks to get it written and published, 4 to 6 weeks to get the responses back, 4 to 6 weeks for an initial internal review, 2 to 3 weeks for presentations by short-listed vendors, 4 to 6 weeks for the evaluation test and 2 weeks for a final decision. That adds up to 37 weeks, assuming the greater values. Add in summer vacation, key people being on travel and you have 10 months, give or take. Another good reason to make sure the budget is locked in when you start.
But Is It Really Worth The Trouble?
In a word, yes. For enterprise-level software acquisitions, the RFP process allows all interested parties to participate and insures that their needs are at least considered. It requires a high level of due diligence on a system that will at least touch every IT asset in the organization. Management and legal have the comfort of knowing that a high level of due diligence was performed with regard to vendor selection and purchasing can commit that nit struck best deal possible. RFP’s can be a lot of work, but can yield even more benefit.