Due to the length of this article, it has been split into two separate but related parts. The first article provides the reasoning behind the proposal style. This part describes the various sections of the proposal structure in more detail.
You may be wondering why I haven't taken down my old article Writing Fee Proposals. After all, if I think this format is better, why bother keeping the old one? I think it's important to remember where you came from, and the things which helped you get there. In addition, there is still relevant information in that article, and who knows, the older format may appeal more to some people.
Now it's time to delve deeper into the new structure, with some concrete examples to help get things moving. In big-picture terms, the document is broken down into two major sections: 1) the first page - this acts as a high level executive summary, and 2) the Appendix - everything else goes here.
Big bold document title
When someone picks up the document, they will know what it is immediately. I always start with the word 'Fee Proposal', but there's nothing wrong with calling it 'Tender' or 'Quote'. I follow with the company name and than what the system is (e.g. 'ACME Website', 'ACME Online Booking System', etc).
Say where supplier & contractor details are located
This is a single line saying that contractor and supplier details are located in the appendix. This information is often put on the front page but I don't believe its value justifies occupying such prime real-estate.
Document purpose
One line describing what the document is about. You can use a standard line like: 'Document purpose: to outline the work & costs involved in undertaking the ACME project'. This will be helpful to anyone picking up the document for the first time.
Cost Summary
Arguably the most important part of the document (at least from a client's perspective). This is where you present what you plan to deliver and what it will cost. At the bottom of the table, you have the project's total budget. The key here is brevity; you should be able to get things onto a single line most of the time. There will be times when it goes beyond one line, for instance; if you're listing specific web pages you intend to deliver (e.g. About Us, Products, etc.)
There are line items which are common to most web projects, these include: creation of wireframes, requirements gathering, integration & customization of the CMS, creation of a specification document, and quality control/testing.
You also need to capture tasks which aren't technology related, but which you spend time on anyway. For instance, people commonly forget to charge for the time it took to create the fee proposal, or the time it takes to generate and send-out invoices. This is time you are spending on the client's behalf, why shouldn't you be remunerated for it?
Some commonly missed items include: client communication (status updates, further requirements gathering, etc), setting up the live hosting environment, bug management and support.
Keep in mind that the person reading the document may not be tech-savvy. Explain things as much as possible, instead of saying 'PayPal integration', expand this to: 'Paypal integration (service used for taking & retrieving online payments).'
Change of Requirements
This section is very important from a supplier's point of view. It sets out the ground-rules for the development process. Scope-creep is known to be a massive project killer, that's why this is the ideal point to make it known to the client what happens if they change their mind. The two points to emphasize are; 1) additional features increase the budget, and 2) that adding features once the project is underway will push-back the delivery date.
I can't stress the importance of having this block on the first page, it is just good professional practice to make these vital points known to the client before the project begins. I also mention that the proposal only covers the cost of features described in this document, and nothing more.
Project Engagement Sign-off
The project engagement sign-off seals the deal between both parties. The head stake-holder from the client's side signs here, as do you. For large projects, it's very risky, and down-right unprofessional to not get this physically signed. For smaller projects, an email from the client is enough, something like this will suffice: "I'm happy with the costings in the fee proposal, please proceed with the project. - ACME"
This covers the contents of the first page. Everything else goes into the appendix.
Introduction
The appendix is split into a number of sub-headings. Begin with 2-3 bullet points describing the over-arching objectives of the project. This will go some way towards demonstrating that you've paid attention to the client's requirements.
The client background section demonstrates that you've been paying attention and care about the client's business. One paragraph will suffice, succinctly state what the business does, perhaps who their target audience is, what their market segment is, what service or product they are known for - that sort of thing.
Technology to be used
This is a good place to make a statement about what programming language you intend to employ. Also, you should mention what database system will be implemented. This information could be significant as there may be third party costs or performance issues the client needs to be aware of (e.g. MS SQL Server has to be hosted on a Windows server and costs more, MS Access only supports so many concurrent users, etc). If a CMS is being used, this is where you would say which one. You should also make a brief statement about what browsers will be supported.
Project Schedule (or production checklist)
Mention that a project schedule will be used to track tasks and resources. When smaller budgets are involved (e.g. 40 hours or less), I tend to use a production checklist instead. This is a checklist of tasks and a percentage marker to indicate the status of the task.
Non-requirements
A fee proposal says what a client will get for their money, but it's just as important to say what they aren't getting. This section goes a long way towards squashing assumptions before they become a problem. For instance; if you're building an online shop, you should say if international purchases won't be supported. Imagine if the client assumed they would be able to sell their goods world-wide, but you haven't coded it that way. All of a sudden you are in a situation where you could be pressured into undertaking a significant amount of unpaid work.
There is another situation where this section is of vital importance. It may happen that during scoping discussions the client brings up a feature they really have their heart set-on. For whatever reason, you decide it can't be done (perhaps for technical reasons, or maybe because of budget). This is a big danger. 3-4 months may pass, and the client may ask "hey, where's the user satellite tracking feature?", you reply "don't you remember, we discussed this and agreed it wouldn't be included?", client: "no". This could be a problem. You would be in a much safer position if you could say "the non-requirements section of the proposal says it's not included".
Contractor & client details
This section holds information about the client's business and contact details. Your information as a supplier goes in here too. There is a degree of personal taste at work here, it's not a big deal to do this differently or to leave it out entirely. I also sneak in some information about the date the proposal was created, and how long it will remain valid for.
Project Team
A short paragraph describing key members of the development team (e.g. a word or two about their qualifications). You could leave this out if you wanted, to a degree it's a matter of personal taste. I like to put this in for the sake of credibility, so your client at least knows they are getting a qualified person for this money, not some kind of code monkey.
Costs
This section doesn't need to be more than half a page. It does however cover some very important points which the client needs to be made aware of.
Change of Requirements - there was brief mention of this on the first page, but it's so important a topic that it bears repeating. Again, you need to spell it out that the fee proposal only covers items described in the proposal document, and that if new features are added, they will cost more and may push out the delivery date.
Budgeting for Additional Features - this is something which is often omitted. As developers we know that not everything will be thought of during the planning phase. Therefore it's important to tell the client to set aside money for unforeseen features they require. As a rule-of-thumb, I tell clients that they will need an additional 10% of the project's total budget in reserve.
Third Party Costs - this helps avoid any surprises. Let the client know in advance if they need to budget for things like hosting, or a SSL certificate.
Payment Stages - in this section you set-out the payment milestones for the project. My personal preference is to take a 20% deposit before the project begins in earnest, than a 70% payment when the project reaches 90% completion, and the final 10% upon sign-off.
Deciding how to set out your payment milestones is a topic in itself, one which is beyond the scope of this article (see Payment Structure on Small Projects if you'd like to learn more).
Terms
My terms and conditions section is relatively short, but this is likely to change on the next large project I do. This is in order to protect myself from clients that willfully disregard SDLC ground-rules established at the beginning of a project.
One of the important points I mention here is that the project won't begin until the start-up deposit is received. Other terms include: how much time a client has to pay an invoice once its sent, CMS licensing information, and 'development staging' of the website.
Development staging means that the site is up live and available for the client to review, but it's not easily accessible to the public (e.g. a place-holder index.html page takes precedence over the default.aspx page). A site is only launched (or taken out of staging) once final payment is made.
Software Warranty
In this section, I describe the warranty I provide with my work. Generally I commit to fixing bugs for free for a period of 6 months after launch. I know some people provide bug fixing for an indefinite period of time, and others that only do it for 3 months. You will have to find a time period that suits you. It is also very important to state just what a bug is, in your mind that may be very clear, but skip this definition at your own peril.
Logging of Bugs - I have a couple of lines stating that bugs need to be reported via a bug tracking mechanism. If you want any hope of getting clients to use your bug tracking software, you must discuss this early on in the project. Even then, it may be an uphill battle getting them to use it.
Content Management System
This section is optional, depending on whether you offer a CMS as part of the project. Nearly all of my private contracting work comes with a proprietary CMS I built called AURON. I have an example screenshot of the CMS in this section, along with a very basic description of what a CMS is. I also make note of the limitations of the CMS, mainly that it has no WYSIWYG editing capabilities.
___
A quick note about document style, you may have noticed from screenshots in this article that my word documents are very plain and unsexy - 'straight meat and potatoes' if you will. I have seen many fancy document templates at companies, branded with the company logo and lots of 'useful' information in the footer.
I understand the reasoning behind this, but I take a different path. The reason why I don't put logos, colored headings, footers with copyright notices, etc in my documents is to make it easier for new people to pick-up the document and run with it. When a person picks-up a foreign-looking document for the first time, they have to make an investment to get their head around it, decide what to ignore and what's of value. This may seem like heresy to a marketing or business person, and I doubt I would get broad support on this topic. I admit there is an element of personal taste/opinion at work here too.
There may be things about my proposal document structure which you don't like, and that's OK; just take the parts you like and adapt them to suit your needs and personal tastes. One strange thing I do is not bother including a table of contents ("sacrilege!" I hear you say), but hear me out. What need is there for a table of contents when a document is so short that you can just flick through it looking at bold headings to find what you want? What need is there for a table of contents now that we have Ctrl+F (i.e. the Windows search dialogue)?
Read part 1 for the background reasoning behind the new proposal structure.
Special thanks to Moin uz Zaman and Petras Surna for providing input and feedback during the development of the new proposal structure.
Subscribe to RSS Feed.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.