The A-Z of Project Management Survival

C is for... Channeller

2008-03-31T15:28:00.001+01:00

Reading through the entries in this A-Z, you may form an opinion that the authors are a little harsh on project managers as a race.Obviously, we're not saying that all managers are bad, but here are very many that drag everyone else down into a pit of despair.

One such group of these managers are the channellers. As ever, this is another subset of managers who come under the broad category of "Can add no value so scramble about trying to find ways to appear to add value."

Channelling is all about control of information flow. Collecting information from those who know and communicate it upwards and they are seen to be on top of the situation. Get a decision from higher management and pass it down as they're own and they are in control, reactive, happening.

This is particularly obvious when there is really good or really bad news about. The channellers are easy to spot. Volunteering to send emails, organising calls, saying things like "I'll take that to Darren, he should hear this from me." I guarantee that you have already thought of someone you know who does this.

Obviously, the game here is a spot a channeller and make sure you do the communication and watch them seethe at first; then slope off just in case someone asks them to do something.

S is for... Silver Bullet

2008-03-02T09:01:00.002Z

You will often hear people say that "there is no Silver Bullet". And this is generally true. Such miracles tend not to happen. What you can say, though, is that there are many situations that would be significantly improved by Silver and Bullets.

It is hard to see how getting rid of useless people and paying a little more for good people can't help. Not necessarily a palatable option but quote it to people seeking miracles. It might shut them up.

M is for... Marionette

2008-02-07T10:14:00.000Z

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.

D is for... Directing Traffic

2007-11-05T22:36:00.000Z

On a recent trip to India*, I observed a strange phenomenon that has a parallel with pointless Project Managers. I saw a great number of people, mainly in uniforms, whose sole function seemed to be to wave people in the direction they were going anyway.

This was particularly prevalent in the airport, but was also seen a lot with traffic on the street. You could argue that there was job was to be there in case of incident, but it merely looked liked the were waving their arms to give the appearance of adding value to the situation.

You get a lot of Project Managers like that. Watch out for them. They have no input of their own so, instead, they give the appearance that they are giving direction but, in reality, they are only waving people in the direction they were going anyway.

Agreeing with other people's decisions, sending out emails saying "Yes, I agree, do that.", is not managing, its just waving people towards a door that is already clearly sign-posted. Don't do it. You look like a fool.

* I'm not suggesting this only happends in India, its just where I saw it and had the thought.

W is for... WOLF!

2007-08-09T14:26:00.000+01:00

Don't panic. Really, just don't. Sure, big problems do happen and you may have to take action and say that it is urgent/critical/non-negotiable (perhaps even using bold) and escalate to the Gods, but choose the times to do this carefully.

No one likes it when you go bananas about something that really isn't that important. No one will listen to you if you do it too often. Time will come when you do have a real issue and the villagers simply won't be around to help.

On the flip-side, if you see people over-reacting in this way, try shouting 'WOLF!' at them. Everyone else will love it and you'll get the point across. Unless they don't know their fables, in which they'll just be a little freaked out, which is good enough.

P is for... People (part 1)

2007-08-06T21:24:00.000+01:00

Now we're getting to the meat.

Cobb's Paradox:

"We know why projects fail, we know how to prevent their failure
-so why do they still fail?"

Martin Cobb Treasury Board of Canada Secretariat

Since 1994 the Standish Group have been producing their Chaos Report. This project “ exposes the overwhelming failure of IT application development projects in today's MIS environment”

From the 1994 report we can see the core reasons for failure: The factors that cause projects to be challenged were:

Project Challenged Factors	% of Responses
1. Lack of User Input	12.8%
2. Incomplete Requirements & Specifications	12.3%
3. Changing Requirements & Specifications	11.8%
4. Lack of Executive Support	7.5%
5. Technology Incompetence	7.0%
6. Lack of Resources	6.4%
7. Unrealistic Expectations	5.9%
8. Unclear Objectives	5.3%
9. Unrealistic Time Frames	4.3%
10. New Technology	3.7%
Other	23.0%

So, what conclusions can be drawn from these many years of research? One broad message is that, despite all the years of innovation and experience that have passed, as Cobb’s paradox suggests, nothing much has changed. What was problem a decade ago is still a problem now. Despite tools, techniques methodologies aplenty, projects still fail and for the same broad set of reasons.

This research clearly points at the major issues in project failure and with consistent results over so many projects over so many years it would seem entirely incontrovertible. There is a common thread in all the results that is concealed behind the detail. At the heart of all project failure is the people. This may seem obvious, after all, projects are conceived by, designed by, built by and used by people. It is clear that this human factor can never be removed from projects but, by understanding the nature of the influence of people on a project, certain key failure points can be targeted and improvements made. At least in part, this is perhaps at least part of the answer to the paradoxical question ‘so why do they still fail?’.

All the great processes and tools cannot make up for the fact that people are at the core of everything we try to do, and if the people aren't up to it then there isn't an awful lot you can do about it. Except to look for a saviour.

What this all points at is that there is only one thing you need to get right. Get the right people on your project. You do this by either getting your recruitment right or, within the existing resource pool, making sure you grab the good ones.

The quality of the people at the start of the project sets the upper limit of how well everything can go before all the usual stuff starts to go wrong.

Everything, EVERYTHING you try to do is based on and reliant on people. Get good ones, make sure they are happy, give them space and let them do their thing.

M is for... Mean Value Coefficient

2007-08-06T15:03:00.000+01:00

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:

An individual with an Mean Value Coefficient of 1 has a neutral impact on your project, makes it neither better or worse.
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.
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.

N is for... Nicknames

2007-08-06T13:44:00.000+01:00

Nicknames aren't anything new. Some people get them, some don't. Some last for a while and die away, some stick for life. They can be derogatory, complimentary, used to the person's face or just behind their back, but very, very rarely, are they planned.

Here's the deal, everyone should have a nickname that is known within the inner circle of trusted friends. This isn't just for colleagues, it can be for customers, suppliers, whoever. The point is that it is very useful to be able to talk about people with other people, including the individuals themselves, having no idea who you are on about.

The important thing is that the nicknames can't be obvious. You can't call John Smith 'Smithy' or 'Bitter'. By way of example, you could call him 'Garlic'. See, you have no idea how I came up with that, but there is method to it. Its all about additional degrees of separation.

Above all, nicknames can make every conversation more fun, which is very important.

F is for... Fun

2007-08-06T11:42:00.001+01:00

Remember this. Write it on a piece of paper if you have to. No one you
work with is independently wealthy and comes into work just because
they love it. And, even if they are, they still do it for more glory,
not relaxation. None of us are charities, we work to earn money, simple
as that. And we spend a lot of our lives doing it.

Therefore, enjoying our work as we go is very important. Sure, it
helps with retention, churn, yada, yada. But you should consider it on
a more human level. If people are, by virtue of necessity, stuck with
working for most of their natural lives, surely everyone has a
resposibility to make it as enjoyable as possible. This is suggesting
that we enter the Brent-ian nightmare of "entertainer first, manager
second", it is simply to say that it is incumbent on every manager to
create an environment that people want to work in, to get out of bed
for.

Obviously, your standard arse believes that maximum productivity comes
with the intense silence of the monk in a scriptorium. Their fear
forces them to believe that any time not working is wasted time. This
is very far how it should be. There is never a time when a bit of
laughter can't improve things. A relaxed mind is a clear mind.

A good manager is one that creates the environment in which their
people can work at their best. There is many aspects to this, but
having fun is the central tenet of them all.

X is for... (e)Xpectation Setting

2007-08-02T17:43:00.000+01:00

OK, so it doesn’t actually start with an ‘X’, but there aren’t many words that do, so this is pretty much the best you’re going to get.

This one can’t be stressed enough. If you are managing a project, delivering software, whatever, it means you have customers, or stakeholders, or perhaps both. These are the people that will build or break your reputation in equal measures and with astonishing speed. So, best have them on your side eh?

Build a rapport with them ensure they are aware that you have their interests at heart, because you do of course!

When things are going well, be sure to make sure they are aware of how good a job you are doing, but in a subtle way of course. Equally when things are going wrong, it’s a good idea to be open an honest with them up-front and early. That way the kicking you are likely to receive as a result of it will be minimised, perhaps to none at all.

Of course, if you are a good guy, you will have thought through all the permutations and options and presented the best solution for the benefit of the project. So, beforehand, work out what’s wrong and how you’re going to put it right then present your plan for saving the world to your customer(s). Do it well and you will maybe even come out smelling of roses.

B is for... Butterfly

2007-08-01T21:57:00.000+01:00

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.

F is for... Flip-Flop

2007-08-01T21:47:00.001+01:00

Those of you of an older vintage may remember the flip-flop. A simple logic circuit that can be in one state or another. You get people like that too. Having no clue about anything, they tend not to have any definitive opinion of their own. Instead, they carry about with them the opinion of the last person they discussed a given subject with.

This is generally quite irritating as you can usually have two very different conversations with the same person about the same thing.

"But I thought we had agreed yesterday that the sky was blue?"
"Yes, but I had a meeting with marketing this morning and no I see that it is more of an indigo..."

Fundamentally, such people aren't much use, but there is much to be exploited here. If these people are in decision making positions and you'd like to them to act in your favour, all you have to do is get to them last. Just make them flip to your way of thinking, make sure no one else talks to them before they enter the crucial meeting and the world is yours.

N is for... Nepotism

2007-07-30T22:50:00.000+01:00

We all know it happens. Someone gets a job then gets his/her mates a job. And we all know it isn't always a positive thing. Friendship blinding reason, people promoted above their ability or nowhere near their area of expertise. It happens and, to be honest, their ain't much you are going to do about that.

There is, however, a more positive side to this. There are a large number of good guys who tend to get overlooked for bigger and better jobs because they are too busy getting everyone else out of the mire. Sometimes they can be hauled out of this by their good guy friends/peers and put in a position of more importance and, crucially, more influence. The higher up in an organisation you can place a good guy there better everything around him goes.

You can have a massive impact by using this kind of of positive nepotism. Get the real talent in its right place.

F is for... Flawed

2007-07-30T12:43:00.000+01:00

This is an important realisation you have to have. Everything is, to some extent, flawed and everything you do is an attempt to reduce the level of imperfection. Everyone makes mistakes, things generally don't go to plan so have to find ways of making sure that you find and correct issues before this is too late. Obviously, this is what review/testing and all the standard project stuff is about. But the crucial thing to remember is that it is the people who are flawed and collectively everyone and everything has to act to reduce problems.

The amount that flaws can be eliminated is simply another aspect of the Bermuda Triangle. If you have enough time and money, you can test/fix/control for many years and you'll get close. This is a space industry thing, very expensive, one shot and it has to work as near to flawlessly as is possible. But even space stuff expects and gets some issues.

Most of us don't work in that kind of industry and our scope for validation and verification is much less. There isn't a problem with this. Its just a balance of risk. A website selling shoes can go live with issues. We won't need a Shuttle mission to repair it.

The key point is, if you accept that things are inevitably flawed then you have to accept that it is your responsibility to organise the process by which collectively the project decides who to handle the flaws.

One obvious characteristic of an arse is that they tend to accept that corners are cut during a project (usually because they are too scared to declare a slip) but then blame people for there being issues at the end. Phrases such as "How did you let this happen?" can be heard. If you accept risk then accept the consequences of the risk not going your way. And, always accept that things are flawed.

O is for... Ostrich

2007-07-26T15:23:00.000+01:00

You know the type, you probably have some of them in your organisation; when there's a problem, they bury their head in the sand, usually because it is beyond their capabilities to do anything else.

They will ignore the inevitability of the situation, hoping upon hope that it will go away. Usually until the very last minute, when they will endeavour to get rid of the problem or otherwise attempt to make someone else responsible for their own failure to deliver. This is often too late to do anything effective and even the best endeavour to help out will result in association with the problem.

Best to avoid these people, and if it's impossible to avoid them, or you have a sneaking feeling that the hospital pass will be coming your way at the end of it all, practice a little coaching on them as an exercise in splash damage limitation.

B is for... Bermuda Triangle

2007-07-24T16:48:00.000+01:00

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.

U is for... Use your tools effectively

2007-07-24T15:54:00.000+01:00

There are many tools out there to help you do your job effectively, just bear in mind that having all the tools in the world is no substitute for skill and ability; in that way that having a copy of MS Project (other planning tools are available) does not make you a Project Manager.

However, if you make yourself a master of the tools you need in your day to day tasks, it makes everything else that much easier and quicker. People pay more attention to the content of a well presented document, instead of mocking or getting confused by layout and mistakes. If you don’t have time to master a tool before you have to use it, get someone on your team that is already a master of it.

Here’s a few pointers (other products/pointers are available):
Word:
Learn how to use the formatting tools: paragraph marks, bullets/numbering, headers and footers, auto numbering and styleref.
Create templates for the stuff you use a lot.
Excel:
Learn how to use the formatting tools, borders, colours, conditional formatting, charts.
Use macros for anything that is repetitive.
Powerpoint:
Learn how to use the formatting tools, master slide layout, transitions.
Don’t overdo it, people tire VERY quickly of flashing lights and sounds.
Project:
Set your working day before you start putting in tasks (if you don’t – learn to live with it that way)
Don’t use hard dates other than fixed starts of major phases or hard milestones: use dependencies, including ss, sf, fs, ff and lead and lag times.
General:
Use the right tool for the job; don’t do presso’s in Word, don’t do your project plan in Excel

Y is for... Yesterday

2007-07-24T14:36:00.000+01:00

You: “When do you need this done for?”
Gimp: “Yesterday.”

You will no doubt have had the above conversation countless times. It’s become some kind of glib, I.T. in-joke. The response is generally accompanied by a raised eyebrow and knowing look; “It’s not my fault it’s been dumped on me from a great height”. And of course, they’re now dumping the problem on you. It’s a form of Tennis, but not a particularly great one.

So, in the absence of a time machine you can, by all means do the best you can to satisfy the request, but make it clear at the outset that you will not be held responsible for failure to deliver on time. Remember, you are helping them out. Someone else’s lack of forethought and planning does not become your problem unless you allow it to.

You can of course look to use the event to gain yourself some brownie points, perhaps even seeding the grapevine with stories of how you pulled them out of the fire.

S is for... Scoping-Sword

2007-07-23T16:43:00.000+01:00

Because of the single most important rule of delivering software projects – the Scoping Sword is not only a key weapon in your armoury, you must be skilled in how to use it effectively.

Picture the scenario; you start off with a nicely planned and resourced project and everything is just swell, the sun is shining and pretty flowers are blooming all around your feet. Cue the day you deliver the first cut of the new software to the customer. This is the point when you experience the phenomena known as goalpost-shifting. The customer will come back with all sorts of statements, like, “but I thought it would do X”, or, “surely you knew I needed Y”, or even, “everyone in this business knows it has to be able to do Z”. It is important to recognise it immediately and act swiftly to regain control and limit the potential damage.

First of all you need to weed out the genuine defects – of course you are going to fix them. Then you need to assess the features the customer forgot to tell you about first time round, the requirements that your code-monkeys misinterpreted and delivered wrongly and the stuff you were planning to deliver in a later phase anyway.

Once you have all of this information, you need to look at your options. If the project deadline is not moving, the customer is not stumping up any extra cash, and your management won’t sanction any extra zero-cost resource – what’s left to do?

Correct! – pick up your big Scoping-Sword and hack a chunk of features out of the project! Now don’t panic, if you’re good enough, this can all be done in a controlled and tactful manner. The customer can be shown that the additional work he needs can’t be delivered in the remaining time without something else suffering. ‘Better to remove something and deliver it in release 2.0, rather than deliver it badly in 1.0’ is always a good line. You can then re-group, re-cost and charge for it in Phase 2.

Ensure you cover any changes with the appropriate Change Control paperwork and sign-off, to ensure you suffer no repercussions later when it turns out the person that was waiting for the feature wasn’t informed when it suffered at the hands of the de-scoping exercise of week 24.

W is for... Workshop

2007-07-23T15:22:00.000+01:00

If you’ve been in IT for more than ten minutes, you’ll have been to a workshop. Back in the eighties, they were all the rage, along with all the buzzword bingo terms, like brainstorming, facilitators, synergism, leveragability, etc. (note, if you’re looking these up…)

Nowadays, some people still insist on getting everyone together for a ‘workshop’, at every available opportunity, to ensure everyone is ‘on the same page’, ‘singing off the same sheet’, etc. The trouble with 95% of the these workshops is that the people running them don’t actually know how to run a workshop and it ends up being one of two things – a happy-clappy back-slapping session about how good everyone is because no one wants to be controversial, or an all out bitching session about everyone and everything in the company. Neither of these actually achieve anything and the true sign of having attended one of these is that the closing comments of the ‘facilitator’ will most likely be “I’ll send an invite to the follow-up workshop/wash-up/break-out groups, when I get back to my desk.

Here’s a couple of definitions:
A workshop is a method used to collate practical input from multiple contributing parties to achieve an end-goal, using appropriate tools and techniques to achieve this objective.

A workshop is not:

a platform to allow you to tell people about something – that’s a presentation
a mechnism to show people how the system (will) works – that’s a demonstration
a place for a team to discuss things – that’s a meeting
a method to teach people how to do/use something – that’s a training course
an end-of-season stationery-cupboard frenzy, using as many flip charts, markers, yellow stickies and coloured dots as possible.

Most of them will be a waste of time and achieve pretty much nothing, so if you have to go to them you will have to make the best of them. This is where a good-guy can excel; by demonstrating his grasp of what’s going on and using it to ensure the best positioning for his project, even if the workshop has nothing in the slightest to do with his project.

Most of the time however, the best thing about a workshop will be the free lunch.

O is for... Overload (no such thing as)

2007-07-17T21:33:00.000+01:00

Here's a simple tip. Never say you are too busy for anything. Because its not true. The real answer is that what you are being asked to do doesn't rank higher in priority than the things you are currently engaged in.

You will hear many people complaining of overload, being too busy, "rushed off my feet". Lame. Because overload doesn't exist. Here's another simple tip. You can only do one thing at a time. So, write down everything you have to do in the best priority order you can do and start at the top. One at a time.

People who say they are too busy generally have three main failings:

They fail to say no.

They fail to delegate.

They fail to adjust priority and expectations when something else goes to the top of the list.

Everyone will always tell you that what they need you to do should be your number 1 priority. Sometimes they will use the word urgent. Often it will be in bold. But there really is no point in taking on 2 or 3 such simultaneous tasks and failing to deliver them all. There is always some give in any ridiculous demand. Try phrases like "OK, I can do X today, but I'll have to drop Y & Z, can you check with Mr. Y and Mr. Z that they will be OK with that?"

You see, faced against other people's real priority items, some demands can look a little daft, so let them find that out in discussion with their colleagues. Means you don't have to tell them, which saves you time.

This is particularly important if its your boss who is asking. You can always deflect this by saying "OK I'll complete that report you never read by the end of the day, but can you let the client/business/whoever know that I won't be able to do [task] for them?"

There is never, ever anything to be gained by taking the weight of the world on your shoulders for delivery by 5pm or else. But similarly, you can't say you are too busy. Because, frankly, that's a crap answer.

D is for... Dambuster

2007-07-17T15:07:00.000+01:00

You will invariably find, as you go about your trade, many people who will try to put obstacles in your way. You know the sort, those workshy fops that will try to hide behind process, officialdom and “You’ll need to raise a request before I can look at that” or “I can’t do anything about that without a signoff from network security”.

This can slow your project down considerably, especially when you encounter a cluster of process junkies all quoting form numbers and obscure request systems. You can quickly end up being flipped around form department to department like a pinball, especially if you have the audacity to suggest to them, “go on, bend the process just this once”, or worse, “just feckin’ do it!”.

Most red tape is black and white

Make it your business to understand all of the methods of request, the times to use them and have all the tools installed to allow you to do it. Make contact with the people who are approvers for the various things you will need, eg. security, networks, telephony, sys admin, DBA’s etc.

Then you can use your dambuster skills to quickly and easily break through those process log-jams and achieve what you need with the minimum of disruption to your project.

So, the next time some wastrel of a jobsworth says, “You’ll need to raise form C2634 in triplicate and have the yellow copy signed off by a purple unicorn”, you can be back at his desk 30 seconds later, smiling as you hand it over and say, “So when will it be done?”.

Of course a good-guy would never use process to slow down or prevent progress elsewhere, even for fun. Well, not to another good-guy anyway.

R is for... Rescue

2007-07-16T23:25:00.000+01:00

As your reputation as a Project Manager of note becomes known and people start saying good things about you in hushed tones, the time will eventually come when your manager will call you to the side to ‘ask a favour’. The conversation will start off something like this, ‘We’ve got this project, it’s had a few problems in the past, and I think you’re just the man to put it right.’

Now, of course you’ll be hooked to the grapevine and a bit of an information junkie and will therefore already know plenty about this project and its history of ‘problems’.

Now, you may not have much of a choice about taking on this project, but you are certainly in a position to voice some conditions under which you’ll take it on if you are to deliver it successfully. Look at the big three variables in a project – budget, timescale, scope. This is your chance to put your marker down and give yourself some breathing room.

This is a good time to make some demands about who you need on your team to deliver the project, don’t worry if they’re on another team, another project or even external. It’s also a particularly good idea to review the scope and deliverables of the project, perhaps exclude some features, change technologies or deliver in phases. Lots of options, consider as many as you can.

Be sure you make it clear that not getting the necessary amendments to resourcing, budget or scope will affect your ability to rescue the project as requested. Just remember, once your name is scribed on that list alongside the name of the project, your bargaining power on this front is reduced considerably.

G is for... Grapevine

2007-07-16T22:35:00.000+01:00

Do not underestimate the power of the informal communications network in your organisation.

This is the place you will get to find out everything; from project slippages, new opportunities, all the way to re-assignment of resources, before they are formally announced. In fact, you’ll find out stuff there that won’t ever be announced. Keeping ahead of the game is essential if you are to get the good projects and enhance your reputation as the big cheese of Project Management.

Keep your grapevine contacts active, contribute to the information flow, and take what you can from the grapevine. One thing you need to be mindful of is differentiating the gossip and conjecture from the actual information – after all you don’t want to go off half-cocked, do you?

The grapevine is also an excellent mechanism to publish information to the wider community about your project too. Perhaps you need to get the word out that you are looking for resources. Word gets round surprisingly fast.

C is for... Competency Mask

2007-07-16T21:44:00.000+01:00

Sometimes all is not what it seems. And this is where your powers of observation have to be at their sharpest. Some arses have a competency mask. It can take many forms but what it can do is give the impression to the untrained eye that they might be "OK" or "capable".

Surely you're jesting...

Here are a few things to watch out for:

Dress
Yes, as unbelieveable as it seems. Someone well presented can sometimes fool you into thinking they are not an arse. Suit, dress, good looks, tan, whatever it is, might give the appearance of 'sharpness'. Don't be fooled, don't make any judgement until they speak. After all, when they turn round they might have a sticker that says 'elbow' on the buttock of their delightfully pressed suit trouser.

Vocabulary
Probably the most prevalent of all aspects of the Competency Mask, the language people use can often be a thin veil over an empty head. Modern business language has developed into a bizarre concoction of phrases and cliches that anyone can trot out and, if you are not paying attention, can make you think they sound plausible. Listen again. And, crucially, listen for content. Ask a difficult question and watch as the Competency Mask descends to cover the rapidly appearing glaze over the eyes.

Doing the Easy Stuff Well
Comfort zones are very handy. Especially when you need something to cover up the fact that you never actually contribute. Its simple to spot. Watch for people who quickly and repeatedly volunteer to do the easy stuff (before all the tricky actions are handed out). They sit back "well, I have contributed, I'm going to book the meeting room for the follow-up meeting, maybe I'll arrange the lunch too, why not, no harm in over-delivering". They are just doing stuff that anyone could do but getting paid far too much for it.
You see this in document reviews quite a bit, unable to stay quiet, the Competency Mask allows the person to make such massive contributions as suggesting a different font, pointing out problems in the page numbering/footer or suggesting a whole new pagination strategy. Arse.