<body>

The A-Z of Project Management Survival

Put that Prince 2 book down, this is the real art of project management and software delivery

All contributors have at least 20 years of successful Project Management and Software Delivery experience, so pay attention.
 

S is for... Sponge

Sunday, December 28, 2008

The sponge is another example of a PM out of his depth trying to add value to his project.

His project team will be telling this PM there are problems on the project, they will be sending him progress reports coloured in heavily in red felt-tip pen, they will be telling him things like, "We're going to be late", or, "We're easily going to spend double the budget", or, "We need help!"

The sponge will happily absorb this bad news and report to his management that everything is fine, brilliant in fact. So much so, the Sponge will be looking for more green felt-tip pens in the stationery cupboard. He will blissfully continue in this fashion until the point where he can hide it no more. He thinks he's keeping the management happy by telling them what they want to hear and will get gold stars and plaudits in return.

Similarly, any criticism and/or bad news, coming from further up the hierarchy, towards his project team will be soaked up by the Sponge and kept from the poor souls on the team. His management will be telling him, "The business are concerned with the lack of progress", or, "The budget seems a bit tight, do we have enought to complete?", or, "Are you sure you'll deliver what we promised on time." By acting as a Sponge, he thinks he's protecting his team from the bad press.

At the end of the day, it will all explode in his face. Carnage will ensue, with the finger of blame being pointed at everyone and everything.

Labels: , ,

A is for... Agile

Thursday, December 11, 2008

First, let's be clear - Agile is a software development methodology, it's not a 'save the world/software delivery panacea', and in a lot of ways it's really a collective re-badging of stuff that's been around for ages.

The Good Guys will recognise a lot of this before, but others will cling to it thinking it will somehow magically make software development faster, better, cheaper, etc. There are plenty of books on the subject and most will tell you it DOESN'T solve everything, it's NOT necessarily faster, or cheaper, and there are certain projects or situations you should NOT use it.

Agile brings with it lots of new exciting terminology and lots of new fabby techniques, or does it? Let's compare Agile with DSDM and XP, or, if you're old enough, RAD or JAD (whatever happened to that), and let's compare it's new fancy buzzwords with, well, errr, plain English really.


  • Stories: A narrative describing something to be delivered. The old skool will recognise these as 'Requirements' (Epics = High level requirements).
  • Sprint: A defined period of time where everyone works hard with the objective of delivering something. XP calls them Iterations, DSDM called them Timeboxes in the olden days
  • Scrum: When the team all gets together to discuss what to do. Sound familiar? Yes, a 'Meeting'
  • Standup: No, not a comedian, but by now, you are may be beginning to wonder. This is where the team all gets together quickly to discuss what to do, without sitting down. You will undoubtedly recognise this in the real world as a 'Short Meeting'
  • Refactoring: Restructuring or changing existing code to make it work differently. Yeah right, you may be more familiar with the terms 'Fixing' or 'Debugging'

We could go down to the level of discussing 'dunces hats', and 'visible build indicators', but you're probably getting enough of an idea already. It's all been done before and those in the know have been doing it for years without the daft names. Suffice to say, if you've mobilised a teamlet, who've assigned a story-captain and they're now swarming on a work item to burn down a story, you're already too far gone.

The bottom line is that Agile is like any other methodology du-jour; it's right for some things and not for others, it has useful bits and irrelevant/pointless bits and it has people who know about it and understand it and people who think they know about it but don't.

Watch out for the latter; the methodology evangelists. These are the people who will say things like, 'That's not the Agile way', 'We should have a stand-up to resolve this', 'we must use xyz software to track with' (it'll be a beta release of a freeware hack that only runs on an obscure version of Linux, or a Commodore 64 and requires you to be a seventh level mage to sign in), and generally strut about looking like they know it all.

Agile works best if you can isolate everything from the real world; the project team, their development kit, the users, the testers, the delivered system, all common sense. Strangely, us real world guys know it's just not as simple as that...

Anyhoo, like all methodologies, it's only partly about the methodology, it mainly comes down to the people executing them; if you have enought good people, they will stand a good chance of delivering. However, if you don't, then the combination of that coupled with the use of a methodology new to those people , no matter how new and sexy it is, or wacky it sounds, will likely result in chaos.

Labels: , ,

S is for... Scoob



The working assuption here is that the reader has a Scoob** either generally or specifically. To deliver projects successfully, you need the people that have the Scoobs to help you.

If you're on a project and there's noone else with a Scoob, you're in trouble.
If your management don't have a Scoob, you're in big trouble.
If there's noone else you can turn to in the organisation that has a Scoob, better man the lifeboats.

Unfortunately you can't go the the shops and buy a 'Big Box of Scoobs' to get you out of trouble, but you can do the PM Survival equivalent; find yourself some Good Guys and get them onto the project pdq.

** For the uninitiated, Scoob is short for Scooby Doo which, in turn, is rhyming slang for 'clue'.

Labels: ,

L is for... Lost Dog



Recognisable from the fact they move quietly from meeting to meeting, with their metaphorical tail between their legs, the Lost Dog generally has a doleful expression on their face.

You'll spot them as the person who always seems to be in all the meetings you go to, but rarely contributes much. Very much the antithesis of the Echo, they will sit quietly, desparately trying to keep up what's being discussed, perhaps nodding occasionally and generally only speaking when directly invited to and then saying a little as they can get away with to avoid appearing scoobless.

Much of this is due to the fact that they feel overwhelmed by the topics being discussed. You will find many Lost Dogs in large organisations, particularly where the technology has moved on and they haven't. They're always busy, mainly because of the number of meetings they need to go to, but also because they're following somone around.

Labels: , ,

E is for... Echo

Wednesday, December 10, 2008

It's never nice to see someone struggle. But as we know, people who are struggling tend not to stay as quiet as they should. Not being able to contribute is one thing, but using up air-time for the sake of an apparent contribution is frankly a pain.

Another facet of the Competency Mask is the Echo. Someone explains something and then the arse in question says pretty much the same thing again with perhaps only a slight change in wording or emphass. In the worst cases, the repitition is near to verbatim.

This obviously wastes time, but what is more galling is that the repitition is done with no shame, with aplomb perhaps "look at me, don't I sound clever".

No, you don't, you're an arse. You gave it away with that echo. If you get a chance say "is there an echo in here" immediately after. They won't know what you mean but it will make you feel better. Others may snigger.

You'll hear these echo people all the time. Take note of them, it's as good a giveaway as a big badge with 'useless' on it.

Labels: , ,

R is for... Rug

Monday, December 8, 2008

The world is an imperfect place. Projects more so. This needn't always be bad news. Keep an eye out for things going wrong that aren't your fault and lie outwith your control. They can be very useful, particularly if there are other things amiss that your are accountable for.

If you get a rug. Use it. Bury your bad stuff under it and carry on. It's really very simple...

"Yeah, we were on track but (someone else's problem) happened and we couldn't get our stuff completed."

They will come in many shapes and sizes. The obvious ones are usually infrastructure related, server death etc.

Using a rug is simply an opportunistic version of Schedule Chicken. Rather than taking a chance that someone else's misfortune might benefit you. You simply pounce on the chance when you get it. It often makes sense to pounce on it when you aren't directly impacted. No harm in building up some excuses.

Even if you don't have any issues, get used to spotting rugs. Say to yourself "ooh, that's a rug" when you see one. But not too loud. You don't want people thinking you're mad.

Labels: ,

 
   





© 2007-9 The A-Z of Project Management Survival.
No part of the content or the blog may be reproduced without prior written permission.