Anti-Pattern #2: Make Customers Wait

The full title of this anti-pattern is "Make customers wait until they can all be satisfied simultaneously", and it doesn't really need much more explanation than that at first glance. This is rather related to "All projects equally late" in some ways, as it's a lack of focus and a failure to prioritise that underlies the problem.

But put simply, this anti-behaviour is turning down an opportunity to deliver finished software now, because there are fixes or features required to satisfy some users left to do. I stress some users, as I don't necessarily mean the minority: I believe that it should be possible to release software, or software upgrades, explicitly for one group of users only, with the clear intention of releasing something else for other groups on another date.

You might ask yourself - as I have - why very bright people; with the best interests of the users at heart; will actively force a large number, even a majority of users to wait for features or fixes that are ready genuinely ready to go and can be delivered right now.

Anti-Pattern #1: All Projects Equally Late

To kick of this little series of software project management anti-patterns, I'll talk about the one I first noticed: "All Projects Equally Late"

It must have been a couple of years ago that I observed a pattern occurring across multiple projects during attempts to "load balance". Sadly, I have seen on many occasion, the project that is on fire (most late) have resources pulled onto it from projects that are within bounds, then - surprise-surprise - these previously comfortable projects run into problems a few months later. The projects that we're on track, having been pillaged of their originally allocated resources, fall behind, and they eventually become equally critical and late, and the cycle continues.

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...