View Full Version : Quotes - What's your system?

30-04-2008, 01:12 AM
Can people help in discussing their personal schemes and methodologies on how to quote for web design/graphic design/anything really... projects?

I currently use a PERT algorithm

Best Time + (Likely Time * 4) + Worst Time / 6 = Estimate

As i just followed on from a comment of yours...Amanda & Phil....your up :)

30-04-2008, 02:48 AM
Web development:-

- Break project down into user-stories.
- Estimate number of story-points per story
- Estimate velocity (story-point / day)

=> Estimated X days development @ xxx / day.

If the project takes longer due to my estimate being wrong or the client clarifying the spec, then additional time is billed at yyy/day (a discounted rate).

If the project takes longer to complete because of the client (additional features) then the additional time is billed at xxx/day.

A model called "Target Cost". It's sister is "Target Scope" where the cost is fixed but the scope varies (eg you chop features if the project over-runs, and add new ones if there is extra time).


James Smith
30-04-2008, 08:53 AM
Ah the joys of quoting!

For what its worth (and applicable broadly to most service businesses) I have two basis:

1. For things i know roughly how long they will take I offer "menu" pricing, ie fixed fees. If the job is a lot quicker/slower than expected I do sometimes discount it or (with client agreement) add to it if its a failure at their end (ie the records are abysmal in my case). Obviously if its my error, thats my problem. Clients tend to love the certainty of fixed fees and generally its the way to quote for smaller jobs IMO, what you lose on one you gain on another, but you have to get the spec right - ie whats in and whats not and make this clear.

2. For things I really cant estimate accurately I have to charge by the hour or day, but give a range of prices, normally with a price cap. If the project gets big the trick is to keep informing the client of costs and why they have gone up and giving the client the option of scaling back etc. Wacking them with a "surprise" bill at the end is a good way not to get paid.

Also consider ability to pay (Ie the little guy starting out is unlikely to stomach the "full" costs of professional services so if you think they are a good long term prospect you might cut them a deal) and the personality of the client. Some types of people are easier and quicker to deal with than others, and your fees should perhaps reflect that. ie I know I am a probably a nightmare when it comes to something like web design as I want to spot on, others are going to be a lot more laid back.

Hope that helps


30-04-2008, 11:09 AM
My pricing has been built up from experience of how long it takes to carry out most tasks.

I simply add in the following factors into my pricing;

- Estimated time to complete the design concept.

- Estimated time to do revisions based on the average customer and the level of revisions they would ask for.
For repeat customers; Customers beware - the more you chop and change things and change your mind, the higher you are likely be quoted by your designer if they have gotten to know you are like this. For instance if I know a client is the type to keep changing their mind, I quote them higher than my more decisive clients.

- Time spent pulling signed off files together for final delivery.

- If the project was large enough to warrant the quote itself taking me an hour or more to put the quotation and proposal together, this time spent is often also included in the price quoted.

Then I add all the time together x it by my hourly rate, and that's the price they get quoted.


01-05-2008, 02:08 PM
Thanks to you all for the astonishingly good replies! Its much appreciated and very helpful

02-05-2008, 01:48 PM

I've been looking at Agile Web dev for a while, your user stories seems a good/more detailed extension of this.

I'd written a policy similar to target cost or target scope, where you either concentrate on functionality at a higher cost, or save cost based on reducing functionality if there is overrun.

Whilst i love the waterfall model, spec up front, test iterate, as its straightforward and more ordered. Agile seems a more natural approach and the offshoot of it is that the customer has to take responsibility also, which i think in a lot of circumstances can stop the "i said this, i want it done, its your fault developer"

James i agree, i try to give fixed costs where possible, as i know i certainly don't get a car repaired without knowing how much its going to be. I give a guaranteed CAP on the worst case scenario estimate. I also agree on charging differently to people who cant afford it, but have a worthy cause/nice people...also throw in a little charity work every year.

02-05-2008, 05:45 PM

User stories are a part of Xtreme Programming (an agile methodology). A good book I can recommend on agile estimating is the appropriately titled, "Agile Estimating and Planning" (http://www.amazon.co.uk/Agile-Estimating-Planning-Robert-Martin/dp/0131479415/)

Waterfall might be "straight forward" (and at least more familiar to people) but I think it's fundamentally flawed: you define the project upfront when the client+developer know the least about it.

For me Agile is definitely a natural fit: I've never had a web project where the client hasn't changed the spec, or "meant something different", part way through. I think the whole concept of a regular feedback loop makes everyone happier.

With user-stories you can also rank them on priority, so the most important features (for the client) are developed first. That's helpful if you start running out of time / money - at least the most important stuff is done so any features you cut will have less of an impact.