Wednesday, 13 June 2012

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.

At its worst, this behaviour is the determination to prevent any project from succeeding by ripping away people, resources, time, money and focus, to help along the laggards. Baroness Thatcher's government had an education policy like this, called "no-one left behind". A test engineer recently told me that this roughly translates to "no-one runs ahead", which is what you effectively to when you sacrifice the good projects to prop up the bad.

So what do we do to avoid it?

The simplest suggestion I have is to just say the words to yourself, and anyone else involved in the decision making:
Do we want all of our projects to be late, or just this one?
It can seem forthright and provocative, but it's designed to remind us all that there's a consequence to our actions, and that we're trading man power, not conjuring it from thin air.

Once we've removed any illusions and delusions that we can somehow get more done in the same time with the same people, we must prioritise. It is almost never the case that two jobs are equally important, so one of the jobs takes precedence. Is it the one that's on fire, or is it the one that's going well? It's OK to let the job that's on fire slip, so long as you know that it's the best thing to do on balance. But it's the knowledge that's important, rather than the basic reaction to the problem, so sit down and talk about it with all concerned. A mechanical engineer I worked with years ago used to say that we needed to focus on the important jobs, rather than the urgent ones, and stop panicking. In fact, if I think about it, the first time I saw this pattern was all those years ago as a novice mechanical engineer, but I didn't have the experience to recognise it then: late doesn't mean critical!

Analysing return on investment is also very important, because if a project that can make you £5K per month is late, but you've got a £20K per month project going well, don't delay the high earner for the sake of a few bucks now, as delayed earnings actually cost a lot more than equal gained earnings now in terms of ROI. And don't forget that spending more on a project that's now late is going to reduce its effective ROI anyway, so do the sums and focus on marginal costs, rather than sunk costs. I think I'll be revisiting this last point when I talk about "Finish The Job, No Matter What The Cost", when I'll be talking more about how we should always remember that stopping a project should always remain an option.

The last thing I try to remember to do is to offer planning options. I don't just push-back on the request to move work to the emergency project, I'd rather offer options, but each with the consequences to other projects outlined.

Looking at the last point, it seems that the common theme to all of this is to make consequences clear to the people making the decisions! It's amazing how very clever people can appear to live in cloud cuckoo land when it comes to making these decisions, but it's a lack of information and context that makes silly decisions easy to make, and not a lack of clear thinking on the decision maker's part. Even if it feels like teaching your Granny to suck eggs, stating the obvious shouldn't be shied away from, as it's usually overlooking the obvious that gets us into trouble.

No comments:

Post a Comment