Today’s post is a followup to the post from last week where we broke down what an RFP is, the process that is followed and what you should put in an RFP. Today we will take a look at what the proposal should have in it that you send in response to an RFP. This post is specific to technology based proposals.

Introduction

There are a number of ways to handle proposals these days from tools that allow you to manage and track the creation, sending and signing of your proposal to writing a proposal in a word processor and physically meeting with your prospective client to review and sign it. What we cover in this post will be agnostic from the method you choose to write and manage the proposal process and instead will focus on what content you should have if you want the best chance to secure the work with the prospective client you are hoping to secure.

Now What?

You have received an RFP or have at least the requirements, now what? If you want to respond to an RFP you need to make sure that you understand exactly what they are asking. If there is any ambiguity in the RFP don’t feel like you can’t ask clarifying questions. In fact, if I have written an RFP and don’t receive clarifying questions from a prospective vendor then I actually question whether or not they really read the RFP and understand what I am looking for from them. A second thing to remember when responding to an RFP is to make sure that if the RFP has any questions you do a really good job of answering them thoroughly.

Your Proposal

Now, the rest of this post applies to both situations (1) responding to an RFP, (2) responding to a list of requirements. The objective of a proposal is to present a case to the prospective client as to why they should choose your business to be their vendor. In order to do this well you have to demonstrate a clear understanding of the problem they are trying to solve and present a reasonable approach that your company can provide as a solution to their problem. I have found that the following sections of contact are critical in presenting this case:

  • Introduction – Here you want to give a short synopsis of who you are. Be sure to include details relevant to the reason you are an ideal choice to do the work they are requesting.
  • Executive Summary – Here you want to try and summarize the problem they want solved and how the solution you are proposing to deliver to them will solve that problem. Keep this short and to the point.
  • Delivery Process – Here you should explain the delivery process that your company follows to ensure the client gets the most value out of your work. If I don’t see a section that explains how a vendor delivers their service I question their ability to do the work so this is important.
  • Solution Outline – This section explains the solution that you are proposing and should contain an overview of the architecture of your solution. This may include a summary of both the application and infrastructure architectures as well as sizing estimates related to those. This should not be a detailed design, rather an overview of what the solution will be.
  • Scope of Work – Here is where you describe what work you will do and what work you will not be doing as a part of delivering the solution that you are proposing. Here you should include how your solution satisfies each of the requirements in the requirement list, both functional and non-functional requirements. You should also include any other design details that you think relevant such as wire frames for a website, a data model, etc… Be careful here of giving too much detail. The litmus test is asking yourself if this will help convince the client that you’re solution is the best solution or not. If it does not do that, than save your time and leave those details to the design phase of work in your project. Also, be sure to include a list of things that are explicitly not things you will be doing, especially if there is any ambiguity in those areas. The goal of this section is to set a boundary around the work that you will be performing so that as the project moves along you can manage
  • Timeline – Here is where you list the key tasks that are required to complete the work. You should also provide an estimate for how much effort each tasks will take as well as an indication of the duration of the project. This is particularly important when your client has a due date for the project. Be sure you propose a completion date that within the clients time frame or give grounds for why the project can’t be completed within the indicated time frame.
  • Payment – Here is where you indicate the cost of the project to your client. You don’t have to go into great detail. What you do want to ensure is included are the key payment milestones so the client knows when you expect to be paid and for how much. I would avoid two payment milestones and instead have three, this way you get paid at the start and in the middle in case the client fails to pay you at the end, you’ve collected two thirds of what they owe you.

The Appendix

The next items should be included in the appendix of your proposal. It’s important to note that just because they are in the index they are still just as important to include. A recent client received a proposal that aligns with the guidance in this post and his first impression before reading it was that it was overkill but when he read it, he realized that each and every section of content was critical to the project and could not be removed, even the appendixes that are described here. It was the thoroughness and quality of that proposal that resulted in our company securing the work.

  • Assumptions Appendix – Here you want to list all the assumptions that you have made in writing the proposal. You should work to confirm the assumptions before submitting the proposal.
  • Risks/Issues Appendix – Here you want to list all the Risks according to likelihood and impact as well as your mitigation plan for them. You will also want to list the known issues that are going to hider your ability to deliver and suggest solutions for those issues to ensure the most success for you to deliver the work being proposed.
  • Dependencies Appendix – Here you should list everything that you need but don’t have control over in getting the work done. Include the name of the party that you depend on for each item and whether or not it has been provided. (NOTE: Assumptions, Risks/Issues and Dependencies are not just important in the proposal phase but should be managed throughout the deliver of the project.)
  • Definitions Appendix – Here you list words that may not be common knowledge for those reading your document and an accompanying definition for each. It is important to realize that you don’t know who will read this document and therefore want to provide these definitions to ensure everything is understandable for all that read it.
  • Acronyms Appendix – This is similar to the Definitions except you list all the acronyms that you use in the document and write out their meaning.
  • Current Third Parties List Appendix – Here you list those companies that you know of which your client has already engaged as 3rd parties. If you need anything from them, it is advised that you stipulate that you will expect your client to interface with their 3rd party suppliers and request the point of contact with your client that you should communicate with regarding the project and dependencies on their suppliers. This is an important commercial boundary that will help simplify everything from politics to communications on the project.

Conclusion

If you take the time to write a proposal that contains these key items you will go a long way to convincing your prospective clients that you are the right person for the job.