Time Budget Proposal Review

This is just off the top of my head, but here's how I react to your proposal:

1) Setting up Drupal core does not take a huge amount of time. And that is hardly ever the place where I get bogged down. So your 10 hours seems fine to me.

2) As someone above noted, theming can be a black hole. It depends on how much you have to change to get from a base theme to something that looks like their wireframes, and then it depends on how many times they are going to re-hash the implementation and ask you to do it over (which can be a LOT). I have had clients that literally took pixel rulers and measured every element down to the pixel and expected it to be reworked if it was off by even a pixel. If you have a client like that, take your estimate to do it once and multiply it by 2 or 3. And you also have to test across browsers, which is time-consuming. For the small sites I do, I just tell them they need to find a nice pre-existing theme and live with it to avoid going down that rabbit hole. At the very least you want to get them to agree to a 'best effort' that won't be re-hashed over and over. Promises to mimic the current site are likely to lead to LOTS of time fixing tiny things.

3) When you talk about setting up content types and fields, it depends on how well they are defined. I usually end up spending some time figuring out exactly what they need, which often involves going past the wireframes and asking to see the data that needs to go into the new site to be sure you know what kind of data needs to be stored as well as how it needs to be presented. I almost always figure a minimum of 6 hours per content type, and more than that if they're complicated.

4) You threw a ton of contributed modules into one big bucket of 6 hours. I think that where you are way way short. Views alone can take several hours per view to set up, test with real data, and confirm that the client has what they want. A few of the other modules are just 'enable and go', but most aren't. You might easily use up several hours per module to be sure it is configured correctly and then test that it behaves the way you expect with real data. Anything that involves authentication or access control (I see oauth on the list) will take extra work to thoroughly test that it is actually working as it should. And realistically, you will run into modules that have bugs or that won't quite do what you needed them to do and you'll have to either patch them, work around them, or throw them out and look for other solutions.

5) You don't have any estimate for migrating in data from the current site. That is one of the things that is often forgotten or under-estimated. You have to figure out HOW you're going to get data from the old site to the new site, which often involves making sure you can keep them synced up during the period when you're developing the new site. And clients often don't understand their current data as well as they think they do. After you build a site that has places for the data they TOLD you they had you will often find out there are more fields that no one remembered or some data that doesn't fit the pattern you were expecting and you have to stop and sort that all out.

When you get done with an estimate that takes all these things into consideration, it is likely to be much higher than anyone expected it to be (because that's what it actually takes to do those things). The response then would be to see what functionality can be pushed off to a later phase and what modules could be eliminated (at least initially).

I think this looks pretty good to me, other than the issues others have pointed out with Views and some of the contrib modules. I usually break my estimates down into smaller chunks, so no individual item would be more than 10 hours or so. I also break things by feature sets or site sections depending on the requirements, rather than by Drupal's functionality (e.g. Views would be bundled with the functionality they support). On top of that, I have two columns - one for configuration, one for theming, and estimate the hours separately (plus one for custom development if needed).

One other part of your proposal that stands out to me is launching, including configure client web server. I often find working on unfamiliar servers to be a "black hole". I always include a note in estimates that set-up time depends on the server configuration etc. If it's an unfamiliar hosting environment I always need time figuring out how to use the control panel, and getting them to give me SSH access, etc... I would pad that a bit in case there's something about their server environment that causes problems.

I've only been doing this for less than a year so I'm still working things out as I go. The more projects I do, the more accurate I can be with estimating. I don't know if complete accuracy is even possible without spending too much time creating the estimate. I usually find that I'll be over in some areas and under in others, and it usually balances out.