Writing Fee Proposals

How to write a fee proposal and knowing what to put in it.

Over the years I have seen a number of different styles used when it comes to writing fee proposals. Generally, the differences come down to personal taste; how much disclosure on costs do you give the client, how voluminous are your terms and conditions, should you put a portfolio of past work at the end of the document, and so on. My ideas on how to create a fee proposal are no more special then anyone else’s, but I have found they have worked well for me. I should say that this format of fee proposal is best suited to web development projects in the range of 40-120 hours in duration. So, you probably wont be winning that big government contract with this template.

With most of the documents I create, a big motivation is to go for maximum ‘bang for buck’ – no one likes reading long documents, so I’m not going to write more then I have to.

I like to start with a Document Purpose section, I do this in nearly all documents I create. If you look at it this way; you wrote the document, so you know exactly what it is, but when someone else picks it up, the first thing they will think is ‘what is this?’ The Document Purpose section can be something as simple as saying “the purpose of this document is to describe the tasks involved in creating The Blue Widgets shopping site. These tasks will then be used as the basis for producing a cost for the project”.



Next I like to have a section I call Purpose of the Website. This is a brief bullet point list of the business case for the website; what its trying to achieve in fairly concrete terms. For instance; ‘Let customers buy Widgets online’, ‘Give customers information about Widgets’, etc. These statements are big picture, they also demonstrate to the client what you think is important about their project. If there is misalignment of ideas, the sooner it comes out, the better.

Client Background is another block I like to put in. Nothing too long, just one paragraph to show the client I have been paying attention and have some basic understanding of what they do – I think this is important (e.g. “Blue Widgets has been manufacturing widgets for over 10 years and sells its products via a number of retail outlets across the country...”).

Another section which some people may or may not like is what I call Technology to be Used. You could say it’s irrelevant, but I like to set-out what programming language the system will be developed in and what database it will use. Probably the most important aspect of this section is technical limitations. And yes, you got it, this is an exercise in ‘covering your ass’. For example, you may make a statement here about what browsers you are going to support, or what CMS you are going to provide.

Arguably the strangest section in my fee proposals is the block called Non-requirements; why would you want to tell a client what you’re not going to do for them? It comes down to avoiding potentially costly confusion. You will find that most arguments in life arise as a result of ‘misalignment of expectations’ (e.g. “you said you were going to do this...” “you promised this...” “I never promised that!”, etc). This section is about nipping-things in the bud before they become problems. For instance; if you are creating an e-commerce site, you may want to say “the system will not support American Express credit card transactions.”

Now we come to the real meat of the proposal; the Project Components. If you’ve read my article on Project Schedules with Google Spreadsheets, you may be thinking that this section looks suspiciously similar to a project schedule, and you would be right. Once the contract is locked in, the project components segment serves as the basis for the project schedule. You have a task description and an hours estimate. The hour estimate is how you derive the cost of the project, and this is the point where some would disagree with my approach. I have had people say to me “you shouldn’t show a client tasks in such detail”, my answer is generally “why, they are paying for this project, shouldn’t I tell them exactly what they are getting for there money?” And yes, I have been questioned by clients on occasion about my hour estimates, but I have never failed to successfully defend my reasoning for an estimate.



There are a few other smaller sections I put into my proposals, but I will cover these quickly since they aren’t as important as the previous sections. I have a paragraph called Change of Requirements – the crux of this is to say “if it's not in the fee proposal, then it's not covered by the project cost”. I have an area called Third Party Costs where I say that hosting is a separate fee. Then I have the obligatory Terms section, which is very short – I just talk about payment terms and how the project will run. I have a paragraph titled Software Warranty where I say how long I will be fixing bugs for free (e.g. 6 months, 9 months, etc). Lastly, I have a Project Engagement section where the client signs to signify their acceptance of the project.

Note: this layout is what I use for my contracting work, but I have used aspects of it at some of the companies I’ve worked at.

Article reviewed by Nicolas Fontaine.