Main Page Content
How To Write A Proposal
Introduction: Use this section as a high level overview of who you are, why you're offering your proposal, what you're offering and why you're qualified to do so. Most of this material can probably be pulled from the "Who we are" section of your website. Perhaps the person reading the proposal already knows this information, but this 1-2 pages is a reminder so that they have your synopsis fresh in their brain while they read on.
Project Description: In this section you will be explaining what the project is as you understand it. If you are responding to an RFP (request for proposal) then this section is for you to display that you understand what the client's needs are and know of the right approach to reach the best solution. It is important that you divide this section into two main categories. 1) Services - These are the services you will be providing in order to understand scope and accomplish your mission, e.g. requirement workshops, development, training. 2) Deliverables - This is a description of the elements in the project that the client can associate with progression of your work, e.g. status reports, prototypes, support.
Assumptions: In order to provide anybody with a sound solution prior to any real requirement definition process, you're going to need to make assumptions in regards to scope, deployment environment, and any other element not clearly defined in an RFP or your understanding of the client organization. It is important that you list the assumptions you have taken in your proposal so that you can protect yourself (and your quoted price) if the reality of the situation drastically changes the playing field. For example, if you're quoting on the development of a database-driven web site, you may want to make the assumption that all data is already in a database. Otherwise you may find yourself spending valuable time doing data entry which you never quoted for.
Risks and Constraints: If there are any outside factors which you think could present a problem sometime during the life of the project, it is important that you bring them to light right away. This could be possible deployment setback due to relying on an ISP to perform some task, or maybe some other third party indirectly involved in the process. Adding this to your proposal covers your butt and shows that you have experience and know about the pitfalls to watch out for.
The Project Outline: This section should outline your plan and how you want to take the project from beginning to end. Without giving a hard core timeline for the project, you want to give the client an idea of the different stages of the project and what will be happening during those stages. The typical stages of any project are as follows and all are important to note in your proposal:
- Project Initiation: This is what happens right when the project begins and usually involves some sort of meeting with the client and the team (or individual) who will be working on the project.
- Requirement Definition: This is the stage where the team examines the project in full detail and determines exactly what all the technical and functional requirements are going to be.
- System Design: This is when the team develops org charts and technical diagrams illustrating how the system will be developed in order to meet the requirements.
- System Development: This of course is when the real work is done.
- User Training: This could mean showing someone how to update and maintain content on their site or could be as simple as showing someone how to look at their site. In any case some sort of user training should be noted.
- Acceptance Testing: Not to be confused with system testing, this is testing done by the client. This is their time to evaluate whether or not your site does what you said it would.
- Deployment: Whether deployment means uploading a few files or setting up a whole server you should mention it in your proposal since it is an essential part of bringing the project to an end.
Methodology: If there is anything notable about how you approach a project that separates you from the competition you should highlight it in its own section. Perhaps this is where you can mention your particular concern for the 216 colour rule or your understanding of other cross-platform compatibility issues.
Acceptance Criteria: In this section you should outline any conditions involved with the client approving or disapproving your work. Here you will mention what happens if something is done that the client doesn't like and the process that is involved in changing it. You should also touch on any issues involving drastic changes to project scope and requirements. Remember that although you're trying to land a contract it is also important to protect yourself from over-demanding clients.
Similar Projects: Use this section to highlight any similar sites or projects you did for other organizations. You should include what your solution was and any significant elements.
The Team: Your clients know that when they hire a company to make their website they are really hiring a handful of individual people. You should consider providing the resumes of the team members who will be working on the project with your proposal. This way the client will have trust in not only the team, but the individual players as well.
I hope this helps some of you, and remember, just because one of the sections is only going to be a couple of sentences long does not mean you can exclude it from the big picture. Touching on all these issues no matter how in-depth will show the client that you have experience and know about all of the elements that need to be considered no matter how important to the given situation.
