Sometimes I feel like I learned everything I needed to know about software project management on Monster House.

Monster House is a television show on The Discovery Channel. Five random builders and the host, Steve Watson, perform a "monster" makeover on someone's home in five days. If the builders complete the project, they win $5k worth of construction equipment. So what does this have to do with software project management? More than you might think.

• The show is on a very strict timeline. The builders have five days; the job must be complete by Friday midnight, no exceptions. If the builders don't finish the job to Steve's satisfaction, they get nothing.

• This is true custom building. You won't see any cookie cutter tract home construction here; these guys have to actually sit down and figure out how to build a lot of the crazier stuff – a Viking ship in the back yard, a lighted disco dance floor, a western saloon, etcetera.

• The show uses five different builders every time, with radically different backgrounds and skills. They do try to tailor it to the job somewhat – you'll see two welders on a show with lots of metal work, and plumbers on jobs with fountains. But these guys are absolutely all over the map in terms of abilities and personalities.

• The host is not managing the builders. He lays out the construction plan, and ensures that the builders adhere to it, but he generally does not intervene except in the most extreme of circumstances.

All this reminds me very strongly of every software project I've ever been involved with. You never know what kind of teammates you're going to get, and you never really know exactly what you're building – until you build it. But by God, it better be done on time!

After watching about a dozen episodes of Monster House, one recurring theme emerged: the success of the project is almost entirely determined by how well these five random builders work together. It has nothing do with skill. Teams that communicated well and coordinated their work – with a minumum of friction – invariably succeeded. Teams that argued a lot, and those that broke apart into five individuals... didn't. This is basically the entire premise of the seminal book PeopleWare:

We observe that about fifteen percent of all projects studied came to naught: they were canceled or aborted or "postponed" or they delivered products that were never used. For bigger projects, the odds are even worse. Fully twenty-five percent of projects that lasted twenty-five work-years or more failed to complete. In the early surveys, we discarded these failed data points and analyzed the others. Since 1979, though, we've been contacting whoever is left of the project staff to find out what went wrong. For the overwhelming majority of the bankrupt projects we studied, there was not a single technological issue to explain the failure.

The cause of failure most frequently cited by our survey participants was "politics." But now observe that people tend to use this word rather sloppily. Included under "politics" are such unrelated or loosely related things as communication problems, staffing problems, disenchantment with the boss or with the client, lack of motivation, and high turnover. People often use the word politics to describe any aspect of the work that is people-related, but the English language provides a much more precise term for these effects: They constitute the project's sociology. The truly political problems are a tiny and pathological subset.

If you think of a problem as political in nature, you tend to be fatalistic about it. You know you can stand up to technical challenges, but honestly, who among us can feel confident in the realm of politics? By noting the true nature of a problem as sociological rather than political, you make it more tractable. Project and team sociology may be a bit outside your field of expertise, but not beyond your capabilities.

Whatever you name these people-related problems, they're more likely to cause you trouble on your next assignment than all the design, implementation, and methodology issues you'll have to deal with. In fact, that idea is the underlying thesis of this whole book: The major problems of our work are not so much technological as sociological in nature.

Most managers are willing to concede the idea that they've got more people worries than technical worries. But they seldom manage that way. They manage as though technology were their principal concern. They spend their time puzzling over the most convoluted and most interesting puzzles that their people will have to solve, almost as though they themselves were going to do the work rather than manage it. The most strongly people-oriented aspects of their responsibility are often given the lowest priority.

The other recurring theme – and it's definitely related to the first – is the bad apple syndrome. In a disturbing number of instances, one team member influences the rest of the team so negatively that he poisons the entire project. In these cases, the success of the project hinges on how quickly the team removes the problem team member. The longer they wait, the more likely it is they will fail. Hopefully, this isn't news to anyone. Problem team members is the third entry (ordered by importance) in McConnell's list of classic mistakes:

3. Uncontrolled problem employees

Failure to deal with problem personnel also threatens development speed. This is a common problem and has been well-understood at least since Gerald Weinberg published Psychology of Computer Programming in 1971. Failure to take action to deal with a problem employee is the most common complaint that team members have about their leaders (Larson and LaFasto 1989). In Case Study 3-1, the team knew that Chip was a bad apple, but the team lead didn't do anything about it. The result – redoing all of Chip's work – was predictable.

There's nothing really new here, but it is incredibly compelling to see these crucial lessons documented on camera over and over again, with different people every time. Don't let this happen to your team.