Seriously though, from my work as a freelancer, no is really the right answer - each proposal needs to be tailored to the project. An ecommerce proposal will be very different from a social networking or blogging proposal.
There are lots of templates out there, and there are lots of "build a killer proposal" articles out there too (most of them not very strong,) but when you fall into templating, you're doing what everyone else is doing. What you want is a proposal that stands out from the rest, that shows your expertise.
What I CAN tell you, however, is that a proposal is an agreement, a road map, an outline for exactly what we're going to do. What is blatantly absent in most prop's I'm asked to review, are the following:
Description: Who you are, what you are offering, in brief. ("Companyname offering demonstrated experience in [technologies] for the purpose of [short list]")
Client requirements: This part is almost always missing. Put down in writing what the client expects. "Remember we talked about a blog?" We might have talked about it, but it's not in the proposal. This lays down a clear understanding of what is expected of both parties. Furthermore, this is the first stronghold you will have on change of scope or project creep; define what they want in writing. The goal of this clause: "here are the problems you want to solve." If this part is incorrect, the client should sound off.
Project Framework: Detailed description of ALL tasks to be performed. Make it many pages if you need, create wireframes to graphically describe what you're doing, and most important, be specific. "Install a CMS to allow customer management of data" is vague and can be anything. Any loose ends you leave open are opportunities for it to be interpreted in any way they choose. "A Wordpress based CMS to manage basic front end pages and the blog section of the site, and [some cart] for the management of the ecommerce area of the web site" is far better.
If you're creating programming interfaces, define EXACTLY each step and page view. This is incredibly important. I had a client once ask for a proposal to create a database. He just figured searching and displaying records was automatic, he had no idea that robust programming was required to search and display his back end data, and that user's front end data required a bit of work to get into the database. Every detail, leave no stone unturned.
The goal of this section: Here is how I plan to solve the problems defined above.
Milestones: Although most proposals contain some vague description of timeline, what is often missing are milestones. Milestones can be used to demark payment intervals, but more importantly can be used as short term goals in large projects. Examples might be:
- Present static designs: 5-7 working days
- Install CMS, implement designs into CMS, rough out basic pages, 5-7 working days
- Install cart software, integrate designs into cart, add basic starter set of ten products, 1-2 weeks
- Basic training of usage not to exceed 5 billable hours
- Project complete, remain available for 30 days of basic support without change of scope of this proposal.
What did I miss in the milestones above? :-) The third one should read " . . . and configure cart to connect with the payment processor of the client's choosing." I did that on purpose . . . guess what happens if you leave it out?
"Are you $%45$%ing kidding me? What good is a shopping cart if I can't accept payments? OF COURSE that is part of the deal, do it or you don't get paid!"
Add a clause that states no work on milestones will commence until the previous milestone is approved by the client (and how much time they get to approve.) That last milestone is **real** important. On day 15, client decides "wow, I forgot, I need a forum. Can you throw that in?" The response would be sure, as a separate project. The goal of this section: Define benchmarks of progress so both parties know what to expect.
Scope Definition: Clearly define what is within and not within the scope of this project. It may include anything like color scheme changes on the fly, but anything that requires going back to step one or major revisions of previously completed milestones is considered out of the project's scope. Also state if there are requirements out of scope, indicate all progress will stop and you will provide a revised proposal. Goal of this section: Draw big red lines around the limits of what you're committing to. This is the one HUGE error most developers fail to do. Otherwise you find yourself at this point:
"You know, when we first started I wasn't sure how well you'd do, but I'm just not happy with it. I'm willing to continue working with you but we really need to start over."
Project Timeline: Different than milestones, use specific dates. "6-8 weeks total to commence on acceptance of this proposal. This proposal is valid for a period of 30 days starting from [this date]." Be sure to include a disclaimer that maintaining the project schedule is dependent on client responses to completed milestones, and outline any actions that will be taken should the client fail to meet these requirements.
Project costs: This part they usually get right. :-) State payment terms and periods, as mentioned it's often a good idea to pay by the milestone so if someone decides to ditch halfway through, everyone gets what they expect.
Definitions and legalese: Define property rights "do I own this code now?" Seems obvious, but put it in writing, and include any clauses relating to third party materials (stock photos or open source software, for example.) Define warranty, liabilities, and what you are not liable for. Define the relationship of the parties ("independent contractor, not in employ, client cannot dictate the hours, duration, or location of work"). Define what we do if either party decides to terminate the agreement. Define confidentiality - which becomes important if the client lets someone else log in, look at your code, and start a game of king of the mountain.
HOLY CRAP that's a lot of work! Trust me, as someone who has worked for 50 cents an hour at the end of an open ended agreement, this is well worth it, and once you have the first one you can base subsequent ones off it. The other argument I see is really based out of laziness on the part of the proposal writer: the justification that the client doesn't want to read all this, they won't understand it.
Every client that's seen my proposals has awarded the projects hands down because the attention to detail really shows you know what you're doing, and they have very few questions about what I'm going to do. They just get out of the car, point to the steering wheel, and get in the passenger side. :-)