The A-Z of Project Management Survival

You would probably always argue that a project will generally suffer if it has a hapless buffoon of a project manager. Strangely, this isn't always the case.

There is a particular type of hapless buffoon that knows he is out of his depth and is open to suggestion and instruction. A project that has a strong technical team can get the right thing done by telling the project manager what to do. The manager does the dull stuff, goes to the meetings, sorts timesheets etc, letting the team (or lead individuals within the team) make the major decisions and get on with the work.

Teams who work for such managers can enjoy a great degree of freedom and success if they realise that the 'leader' is easy to manipulate in this way. Keep and eye out for them, you might be missing a trick.

Obviously, the hapless buffoons that linger under the misapprehension that they are in charge and should make the decisions themselves will always cause a disaster.

Labels: M

As regular readers will observe, there is much discussion on the central concept of arses and good guys. Some may find this a somewhat vague concept. So, to bring this to life a little, we will introduce the concept of the Mean Value Coefficient.

This is being done for a few reasons:

• the concept will be used in forthcoming posts, there's a whole theory to come
• it is an extension of the nickname concept
• you just can't beat a bit of pseudo-science

The concept is very simple:

1. An individual with an Mean Value Coefficient of 1 has a neutral impact on your project, makes it neither better or worse.
2. An individual with a coefficient less than 1 has an overall detrimental impact on your project (an arse). The smaller the coefficient, the worse they are.
3. An individual with a coefficient greater than has improves your project (a good guy). The higher the coefficient, the better they are.

This has a very important use. You can simply refer to people as "MVC 0.5" and only those in the know will know what you are on about. This is sometimes safer than the more traditional "he's an arse" when you don't know who might be listening. Generally, people who don't know what MVC is will be to embarassed to ask. Its also particularly sneaky as MVC means something else too.

Labels: M

Methodologies are wonderful things, or so the people who invented them, or offer training or consultancy in them, would have you believe. Some have cool-sounding names: RAD, JAD, some try to sound important: PRINCE, or obscure: SDSM, SSADM, ITSL, some are just clubs: APM. They’re all basically the same concept, take a real world discipline and put some rules in place, some fancy terminology or acronyms and maybe thow in a few standard forms and a £45 manual or two.

Yes, they come under many guises, Project Management methodologies, Development methodologies, Quality Management methodologies, etc. They all have one thing in common, the people who invented them and the organisations that are touting them are now very rich.

The other strange phenomenon that exists in this area is that just about every organisation thinks they can do it better. So, when you hear things like ‘Yes, our Product Management methodology is based on Prince II but it’s much more practical’, the warning bells should be starting to ring. After all, why would people plough millions, nay many millions of pounds in developing and spreading the word about something just for other people to discard bits of it because they don’t like it?

Rule #1: Don’t try to use a big methodology to deliver a small project. Use the lesser known Common Sense methodology instead, it’s cheaper and much less complicated. If tou’re a Good-Guy, you’re already trained in it!
Rule #2: If you don’t have to use it, and it does not benefit you to use it, don’t use it. There is little benefit in telling people you ran a fully SSADM compliant project, using PRINCE2, which failed.

Labels: M, Methodologies