And yeah, low budgets often indicate they won’t go for it, but if the budget is low and you feel after sounding out the project it will require a big ole spec phase, it could possibly be a a case of unrealistic expectations from the client.

If possible work with them a little longer to try and propose more cost effective solutions, or maybe walk away?

If the client was massive the long-term benefits of winning this project were significant, I’d possibly do the requirements work for no charge – but of course it depends on how your business is doing right now, just how much time you think you’d need and how valuable the client could be.

Alternatively I’ve been very honest about this fact with the client and proposed an alternative approach – to be paid to do the requirements gathering and sitemaps, functional specification etc. as a piece of work.

The idea being that this work will need to be done regardless of who the client awards the web project too, and it will also allow the client to ensure they’ll be getting the solution they want and for the best cost possible (given any agency quoting would unusally have a full specification to refer to when estimating)

This not only works for the client but also can work for you. During this phase you can assess if you actually want to work for this client on the web project or not… if they’re difficult during the spec phase, once paid up you can walk away if you want.

But on the flipside so can the client from you, but if you’re smart you’ll use the spec phase to build a rapport with the client so that they hire you for the full job, or at least hire to consult on the hire of a new agency.

As far as factoring in the discovery phase into a web project quote, all you can really do is use instinct and put a number against the phase – if you win the work, the Web Project Manager should then immediately begin to set expectations of the sold hours – if it’s looking like a lot more time will be needed, they should tell the client and try to negotiate more budget – easier said than done but if the client is handled correctly from day one, it’s not as difficult as most think!

To know for certain, you’d need to spend more time getting the granularity of information you’re talking about, but that process could end up requiring a significant amount of time, and at the end of the process you might find that the total budget doesn’t cover it, or that the client opts to go with someone else anyway.

So I’m wondering if there is a way of covering yourself for that initial discovery phase if the result isn’t in your favour, or is that just a cost of business you have to accept?

So when start your time when you start that print stylesheet, and stop it when you switch… it’s a tough thing to stay disciplined at, but if you can manage it until it becomes second nature then you have an excellent additional set of business data to further increase your accuracy!

What I feel really hard to do is not that estimation, as it’s necessary to get the client, no, what is hard for me is to count time spent on the project as it starts : what time is it ? Okay, i start the print style sheet at 11h05. And at 6pm, as I’ve finished the news feature of another client i’m wondering at what time a finished that printing stylesheet this morning…
But it shouldn’t be a problem.

A progress I’ve made in my estimations is including a lot of actions that we allways forget :
- time to do the estimation,
- time to write all those e-mails you’ll send to the client to inform him on the running project,
- time spent to produce the bill, to the check the payments,
- time to do the archive of the project, with a nice illustrated CDbox…
- money spent in printing the specifications provided by the client…

The master key is really granularity, as you explain it, and stick to the estimation to immediatly see that you’re going off what’s planned ands try to correct it asap.

It does seem web project management is full of catch 22 situations though doesnt it!

* The client gets a good idea of each feature will do (and what it wont do in order to define some kind of boundary that can be cited in the case of scope creep)

* A developer can understand that aim of the feature and see any detail they need to in order to build it

* Allow a designer to understand what elements need to be included in that feature

It’s not ideal as it tends to lack a little detail for each party, but when time is precious and you have a load of work on, it serves as a good platform for the client to sign-off and for your team to get started on production…

As for templates, I’m afraid I’d be slapped on the behind by Rawnet.com if I started making mine available to the world ;-)

Luckily I’ve subscribed to your 12 month RSS plan… what a bargain! ;)

On a heavier banknote… I believe clients would generally think you know your stuff and *therefore* spend minimum time on the testing front (caveat: unless you’re doing something outstanding and awesomely new!).

From my past experience ‘learning on the job’ has always added too many hours to justify the price. I’ll let you know when I’ve conquered this catch 22…

Thanks for some very interesting and useful articles.

I am webdeveloper at heart but working in small teams and sometimes freelance I am often faced with doing the estimates myself.

I am rarely sure how much text to write for each feature and how technical I should get.

Therefore I am curious if you perhaps could show how you layout your estimates. Perhaps you have a template document you use or just some basic ideas?

Testing is defintely one that’s often overlooked yet takes up time… I’m now trying to incorporate this into my estimates and schedules as separate line items. Will see how it goes and maybe write an article about it in 12 months ;)

Does anyone else find it hard to get a client to pay for testing I wonder?

Having run my own freelance *thing* I know how hard it is to estimate for a new client… You’ve done a fantastic job with this and I have found myself nodding with a resounding “yes” to all the points you brought up in Part 1.

Thanks for your granular tips, I’ll be sure to double check this list for the next project! (as i am a designer adapting to development).

And I’ll also take note of @mr_mcd’s point on testing, which I think takes up a lot of time when learning/using new technologies.

Great stuff! Thanks again.
Bren