The A-Z of Project Management Survival

This term will likely be familiar to anyone that's been on an IT project, it describes the point of sudden realisation that there is a problem on the project and a scapegoat is required.

Really it shouldn't work that way, people should undoubtedly be focussing on solving the problem and delivering the project, but these days it seems that there always has to be a post-mortem and a, consequently, a culprit found.

The meeting may take a number of different forms, or have a number of different titles, like "Process Improvement Workshop", or "Post Implementation Review", but in essence it will turn out to be a drains up blame-fest. You can usually gauge how much of a kicking is going to be dealt out by the seniority of the attendees. There may be even a series of blamestorming meetings to get the story straight before the upper management get told the story.

As you attend more of these meetings, you will witness people who have never moved quickly in their lives suddenly acquire the speed and adaptiveness of gazelles being pursued by a cheetah and reknowned trouble-makers will become strangely slippery, as if lubricated with some kind of advanced silicone compound.

Best go prepared to these kind of meetings, because the black spot will need to be finding a home, and you'd be advised to make sure it doesn't unfairly land on your lapel. Of course, if you are a Good Guy and have followed the advice in this guide, you will already be well equipped and have nothing to fear.

At the meetings, watch out for the phrases, "This isn't intended to be a witch-hunt", and, "We're not looking for a scape-goat here".
It is, and they are.

Labels: B, Blamestorming

The basic rules of prioritisation tell you what is important, what you should do next, what is really important to concentrate on. The butterfly doesn't follow these rules. They flit from flower to flower on a whim. Quite like the flip-flop, this change of direction can often be as a result of a conversation but it just as easily be something random or forgetful in the nature. Sometimes butterflies just aren't very organised. The combination of a flip-flip with a butterfly can be a dizzying journey through madness.

Butterflies often follow what they perceive to be important. This can often be what they think will bring them the greatest glory, the topic du jour of senior management, something that will make them sound clever. But usually its just the last thing to pop into their head.

There isn't that much positive to say about the butterfly other than: if they are chasing you for something that you haven't done yet, it usually very easy to distract them with something bright and colourful. Like maybe a new pen.

Labels: B, Butterfly

The Bermuda Triangle is a very real place for projects, and probably the most precarious location on the high-seas of Software Delivery. Many projects, large and small have perished there – make it your business to ensure your project does not suffer this fate.

There are three main factors affecting your ability to deliver your project:

• Timescale – how long have you got (phases, go-live, drop-dead date)?
  
• Resources – what do you have available to you (people, money, kit, etc.)?
  
• Scope – what do you need to deliver?
  

Consider these factors as three points on a clockface, at 12 O’clock, 4 O’clock and 8 O’clock respectively. Draw lines between the points. Now, the area enclosed by this triangle represents the capacity of your project to deliver; your project’s Bermuda Triangle.

The important thing about this triangle is that if any one of your three factors ‘worsens’, the metaphorical area enclosed by the triangle does not change. This means it will put strain on one or both of the other two factors, eg. if the timescale increases, it is likely you will need more resources, if the scope increased, it is likely to have an effect on cost and/or timescale.

You need to be aware of any likely changes in the parameters of your project and be swift to act accordingly. If you’re not all over this, your project could very quickly sink without trace.

Labels: B, Bermuda Triangle

This is one of the key skills for a software Project Manager. Having the ace of spades in bluff up your sleeve means you don't actually have to know everything about your project or, indeed, anything about anyone else's.

You only need to bluff enough to get you beyond the current situation, then you can find out the real facts, or assign the responsibility to someone else. So, the trick is not to appear phased by anything and to give the impression that you know all about the problem/situation/issue, but avoid coming up with any radical solutions until you have time to think it through properly. Remember, if you overdo it, you may end up left holding the baby.

Using a few basic rules of engagement, you can bluff your way through progress meetings, planning meeting, budget meetings etc.

The more experience you get in the software game, the better your ability to bluff will become. It's an experience thing, but make sure you practice.

Labels: B, Bluff