Category Archives: M

M is for… MBWA

Management By Walking About (MBWA) is a much underrated mechanism to keep an eye on what is going on in your project.

As things have evolved technically over the years is becomes all too easy to orchestrate, or attempt to orchestrate, your project form the comfort of your adjustable office-chair. Using eMail, Instant Messaging, Text Messaging, etc. to deliver your guidance and expert opinion.

However, while you may like to think you are some kind of techno-mastermind of all you survey, the chances are you’re missing out on a lot of the crucial information you really should have a firm grasp on.

If you’re only reading the written word, and worse, only spouting it too, you are missing a huge percentage of the other parts that make up that thing we call human communication.

Without getting the real ‘word on the street’, complete with intonation, attitude and accompanying body-language, you’ve only got part of the picture.

Have you ever said to yourself, “I didn’t realise it was that bad” or, “They should have said there was a problem”, then maybe you need a bit more ‘face time’ with your team, customers or co-workers.

So, If you want to keep on top of what’s going on, get off your arse and walk about!

M is for… Marginalisation

Sometimes you get people on your project that are a danger to themselves, let alone anyone else or your project. On occasion, they are actually OK in terms of their knowledge of the subject matter, but you wouldn’t trust them to deliver newspapers.

If this is the case, you may wish to assing them an ‘advisory’ or ‘consulting’ role without any real delivery responsibility. They could maybe coach some of the more junior people in your team in their area of expertise. If you sell it correctly, there’s a good chance they will be happy in the respect you have in their knowledge.

That way you get the benefit of their knowledge without the associated failure to deliver; just make sure you give them some boundaries and keep a close eye on them.

M is for… Marionette

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.

M is for… Mean Value Coefficient

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.

M is for… Methodologies

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 you’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’s little benefit in telling people you ran a fully SSADM compliant project, using PRINCE2, which failed.