The problem with estimating is it involves predicting the unknown so you need to clearly define the process that you're quoting for to reduce the unknown elements.
For instance, your process might be:
- Initial review of existing materials and documentation (0.5 days)
- 1 day workshop to discuss options and proposals (1 day)
- Workshop write up and production of outline specification and approach (1.5 days)
- Review of outline specification with client and approach followed by minor revisions and sign-off (0.5 days)
- Detailed analysis and design with workshops as needed (5 days)
- Write up of final design (2 days)
- Workshop to review final design (1 day)
- Feedback and revisions to final design, no more than three iterations (3 x 0.5 days)
- Final sign off (0.5 days)
In each case you need to state what is needed from them in terms of reviews and you need to state where you're iterating the maximum number of iterations you're going to do. Explain that the reason for this is to allow you to give him the fixed price he wants and that he needs to understand that you're working the way he wants, so he needs to keep his side of the bargain and focus his team on it when they're needed.
Once you've agreed a process you can estimate it fairly accurately. For me there are two key tricks:
1) If you're not sure about how long something will take, break it down into smaller tasks. These are smaller (and easier to estimate) but you'll often also pick up on little things you'd forgotten you'd have to do.
2) If the number seems instinctively wrong (normally too high) review the figures but don't change them unless you honestly think you've incorrectly estimated one of the individual tasks. Our instinct tends to assume everything will go well and skip dull stuff (writing up the workshops? yawn... but it has to happen). Unfortunately in the real world the little stuff has to happen and it never quite goes how you want it so don't pretend it will be otherwise - any estimate or process where you find yourself yourself going "so if all goes well" is a bad one and needs changing.
On top of this you need to add contingency - three sorts, two you must add, one you could:
The first covers time to deal with specific risks which might arise. Go through and list all the things you're not sure about but think might come about and add time to the process.
For instance you think that there is a chance you'll need to do some prototyping. Estimate the likelihood it'll happen, how long it will take if it does then multiply the two together. Perhaps you think it's 50% likely to happen and will take 2 days if it does - add 0.5 x 2 days (1 day) to the estimate to cover that.) Add all these up and add that.
The second is "shit happens" contingency. IT projects are unpredictable and things happen you didn't expect. You can try and figure it all out in advance but you won't manage so try and figure in the major stuff and for the rest add a percentage to cover it. I'd normally go for 15% but that can drop to 10% if you think the process is solid and the customer is good and focused, as much as 30% if you think they're flaky.
The third sort is for the client rather than you. If he says that he can't promise they'll stick to the process as much as you need him to, you say "fine, the process is what I've quoted for but let's have a change allowance". This is his budget to spend on deviations from the process. Say you've added five days for this and half way through he asks for an extra workshop which wasn't in the process. It'll take you a day to have and a day to write up - you say "If you want that it's two days from the five day change budget" - he can either agree or not.
This means that you get your process and he gets the ability to deviate from it without going back to his project board and asking for more money.
Oh, and record all the time you do spend. This allows you to compare what you thought it would take with what you did take so you can improve the estimate but also means that if you overrun you know by how much and you might be able to sneakily add it to the build phase and recoup the money.
One last thing: at some point he's going to say "If it takes less time will charge me less?". The answer is no. A fixed price removes the risk of overspend for him but means that you pick up that risk. Your reward for accepting this risk is the possibility that you make more money if it comes in early but he doesn't get it both ways. Charging him less if it comes in under means you get no benefit if it comes in early but get all the pain if it's late - not fair really?