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

I’ve toying around with the granular thing, but the suggestion of using a consistent set of top-level items which makes it easy to track among different projects is really good.

@mr_mcd, I’ve always found the row “Testing” is rarely completed as a single project task because so much of it happens as you go.

I will generally add browser testing as a separate row, but often include functionality testing time as part of the total estimate for each feature. This way the budget for that feature caters for going from nothing to it being 100% complete and tested.

However, the amount of times a feature is complete and tested, but a subsequent feature breaks it… really hurts my head.

Some clients will question why they have to pay for you to fix your own mistakes but they would probably also question why they need a project manager etc. The good clients accept methodical testing as vital and want to pay for it so it’s done thoroughly.

Granular – that’s going to be my new word!

@Kenny, I think if in early meetings you have identified that the project is extremely complex, requires very bespoke development or technologies not used before, often making the client realise this for the first time too, it’s a great idea to try and get the client to sign up to an initial paid spec stage. It protects you as an agency, but also is great for the client as it resets their funding and delivery date expectations nice and early.

As a bonus it also allows you to work with the client for a smaller fee/lower risk and determine what type of client they are. If they’re a nightmare through this spec stage it could be an early red flag that means you run away, save yourself a complete headache in the long-run and go win work off some good clients. Either way the client ends up with a spec and you end up better off – everyone is a winner.

@Eleonor, a really good point and something I have encountered before. It should be said, the mega granular breakdown you create is primarily for internal use and perhaps only needs a public viewing if you have to explain to the client why a certain feature is certain price. How you present your estimates to the client is also up to you. As long as you have all the phases, tasks and estimates you can always word it so it uses non-uber technical terminology in your proposal e.g. Solution Design could become Planning and Back-end Development could be called Technical Build etc.