That’s a great list o paths which lead to death of a team. I think each of them can be a pain in the ass, yet as far as they’re isolated thing should go fine. However the more of that you see in your team the higher are chances of failure.

I would definitely add office politics and permanent emergencies as other factors which lead to the same (sad) end.

Having being thrown into Project Management from a technical role (programmer-analyst), which is pretty common I think (then I discovered it wasn’t my cup of tea), I could summarize in some thoughts what I’ve learned about failure (or how to kill a team without failure):

- Product owners and stakeholders not paying enough attention to how (or which) products are being developed. Sometimes they may tend to think that things are coming along fine while the team might be struggling to deliver something that will, hopefully, meet the business needs. Most of the times they will not, and this is where the morale of the team beggins to be affected (I think having enough quality input to do your work is also a motivation). I consider this to be a difficult situation since it could be just a reflection of deeper organizational issues.

- Poor communication, lack of agreement and lack of feedback among the team members with regard to the project. In other words, in my point of view, not having a stablished shared vision of the project from the very beginning is a sign of failure.

- Not giving enough importance to the people’s strengths and weaknesses. I mean, programmers
acting up as project managers without proper training or couching, having unexperienced team members design critical architectures, programmers trying to do business analysis, project
managers being absorbed by coding activities, just to give some visible examples. According to agile methods We can be generalists at some point but that doesn’t mean every member of the team can do so properly (let’s face it). Depending on the level of tolerance and motivation, I see this situation usually ends up frustrating people.

- And finally, paying more attention to tools and processes over people. Or the contrary, not giving them any importance at all. A project without an appropiate work context is very often disrupted by distracting the team members from the real problem.

Not surprisingly, I think
the smaller a company is the more visible these problems become.