Have you ever met a designer that likes to create time estimates for projects?
The process is fraught with peril no matter how you approach it. Estimate too many hours, the client balks at the price and you need to negotiate to a resolution. Estimate too few hours, the client gladly signs on the dotted line, and you end up taking it in the gut. Hit it bang on the nose once in a blue moon, and take yourself out for a double-tall latte to celebrate, before walking back to the office and rebalancing your books.
Well, I could alleviate some of your estimating stress by telling you that there is no perfect estimate...
...and then raise your blood pressure by venturing that your estimate could deviate as much as four times from your original figures, depending on the scale of the engagement. That is, if you don't properly define what you're delivering, and assess the risks appropriately.
Get out of the "Cone of Uncertainty"
For a quick lesson in estimation, take a page from the software development playbook, which doesn't really differ too much from the large-scale interactive estimation process -- and can be scaled down to apply to most design estimates.
Construx, a well-known software development consultancy here in the Seattle area, has an article on their Web site regarding the "cone of uncertainty" that's essential reading for any designer who is responsible for managing large-scale design engagements.
The "cone of uncertainty" is the zone in any project where a number of interrelated variables -- the details of the work to be done, your process of doing the work, who will be creating the work, etc. -- have not been defined. Any methods of reducing uncertainty can limit "scope creep" (or just plain "lack of scope"), and also create further clarity with your client over shared expectations for the life of the project.
The only way to escape from this scenario is to put all your information out on the table and determine what you don't know -- and get the answers -- before delivering your estimate. That'll be the subject of Part 2.