Writing a Request for Proposal (RFP or RFQ) is a notoriously challenging document to get right.  If it is not done correctly, it can produce no bids or responses that don't deliver what you need. 

A key thing to remember is that a response to your proposal is often only as good as the RFP itself. Spending time and money in the early stages of a project to ensure that you get the requirements specification right can save you a lot of money, time and headaches in the future.

These steps on writing a successful RFP will help ensure that you always achieve your goals.

Be clear why you are publishing the proposal

A clear understanding of the background to the project and what you want to achieve is crucial for a successful software project. Understanding key drivers behind the project will help bidders understand the catalyst behind the request and what your ultimate aim of the project is.  

Understanding your needs

Try and establish what you need, and what you want - and whether this is possible. This will help you when you come to write your requirement specification.

Making suppliers aware of potential risks, issues and constraints of the project will help bidders to understand possible internal and external factors that may affect success.

Make your objectives SMART

It is essential that you are clear about what you want to achieve.  SMART objectives are a great way to ensure that you quantify what you want to achieve.  SMART is an acronym for;

• Specific - Objectives should specify what they want to achieve.
• Measurable - You should be able to measure whether you are meeting the objectives or not.
• Achievable - Are the objectives you set, achievable and attainable?
• Realistic - Can you realistically achieve the objectives with the resources you have
• Time - When do you want to achieve the set objectives?

Think about ROI not just budget

Low cost often results in a project that is delivered over-time and over-budget, and it is likely to give you a lot of headaches along the way. Try to think in terms of value for money rather than cost.  This will help to keep perspective.  The expression 'if something seems too good to be true, then it is' stands for software development project too.   Low cost quotes tend to cut corners in the early, yet crucial, phases of a project, resulting in a poor understanding of the requirements and an incomplete or inadequate solution. This can result in the project often costing two or three times more than the original quote. 

A common oversight of many RFP documents is that they focus too heavily on 'cost'.  By placing greater emphasis return on investment, you'll get a better idea of whether the project represents value for money.   Ask bidders to quote what they estimate to be your return on investment. This will quickly give you an idea of whether or not they understand the project sufficiently.

Agree your judging criteria

Judging your proposals can become a subjective process at the best of times, especially when you have many stakeholders, each with difference agendas. 

Prior to publishing your RFP it is important to agree what the judging criteria will be. This will help to minimise any bias and give you a more structured approach to selecting a winning supplier. Weighting the judging criteria depending on importance to your business is a good method of ensuing that your choice is well balanced.

As well as the obvious; expertise, price, quality, reputation, security and timescales - you should also consider more intangible criteria, such as; cultural fit, could we develop a long term relationship, have they listened to us and do they have a good understanding of your requirements and overall business.

Make sure you cover all the sections

It is important to cover all the key sections including; background, requirements specification, guidelines, selection criteria, timelines, process and; scope of work and deliverables. Each of these sections may have sub-sections with further detail.

Requirements

This section is the most important part of the document and it usually takes the most time to complete. It is basically your understanding, in writing, of your software requirement. It should be written in precise and explicit language, to avoid ambiguity, of the function and capability required from the new development or system. Essentially, it is the blueprint for what you need in the future.

It is worth spending time and money getting it right. Writing a quality Software Requirements Specification (SRS) is a skilled job and will save you a lot of time, money and headaches if it is done correctly. 

Timelines

This section will explain to companies who want to bid on your RFP how quickly they must act and how long the process may take. It is important that you are realistic with your deadlines - unrealistic deadlines may result in the best companies refusing to take part because they don't have time to respond. Don't ask for proposals for complex systems and only give the bidders a few days to respond.

You should also communicate how long you expect the bidding, evaluation and selection process to last.  You should be clear about key dates, for instance when bidders will be notified of their success, and you should stick to them.

Potential bidders should also be made aware of the overall timeline for the project.  Do you have any key milestones that you need to meet?  What is the ultimate project deadline?  And, can the company bidding meet these timescales.

Decide who to send it to

It is likely that you will already have an idea who you would like to bid for your software contract. If not, you can find potential vendors through word of mouth, professional recommendations, or by searching online.

A key thing to remember is not to limit you list to only 'large' vendors or 'established' companies.  You may find that you get a better response and value for money from smaller suppliers who are more interested in winning your business.

Protect yourself

Before you make your final decision ensure that your shortlist of suppliers are financially stable. Horror stories where companies have liquidated or gone bankrupted half way through a project are all too common, leaving customers with an incomplete system, no Intellectual Property Rights (IPR) or source code and a big hole in your budget. Don't be afraid to ask for their financial accounts for the past three years to check that they will stay in business for the foreseeable future

Owning the Intellectual Property Rights (IPR) of the software is important so your supplier cannot repackage and resell the software that they have developed for you to your competitors at a fraction of the price. Ensure that this contract sets out that upon completion and payment in full you will get all the intellectual property rights and copyright to the source code and database together with regular copies of the source code and databases to protect you against the software supplier disappearing. This is better than an escrow agreement.