Marco Dorantes recently linked to a great article by Watts Humphrey, who worked on IBM's OS/360 project: Why Big Software Projects Fail. Watts opens with an analysis of software project completion data from 2001:

Figure 2 shows another cut of the Standish data by project size. When looked at this way, half of the smallest projects succeeded, while none of the largest projects did. Since large projects still do not succeed even with all of the project management improvements of the last several years, one begins to wonder if large-scale software projects are inherently unmanageable.

There's a strong correlation between project size and likelihood of failure. I'm sure that comes as no surprise; it's a lot easier to build a doghouse in your back yard than it is to build the Brooklyn Bridge. What is surpising is the "radical" management solution he proposes for these large projects: trust.

This question gets to the root of the problem with autocratic management methods: trust. If you trust and empower your software and other high-technology professionals to manage themselves, they will do extraordinary work. However, it cannot be blind trust. You must ensure that they know how to manage their own work, and you must monitor their work to ensure that they do it properly. The proper monitoring attitude is not to be distrustful, but instead, to show interest in their work. If you do not trust your people, you will not get their whole-hearted effort and you will not capitalize on the enormous creative potential of cohesive and motivated teamwork. It takes a leap of faith to trust your people, but the results are worth the risk.

If you don't delegate some measure of trust to your teammates, can you even call it a team? Watts also notes that trusting your team is not a substitute for managing them. Trust shouldn't imply a free pass through the "how ya doin'?" school of feel-good non-management. That's what Paul Vick is complaining about in his defense of the Microsoft Shipit award:

As for the rest of [Joel Spolsky's] article slagging the idea of performance reviews, I can only fall back on Churchill's immortal quote: "Democracy is the worst form of government except for all those others that have been tried." There's no question that performance reviews can have terrible effects, but what's the alternative? Give everyone a pat on the head, say "nice work" and send them off to a nap with some warm milk and cookies? This isn't to say that there aren't better or worse ways to do performance reviews, but it seems cheap to dispatch them without suggesting some alternative.

And he's right. In order to manage a project, you have to objectively measure what your teammates are doing-- a delicate balancing act that DeMarco and Lister call measuring with your eyes closed:

In his 1982 book Out of the Crisis, W. Edwards Deming set forth his now widely followed "Fourteen Points." Hidden among them, almost as an afterthought, is point 12B:

Remove barriers that rob people in management and in engineering of their right to pride of workmanship. This means [among other things] abolishment of the annual or merit rating and of management by objectives.

Even people who think of themselves as Deming-ites have trouble with this one. They are left gasping, What the hell are we supposed to do instead? Deming's point is that MBO and its ilk are managerial copouts. By using simplistic extrinsic motivators to goad performance, managers excuse themselves from harder matters such as investment, direct personal motivation, thoughtful team-formation, staff retention, and ongoing analysis and redesign of work procedures. Our point here is somewhat more limited: Any action that rewards team members differentially is likely to foster competition. Managers need to take steps to decrease or counteract this effect.

Measuring with Your Eyes Closed: In order to make measurement deliver on its potential, management has to be perceptive and secure enough to cut itself out of the loop. Data collected on individual performance has to be used only to benefit that individual as an exercise in self-assessment. Only sanitized averages should be made available to the boss. If this is violated and the data is used for promotion or punitive action, the entire data collection scheme will come to an abrupt halt. Individuals are inclined to do exactly what the manager would to improve themselves, so managers don't really need individual data in order to benefit from it.

If this sounds difficult, well, that's because it is. Managing people is unbelievably difficult. Getting code to compile and pass all your unit tests? Piece of cake. Getting your team to work together? That's another matter entirely. Joel Spolsky commented on Paul's post, elaborating on his position:

The Shipit stupidity replaced a genuine form of employees being recognized for shipping a product (being given a copy of the shrinkwrapped box) with a ersatz form of recognition which made it pretty clear that management didn't even know that employees were already motivated for shipping software. And it's a classic case of gold-starism. It was universally derided by the hard core old-school developers that make Microsoft what it is today.

Joel's problem with the Shipit awards was exactly the pitfall that DeMarco and Lister described. Managerial trust relationships take investment and work; facile shortcuts like the Shipit award undermine this relationship. Even if you're only building a doghouse, avoid taking these shortcuts.