Skip to page content or skip to Accesskey List.
Search evolt.org
evolt.org login: or register

Work

Main Page Content

How to write a proposal

Rated 4.2 (Ratings: 7) (Add your rating)

Log in to add a comment
(2 comments so far)

Want more?

 
Picture of Ryan

Ryan Mayberry

Member info | Full bio

User since: June 04, 1999

Last login: June 14, 1999

Articles written: 7

Having slick Flash skills and the latest tool for developing dHTML isn't enough to land yourself a client. With more and more competition it is essential that you know how to put together a sound and professional portfolio, if you want your skills to be noticed. The following is an outline that I hope you will find useful. It shows all the major sections that any basic proposal should include, and an explanation of what each section should contain. Use it as a guide to make sure you're including all the information you should.

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.

Submitted by MartinB on July 19, 1999 - 04:25.

One thing to add to/emphasise in this is Scope. Most problems in running a project, billing arguments etc, arise from differences in understanding of exactly how much is covered within the proposal.

Another thing I've seen recommended for the Team listing is to list all (or a juicy selection) of the clients which members of the team have worked for at any point. Note that this doesn't just mean while they've been working for you. If I joined your team, you should list The Royal Bank of Scotland, if it suited the pitchee's profile, as I've worked for them.

login or register to post comments

Proposal Writing

Submitted by cdickson on August 29, 2007 - 18:52.

Another topic that is important to drive home is what are the benefits to the customer of your approach. In fact, it may be better to start with a list of benefits that the customer wants to achieve, and then describe the things you will do/requirements that will deliver those benefits.

People often jump straight into a description of the project and requirements without any discussion of how the customer will benefit from them. A company that helps the customer achieve their goals has a better chance of winning than a someone who merely supplies a list of features.

FWIW, we've got a ton of free articles on proposal writing techniques like these at CapturePlanning.com.

login or register to post comments

The access keys for this page are: ALT (Control on a Mac) plus:

evolt.orgEvolt.org is an all-volunteer resource for web developers made up of a discussion list, a browser archive, and member-submitted articles. This article is the property of its author, please do not redistribute or use elsewhere without checking with the author.