That, interestingly, is what a couple of psychologists tried and succeeded in implementing at Best Buy, of all places. See:
http://en.wikipedia.org/wiki/ROWE
They seem to have been very happy with the results they got from that.
If you want to evaluate results, why measure hours?
I dunno-- saying that you shouldn't measure time spent as long as people get their deliverables done feels like saying that you don't need to track where you spend your money as long as your business is making a profit. Time is a really valuable resource.
Most people suck at time management, and should get better. Most managers have no clue how much (or how little) their team works or how workplace variables (like office layout and team composition) change how people spend their time. Most managers aren't good at guessing what an appropriate list of deliverables for a given full-time employee. If they try to dole out equal workloads to two developers, what happens when the manager screws up on their time estimates? Renegotiation mid-week? How does Dev2 feel when Dev1 gets to go home early? Who gets the bugs/tasks that have risk associated with them? Does SeniorDev get harder/riskier tasks than JuniorDev? Does he get more tasks?
The ROWE concept reminds me of fixed-price bids from my consulting days. To successfully give a fixed price bid with the least risk, you have to do MUCH more careful cost analysis. With a ROWE system, you have to have a pretty perfect handle on the "cost" of the bugs/tasks you pass around (which, with most knowledge work, is nigh impossible).
Startups kick ass because (among other thing) the founding team really cares about what they're doing-- I think it's pretty rare for a founder to say on a Wednesday, "Well, crap-- I finished all of the stuff we said I'd do this week. I'm off to the slopes!". Instead, they say, "I'm on a roll and there is an endless to-do list. Time to hit the next item!".
Don't get me wrong-- I think the punchclock mentality is ridiculous. But I think we're throwing the baby out with the bathwater-- You should measure BOTH.
So you might agree on having a set of bugs fixed, for instance, or agree on getting a piece of functionality implemented. I'm not an expert on ROWE, but as I understand it, the key is that you agree on results which you (as a manager) are satisfied with and which the team (who will produce those results) is satisfied with.
Then, you don't care about how many hours they work. At the agreed time, you expect the result that you agreed on. If it's there, no problem, move on to the next bit of work that needs to happen. If it's not there, then you can sit down with your team and figure out why (but avoid the all-too-easy accusation that "they didn't spend enough time on it").
Apparently this technique (along with a set of workplace practices that actively discouraged managers from trying to figure out whether their teams were actually working or doing something else) worked really well for Best Buy.
Longer-term commitments (we'll release in 6 months with features X, Y, and Z) on software projects tend to be impossible to make accurately or to live up to, so as an engineer it's impossible to really take them seriously or to be held accountable to them.
By making the commitments much smaller and near-term, they're much more reasonable and doable and much more likely to be taken seriously by all parties.