This is a pretty deep topic with a lot of research in it. There's a book called Software Estimation: Demystifying the Black Art which I'm told is pretty good, though I have yet to read it myself.
As far as completion time and total man hours goes, evidence-based scheduling has given me a lot of success. Quoting myself from another answer:
Long story short, you split up the task, write down how long you think
it'll take to complete each task (including interruptions like coffee
breaks, bosses nagging you, StarCraft, etc.), and then time how long
it actually takes you to complete some of those tasks. It's important
to be blunt, and to include all your distractions -- because that's
part of life as a developer, and it's a realistic factor that
influences the time it takes to finish your work.
Then you can either multiply the average estimated-to-actual time
against the estimated time of the remaining tasks, or you can take the
error factor of your estimations to run a Monte Carlo simulation and
determine the probability that you'll be done your tasks on any given
The end result is a graph that looks like the first one in that link, where the X axis is the finish date and the Y axis is the probability that it's finished:
I can't think of many other significant and measurable resources that'd be involved in software development, but if there are any, say, the cost in dollars of a web service used throughout development, you could probably apply this same technique with different variables to yield a satisfactory result.