Software Project Management Anti-Patterns

Anti patterns are often a great way to sum up the thinking behind a set of patterns by stating a small, highly exemplifying set that sums up exactly what we shouldn't do. In some cases, they are the best or only way, because the patterns we want to communicate aren't quite so easy to elucidate, are too many, or too varied.

I find some aspects of project management to be like this - not because of the way I understand it, probably more the subtlety in communicating it. In particular, the more tacit knowledge gained when learning to project manage is very difficult to communicate. But I'd better give it a try, considering I believe communication to be a significant cornerstone in an ability to project manage...

So, to this end I've been compiling a list of software project management anti-patterns that sum up those things that I vow never to do (again). I suspect that this isn't an exhaustive list, and it's grown since I started writing this post, as I'm now rather attuned to noticing the anti-pattern. These anti-patterns aren't particularly leaned towards any particular methodology such as Lean or Agile, and are probably not even particular to software.

In no particular order:

• All projects equally late
• Make customers wait until they can all be satisfied simultaneously
• Cheat to win
• Give work to the lowest bidder
• Always finish the job, no matter what the cost
• Avoid difficult decisions (the "no decision decision")

The "All Projects Equally Late" anti-pattern is the first one I really noticed about a year ago, so I'll begin with this in the next post. After that, I'll follow with a series of posts on the other anti-patterns, and extend as new ones come along. Hopefully, I won't drag it out quite as long as Lost, but it's been a while since I've had a decent series of things to think and write about, so I'm looking forward to getting into the groove of it.