Carlos Viellas has been watching contractors waste time (emphasis mine):

As I see it, there are two positive incentives: peer pressure in justifying rates, and collecting good contacts and references. In the situations we have been witnessing, those pale next to doing whatever is possible to extend the contract, which more often than not are some incarnation of finger-pointing, back-stabbing or just plain inaction in order to make the project as late as possible. By extending the contract, they can ensure there’s always time to fix the mess created by blaming everyone else but their contracting buddies (those who’ll happily point them to new gigs) and pretending to work harder than everybody else by assuming authorship of other people’s work and ideas, while happily surfing the web all day.

Actually, there’s another positive incentive: Good contractors enjoy doing a good job. Not for contacts or references, but because they just like what they do. I’ve been fortunate to work alongside people like this and they are often highly productive precisely because they want to be productive. As it happens, there’s a very different risk here - if there’s too much obstruction, too much politics, they’ll be the first to leave.

Under good project leadership, time-wasting contractors shouldn’t be recruited, and those who slip through shouldn’t last very long.

Detecting time-wasters during recruitment:

• Check references (amazing how rarely this happens, maybe something to do with HR policies in many places that place a gag on non-HR staff giving references).
• Look for genuine interest in software development - hobby work, professional groups, presentations, conferences attended. If they're not really interested in these things, they probably won't be motivated to do a stellar job on your project either.
• Education and experience. It would be nice if you could learn "Information Security in 60 minutes or less", but, well, you can't. I think this is relevant to time-wasting because there seems to be a correlation. (Recent podcast with AT&T's Ed Amaroso touches on this topic.)

Detecting time-wasters during development:

• Daily Scrum meeting or equivalent. And if people have problems, take them seriously and deal with them.
• Task estimation at an appropriate granularity, e.g. tasks of several days.
• Encourage at least some pairing.
• Real leadership.
• Collective ownership, or at least ensure some people know the entire code base so you can ensure work is reasonable.
• Avoid micromanagement. Nothing will destroy morale faster.
• Moreover, keep people motivated to avoid time-wasting in the first place. (That's a separate post.)