How to write an applications RFI
The writing of a ‘Request for Information’ document is where all successful application projects begin.
Requests for Information (RFIs) are the starting point for any serious software purchase. As such they are the means by which you communicate needs to potential suppliers. Get it wrong and you’ll waste a lot of time. Get it right and you’ll not only stand a fair chance of getting what you need from suppliers that deliver to your specification. Critically, if you can’t get an RFI on four pages then you’re wasting time and effort. It must ask all the key questions, and provide a sensible picture of what you are after - but succinctly. Suppliers will use a RFI to carefully qualify you as a potential customer. Therefore, the more information you supply, the more likely you are to receive a considered response. What you are really trying to establish is whether broad functional requirements can be met by a narrow range of experienced suppliers. Door stop
It is important to understand that an RFI is not an exhaustive feature and function checklist – that may come later. Many people make the mistake of assuming that the work done in compiling a needs assessment or gap analysis provides the definitive list of needs. Until you look at what suppliers broadly offer, you won’t know whether the needs you’re expressing can be delivered. Neither will you know whether your preferred method of operating particular business processes is in line with best practice. What’s more, any supplier faced with a 100-page document that purports to cover every functional detail will use it as a door stop and not consider it worth responding. A good reseller will offer you a menu of suppliers from which to choose. Similarly, if the reseller has expertise in your industry then you’ll be off to a flying start. But if you want detailed information from this source, then expect to pay something for it. There are no free lunches in IT and the reseller will be giving you the benefit of their established expertise. One mistake that many companies make is to assume that SAP and Microsoft should always be on the list. Apart from the fact they operate in different segments of the market (generally the large enterprise in SAP’s case and the mid-range with Microsoft), neither vendor covers every industry segment. It helps considerably if you can explain to suppliers how you perceive your business. In this context you need to say more than “We are an energy utility supplier.” Some years back, the chairman of Manchester United Football Club was asked this question and he responded: “We’re in the entertainment industry.” This kind of description provides context and meaning for suppliers so they can get to grips with how your business is likely to function. During the needs analysis phase, you should have identified core and business- specific processes that differentiate your business. For example, if you operate a four hour return call service, then you need to have processes in place that allow you to meet that target. Armed with that information, suppliers can identify areas where they can assist the business in improving processes. Similarly, where you have identified broken processes, it is important to set out how those processes need fixing and what you propose in terms of the underlying functionality required to rectify the processes involved. This allows you to see how suppliers respond to the requirements and so make a more informed choice. Although the technology is not usually important of itself, that is not true when choosing technical architecture. Many of the applications you’ll see will for instance claim to be ‘internet ready'. What this often means is a browser slapped on a dated product that in turn needs to be extensively customised. That won’t be any good if your objective is to allow your 2,000 employees to self-serve their benefits and holiday entitlement. Similarly, you will need to know whether you are looking for product to configure or customise. The difference is huge, both in terms of project time and the extent to which product will provide a close fit to needs. You need to know about the environment in which the applications will run and the extent to which you may have to build interfaces, or integrations to existing applications. This is important because the degree of interface work will have a direct impact on the build and maintenance effort needed to make the applications work in your environment. You will need to determine mandatory components and spell these out clearly. There is no point for instance in shortlisting suppliers that don’t support the Oracle 9i database, if that is your preferred development environment. What you should not do is fall into the trap of assuming that just because your industry segment uses, say AS/400 plus Sybase, then that is the only way to go. What it will cost
Any RFI that does not ask questions about the potential return on investment (ROI) will lead you to a money pit. Whether spending £10,000 or £10 million, your finance director will certainly want to know the ROI potential. This is notoriously difficult to establish but if you put the effort in, then suppliers will know the game rules. As part of the exercise, an indication of your required time to implementation and rollout is critically important because this helps you establish the broad milestones expected of suppliers. This is also a critical component in an ROI calculation. The only time this doesn’t apply is if you are faced with replacing an existing unsupported application. You need to get detailed information about the proposed supplier that you can present to the finance director for his evaluation and input. He or she will take a great deal of convincing that Joe Bloggs down the road is the right choice if Mr Bloggs is running a hefty overdraft, has only been in business six months or has a court judgment hanging over him for non-payment of Microsoft server licenses. Finally, just remember the cardinal rule stated at the beginning of this piece – keep the whole document to 4 pages.