Writing Short, Easy to Read Fee Proposals (Part 1)

Creating fee proposals which are quick to write & easy to understand.

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. The second part describes the various sections of the proposal structure in more detail.

A while back I wrote an article called Writing Fee Proposals, since than I have learnt a few things which have led me to produce a new streamlined fee proposal structure (or tenders as many refer to them).

What prompted me to develop a better proposal structure? I had an experience last year where I lost out on a new contract. The client said I didn't get the job because my proposal was "too complicated". Up to that point I had thought being thorough and documenting everything in painful detail was a good thing - I guess not (at least not for everyone).

The biggest driving force behind the development of this new proposal structure was this thought: "people are busy, give them the facts and let them get on with their work". To achieve this goal, the proposal had to be short (generally 4-5 pages), it had to use the military principle B.L.U.F or Bottom Line Up Front (where facts are favored over 'fluff'), and it had to use language which would be universally understandable.

One of the major themes of the new proposal is setting up expectations. You've probably heard someone say "you have to manage customer expectations". Ideally, you want to lay down the ground rules for how a project is going to be run early on. What better point to do this than before the project has even started? I have seen projects in all sorts of trouble because it wasn't explained to a client early on that "this is how we run a technology project at our company". Trying to explain protocols once a project is underway is an uphill battle (not impossible, just harder than necessary).

I personally believe a proposal should tell a client exactly what they are getting for their buck. Seeing a line item like 'development cost' or 'consultancy service fee' is really no help to anyone. Having vague line items like these in a proposal just tells a client you aren't listening and don't recognize their specific business needs. Better line items would be 'development of shopping cart mechanism' and 'consultancy regarding off-page SEO strategy'.

One thing to keep in mind is that this structure is mainly suited to small to medium sized projects (e.g. 20 to 150 hours). I don't believe it is appropriate to use this format for bigger projects. You would risk under-pricing the project since you don't have enough detail to produce good estimates.

Let's take a brief look at the overall structure of the new proposal style (nb. part 2 of this article series goes into more detail about each section).

The First Page

• Big bold document title (e.g. Fee Proposal - ACME Website)
• Subtle note saying supplier & contractor details are in the appendix
• A single line describing what the document's purpose is
• A Cost Summary table (including the project's total budget)
• Change of Requirements block - this sets out important ground-rules
• Project engagement sign-off box - client's signature goes here

All this should fit on the first page, it's like a big executive summary.

Appendix

• Introduction
- Purpose of the Website - briefly state the project goals
- Client Background - demonstrate you were paying attention & care
- Technology to be Used - what language & database will be used
- Project Schedule (not the actual schedule, mention one will be used)
- Non-requirements (saying what isn't included in the project budget)
- Contractor & client details
- Project Team (brief history & qualifications of people doing the work)
• Costs
- Change of Requirements - affect of adding new features mid-project
- Budgeting for Additional Features - prepare client for extra costs
- Third Party Costs - (e.g. hosting fees aren't included in the budget)
- Payment Stages - when milestone payments will be triggered
• Terms - when invoices need to be paid, that a deposit is required
• Software Warranty - describing what happens when bugs are found
- Logging of Bugs - describing how bugs are to be reported
• Content Management System - CMS license details

The most radical change is that I shifted nearly everything into an appendix. If it wasn't absolutely critical for the client to know something straight away, than it got shifted to the appendix. What this meant was that the client could potentially read just the first page and approve the project from that (not advisable of course). From the client's point of view, the first page contains arguably the two most important pieces of information; what am I getting, and how much will it cost? From a technology supplier's point of view, the first page lays forth the most important rules for the project (e.g. how feature additions will be dealt with).

The reason why the majority of the document is in the appendix is because it's hard to say what's most important to a potential client after stating what the costs and deliverables are. Delivery date would be high on the list too, but you can't know that until you've done the project schedule. The appendix contains many sections which probably fall under the category of "who cares" as far as the client is concerned, but nearly everything in the appendix is a bureaucratic must.

With regard to the language used in the proposal, you have to remember that the client may not be that tech-savvy. This means you can't just drop words like 'SEO' without explaining them, you have to at least expand the term to 'Search Engine Optimization'. Being overly technical isn't the only pitfall to watch out for. The single biggest thing which will improve the overall readability of your document is to use short sentences (don't be stingy with your full stops). If you really want to improve your writing, I suggest you look into something called the Flesch Reading Ease Test and Flesch-Kincaid Grade Level Test. Microsoft Word has features built into it which support these metrics. You will have to Google this if you want a deeper explanation since it's beyond the scope of this article. Suffice it to say I use both these tests prior to posting any article to this blog.

After submitting a proposal, it's good practice to make a follow-up call (or arrange a follow-up meeting). Once sent, let at least a day pass so the client has a chance to read the document, than ring up to ask how they went with the proposal (e.g. "hi Bob, it's Tony. I'm just ringing to see how you went with the proposal, check if you had any questions I could help with"). This does a few things: 1) it keeps you at the forefront of the client's mind (a good thing if you are vying for a project amongst other competitors), 2) the client may have not understood things in your proposal (so you have a chance to clarify), and 3) the client may be very busy with their business, so they may not have time to call you - you are proactively pushing along the project. On larger projects, with more granular break-downs of project deliverables, its best to organize a meeting to go through the proposal and explain things step-by-step. That way the client will know exactly what they are getting for their money.



One last thought about clients and how they view proposals. Consider that people have different learning styles (e.g. some are more visual learners, others are auditory learners, etc), the same may be true for how clients relate to different styles of proposals. Certain styles will appeal to some but not others. One client may like a detailed break-down of exactly what they are getting, because they want to know exactly where every dollar is going. Other clients may not care about the fine details of the project; they just want to know what the grand total is. This phenomenon poses a tricky question; do you tailor proposals structures to suit individual client tastes? I haven't tried this out, but there may be merit to the idea if it means the difference between locking in a contract or losing it. Obviously there are some draw-backs, including: 1) it would be a time investment to maintain multiple proposal documents, and 2) how do you even know which structure is best suited to a client you haven't had much time with yet?

Read Writing Short, Easy to Read Fee Proposals (Part 2) for a detailed break-down of each section in the proposal.

Subscribe to RSS Feed.

Writing Short, Easy to Read Fee Proposals (Part 2)

Creating fee proposals which are quick to write & easy to understand.

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.

Super-Quick Project Post-mortems

The project post-mortem you do when you don't have time for a project post-mortem.

Good judgment comes from experience, and experience comes from bad judgment. - Mulla Nasrudin

"Don't you already have a blog article on project post-mortems?" Yes, I do. You may be wondering why I'm writing another article on the same topic. It's not because I have an improved version to share, and it's not because I don't believe in the structure I previously devised, in fact, I don't even like this structure I'm about to describe. But just because I don't like something doesn't mean it doesn't have value. The bottom line is that some form of project post-mortem is better than no post-mortem at all.

This leads me to the question; in what situations is this style of report useful? The answer is when you don't have time to run a thorough debriefing at the end of a project. Using this style of report, you can prepare a post mortem document in under 3 hours. So what's my problem with this format than? It's very subjective, it makes no numeric analysis of the bug log, and it doesn't gather input from the developers who worked on the project. That said, it is super fast to produce, so I begrudgingly bow my head to it.

The report format is loosely based on the PRINCE2 lessons learned report protocol. I recall when the structure was first proposed by the lead project manager, I was quite against it, I said my piece, and then waited for a rubbish report to be produced. To my surprise, the report wasn't rubbish, it was quite insightful. It was a good lesson for me too, in flexibility and 'giving things a chance'. The other area of merit this format possesses is that it has room for describing what went well on a project. All too often people want to focus on the negative, but I think its important to speak about the successful aspects of a project too.

The real beauty of the report is that it was written in about 2 hours. This was done in coordination with the lead project manager. I had tried to get approval from the managing director to get the hours needed to do the more in-depth style of project post-mortem I like, but there wasn't enough time.

Now onto the structure of the report. The original report I produced was a PowerPoint presentation, but a Word document is fine too. Each page is made up of a main title signifying the area under analysis (e.g. Management, or Technical). Most pages have a sub-heading along the lines of 'what went well' or 'what went badly' (I like the straight-forwardness of these titles, there's no sugar-coating). Each page contains bullet points rather than paragraphs of text.

Title page - a title like 'ACME Project Post Mortem' in large font, than the date of the report and the start and finish date of the project.

Management - what went well - on this page you describe good management practices employed during the course of the project. Describe strategies and protocols which were seen to pay dividends. For example: "low number of post-launch bug reports. This indicates effective QA protocols", "team commitment was good - everyone contributed time after hours to finish the project."

Management - what went badly - a description of management practices used through-out the project which caused hardship or didn't come out as expected. For example: "the wrong prototyping tool was chosen for creating wireframes", "formal approvals not taken from client, resulting in lost revenue and rework."

Management - what was lacking - this section gives you a chance to discuss what practices would of helped the project along (i.e. "things would of gone better if we..."). For example: "we should of done technical briefing sessions with programmers before they started to code", "we should of spent more time analyzing the spec to produce better time estimates for the project schedule."

Events - a summary of abnormal events which caused deviations on the project (this could be deviations in budget or delivery date). Examples would be: "delays and disruptions caused by staff turn-over", "delays in project progress caused when entire team was moved to a new office location."

Technical - what went well - describe what technical decisions turned out to be a good choice. Examples would be: "the bug tracking system helped manage and control bug reports", "the CMS we chose for the project was simple to install and configure, and easy to teach the client how to use."

Technical - what went badly - a few bullet points about what technology choices hampered the progress of the project. For example: "a lot of the bugs logged were UI related, indicating a lack of attention to detail", "a XML data-store was chosen for the product catalogue when a database implementation would have been better."

Recommendations - arguably the most important section of the document, you can't get to this until you've laid out the proceeding pages of the report. Here is where you bring it all together, look for overall patterns and pose suggestions for how things can be done better on the next project. Some examples would be: "ensure developers get a technical briefing before they code", "development tools should not be changed mid-project if a functioning tool is already in place."



How long will the report be? Perhaps 10-15 PowerPoint slides for a medium to large-sized project (e.g. 160-300 hours).

As an interesting side-note, you'll probably find that on projects which didn't meet their set objectives, went over budget, or were delivered late, the Management - what went badly section will probably be the biggest. The good thing about this is it somewhat objectively shows management practices are what derailed the project (rather than technical decisions).

The witch-hunt factor. I don't believe the purpose of the post-mortem report is to lay blame and point fingers at individuals. That kind of activity serves no one. At its root, the post-mortem should lead to 'kaizen', a Japanese principle which is all about continuous improvement. Will a post-mortem radically change the processes used on the next project? Maybe, but it doesn't have to. It should at least lead to some improvements, some kind of change for the better, otherwise it's a useless exercise.

Subscribe to RSS Feed.