$$ - The Requirements Phase: From RFP to demonstration
Great news! You have identified a need for a new information system, gone through all the right channels and now have the job to get it done. Taking on the task with great gusto, youve already identified your Executive Sponsor [refer to Pulse+IT, Edition #9, page 42] and like a tightly coiled spring, are anxious to get straight into it. But wait... proceed with caution, because this is the time you can set yourself up for success or failure.
When the need to select a new information system arises, a vital early step is a handy document known as the Request for Proposal (RFP). This detailed and (hopefully) well structured piece of writing sets out your requirements from start to finish.
The single most important function of preparing this document, is to determine your requirements for the new system. Well get to that in a moment. There are certain other items that make up the complete RFP. Lets go through them now, with the reasoning behind each.
Start with an overview of your organisation, including some history and relevant parts of the strategic plan. Major projects, past and present, are also useful to cover here. Ask the vendor to demonstrate how they have serviced this type of organisation previously and to supply references that you can contact. It will give you a good idea of whether or not they have any direct experience in the health sector, or your particular type of implementation.
The purpose of your implementation should come next. Give a good description of why it is needed, the problem that needs to be solved (if there is one) and what you expect to gain from it. This section will form the basis for everything that follows, so keep referring back to it when determining your requirements.
Whilst you are going through the writing process, keep in mind that it will be read not only by people in your organisation, but also by vendors and developers who have no knowledge of how your environment operates. Give these people a chance to provide the best response they possibly can, by structuring your document in an easy to read fashion. Use tables, lists and lots of dot points to enable clarity.
Now for the inner workings of your new system. This is often your first chance to really sit down and nut out the essential functionality you intend to deploy. The functionality section of your document is key and you must get as much feedback as you can from your organisation.
Rather than scheduling workshops with various managers, end users and technical people, the one-to-not-very-many approach is faster and far more efficient. Make appointments with department or unit managers who will be users of the new system and ask them to get feedback from staff on requirements before your meeting, splitting up the requirements into essential and desirable. Use these two categories in your RFP also, when documenting requirements. It will give the respondents a guide as to whether their product will fit your needs.
Ensure a small representative party is present at each of these discussions, such as an end-user, team leader and unit manager. This way, you should be able to garner an idea of what type of functionality is most important fairly quickly. Dont forget to include compatibility with other applications, how many users will need to connect and timeframes for implementation in your discussions.
An interesting side-effect from brainstorming in a small intimate group is finding out which issues are going to arise to affect your project. Often, end-users know about other projects going on around about the place and the impacts they are likely to have. Remember, your IT department is not always kept in the loop when projects are in the planning phase, especially if there is external funding involved.
When you are happy that you have spoken to everyone that should be involved, collate the results in a table. During the review process later on, some of these are likely to be removed or modified.
Next, insert a description of current and future hardware environments and operating systems. If your respondents arent able to use your technology platforms, they need to know right from the start.
As for the cost of the system, you will no doubt have a budget in mind, but this is no time to mention it. Its better to get the right solution and then negotiate on price if it doesnt fit with your budget. Nevertheless, you must ask the vendor to supply an estimate of the software package price in the response, so you have some idea of whether there will be any chance of making an agreement.
Now lets move on. Youve done well in speaking to, or getting feedback from, all the people likely to be able to help you with determining the requirements. The RFP document is well-researched, written in plain English and asks only the pertinent questions. Now is the time to check back with your contributors and review what has been written it will be well worth the effort if you can pick up any mistakes or modifications now.
How to release the RFP can offer some uncertainty. If your organisation doesnt have a policy on this aspect already, you may choose to send it direct to a select number of vendors, hand-picked for their reputation to deliver a good result. This is a valid approach and will save you having to trawl through an unlimited number of lengthy responses. However, you also risk missing out on new entrants to the market, or smaller, less utilised vendors that may have just the solution that youre looking for. If you wish to capture all possibilities, you will need to consider placing the RFP on a website and advertising your choice.
Before the responses start to trickle in, set up an evaluation chart. This can be relatively simple to do and keeping it simple is definitely best for this process. Just put all your requirements and other items that need responses (such as technology platforms) into a spreadsheet and supply a weighting next to each.
For example, create two worksheets, label one Responses and the other Scores. Split each worksheet into Essential and Desirable requirement categories. For the Responses worksheet, add the columns Requirement Name, Vendor One Response, Vendor Two Response and so on. Its OK to use their real names as this will be kept confidential. Copy your list of requirements into the Requirement column and add all the vendor responses.
The Scores worksheet is where you do the real work. Again, create a column for Requirement Name and also Weighting, Vendor One Score, Vendor Two Score until all the vendors have been added. The Weighting column is where you note the level of importance for each requirement, which you will already be familiar with from your round of discussions and consultation with stakeholders earlier.
Essential functionality should be given a weighting score of between 3 and 5, 5 being the most essential item. Desirable functionality scores either a 1 or 2, 1 being the least necessary item. Mark these down on the chart in the Weighting column, corresponding with each item of functionality. Next, evaluate each of the vendor responses and allocate a score. For each item of functionality the vendor can fully deliver on, give a score of 5. If unable to meet the requirement at all, score a 0. Rank each individual item and response accordingly. When completed, add totals for the essential and desirable categories separately.
Now you have a convenient, straightforward evaluation chart to assist with reviewing and selecting the successful respondents. Here you may use your discretion to select the three top-scoring vendors. Consult with your Project Sponsor on this. If all vendors scored poorly on the desirable category, you may choose to ignore it completely and concentrate only on the essential functionality section.
Notify the top three respondents that you wish to see a demonstration of their solution. If you have advertised the RFP widely though, you may have some proposals for a custom-built system, not off the shelf software. Which raises another question: To build or buy? But thats a story for another day.
Posted in Australian eHealth