The A-Z of Project Management Survival

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

At some point in the working life of every manager, you will be asked to make judgement on your subordinates. Luckily they will be usually given some form of performance review system to give structure to your meandering thoughts. The system will typically be based on objectives, competencies, performance against ‘vision’, that sort of thing. The simplest thing to do is to ignore all of this and to concentrate on some fundamentals rules. Start by answering these questions:

• Who in your team makes you look good without being a direct threat to your position?


• Who in the team would it cause more hassle to lose than retain?


• Who would you happily flush down the toilet?

Got the answers? Good. Now the next stage. Recite the mantra ‘Reward to retain, ignore to eliminate’. Pay most attention and reward to those you want to keep, be polite and courteous to those you want to flush. Its for the good of everyone, you, the company, even the individuals themselves. No one wants to work for a boss that thinks they are a muppet. You’re doing them a favour, putting them out of their misery.

Labels: A, Appraisal

"Change Control is the Project Manager’s friend. It’s more than a friend, it’s your best friend. Without Change Control, your project is out of control."
Anon



Here beginneth the simple lesson:

At the start of your project, before you do anything else, create a Change Control Note. Make sure it contains ‘effort required’ and ‘cost’ sections.

As part of your initial planning of the project, hand a blank copy to your opposite number – your customer or PM counterpart. “This is to make sure we can keep everything under control”, you will say.

The first few weeks of the project, find as many opportunities to raise a Change Control Note for changes to the spec, deliverables or anything really. Make these indicate small effort required and most definitely zero cost. Make sure your oppo signs this and make sure they know that you’re a good-guy. See ‘good-guys’.

Then, when the time is right, stiff them with a costed up one. Make sure you estimate this one accurately and have plenty of back up to prove it.

This is a good way to buy yourself some time, by moving out the deadlines, or be able to afford to get your team-size increased.

Later on you can graduate to the school of ‘comfortable’ estimation to allow you a bit of extra cash in the budget for other things, like the things you forget about. See ‘slush-fund’.

Labels: C, Change Control

It’s no accident that a simple transposition turns this particular species into conslutant. Consultants are in it for the money; and the bigger the company providing the consultancy, the bigger the money.

We have a healthy disrespect of consultants. Many of the big consultancies give this job title to their most junior staff. They then send them out to companies to advise them

Be careful when your company ‘calls in the consultants’. It can mean one of a number of things:

• They are genuinely clueless as to what to do and need someone to point them in the right direction.If this is the case, why don’t they have a clue – it’s their business after all.
  
• You have a board member that has a vested interest (see ‘Vested-Interest’) in the proposed consultancy company.In this case, they are spending your company’s money and boosting their position on various boards.


• They have no confidence in their workforce.In this case, what does that say about you

Advice? Interview your would-be consultants as if you were going to recruit them for your own company. Many companies either don’t realise or forget that you can knock-back individuals from your consultancy firm. In this way you can avoid having a bunch of numptys running the show in your area.

If you don’t have the authority to make the decision on whether the allocated ‘consultant’ should be retained or not, don’t worry. Interview them anyway, then you can label them as competent.

Labels: C, Consultant

The best way to avoid a project management disaster is not to get involved in the project at all. Learn to see the Turkeys coming and duck them with vigour. Do all you can to ensure that those projects are assigned to your less capable friends (see the test under Arses). This is not as unfair as it sounds. Given that they probably can’t deliver any project, giving them the undeliverable to deliver at least gives them a viable excuse for failure.

Here’s a few tips for spotting the ones to avoid:

• If the salesman can’t immediately answer the question “What exactly did you sell?” ( see the entry under it ).


• If the technical architect says ‘no, no, we don’t need a proof of concept, it’ll all work, I’ve read a whitepaper’


• If you’re general manager says ‘we’re going to deliver this one from India’.


• If you get introduced to the team with the words ‘Yes, they’ve been doing mainly mainframe work but they are going on re-training next week’

Labels: F, Failure Avoidance

As you go though your live in Software Project Management, learn how to take a kicking. As sure as eggs is eggs, you’re going to get a more than a few in your time. The thing to remember is not to worry about it, and never, EVER “go off with stress”.

When a kicking is heading your way, find the biggest technical manual in the office stuff it down the back of your trousers, bend over and brace yourself. Above all, remember the wise words of Boris Becker after losing a game at Wimbledon: “I only lost a game of tennis, nobody died”.

Probably best not to use this phrase during the kicking but keep it in mind throughout.

As your experience grows, you will be able to see them coming and you will be able to prepare for them.

The bottom line is, take it like a man, your time will come.

Labels: K, Kicking

Typically, if you’re working in IT as a Project Manager, you will have a group of individuals working for you. More likely you will have responsibility for a team of technical people working for you. Some of the clever ones will maybe even be a little challenging to manage and maybe even to look at. That’s where the ego comes in.

The techie ego is a very precious thing. It’s like a little new born kitten (or puppy if you’re not a cat person). It is looking to you to nurture it and protect it, like a parent. Remember, you are effectively their surrogate parent for a large proportion of their day.

Techies like to think they are the best at their ‘thing’. If you have more than one techie with the same area of expertise, then you’d better hope they get on, and they can work together – you will likely get more than double the productivity – congratulations, you won the lottery!

If they don’t get on, it will go one of two ways: they will be in competition with each other, which will be fine till one ‘wins’ or they will critique everything the other does and nothing will get done. Either way, you’re dead in the water, you wil either lose one of them or spend all your time settling petty squabbles.

So, it pays to be vigilant and massage some ego when required. The best method for this is ‘divide and conquer’, take them aside individually and have a chat about how important they are to the success of the team. If you have competition, split it up quickly, and get them working on different areas, encourage friendly competition by all means, but avoid head-to-head ego battles.

Labels: E, Ego

"The difficult we do immediately. The impossible takes a little longer."

Motto of the U.S. Army Corps of Engineers - World War II

In IT, nothing is impossible, it just costs more. The bottom line is – will your customer or project sponsor pay for it?

Few customers are actually creative enough in their thinking to ask for the really impossible things. Usually a statement along the lines of ‘Do you have any idea how much that would cost?’ will scare them away from the really stupid things.

So, the only issues that are likely to approach the bounds of impossibility are lack of time to complete the work. Although, even this can often be solved with an injection of cash – you can get contractors, you can subcontract, you can work shifts, and you can even go offshore – if you’re feeling really adventurous!

That said, ‘Impossible!’ is a word you will typically hear from your team rather than your customer. Customers, by their very nature, expect the extremely difficult – but that’s because it’s not them that has to deliver it. But, that said, they do have to pay for it, so make best use of the tools of the trade. See ‘Change Control’.

To placate your team of incorrigible realists, point out to them the harsh realities of the situation. The customer is paying all of our collective wages, you’ve done your bit to temper the customer’s enthusiasm, and now they are asking for a lot less that they were expecting before. So surely they can deliver a subset of the real requirement. See ‘Ego’.

Labels: I, Impossible

"You know, we always called each other goodfellas. Like you'd say to somebody: You're gonna like this guy, he's allright, he's a goodfella, he's one of us. You understand? We were Goodfellas, wiseguys."

Henry Hill (Ray Liotta) in "Goodfellas"directed by Martin Scorsese

It’s simple; either you are a good-guy, or you’re not.

Good-guys, or in this day-and-age, good-gals, are quick on the uptake, they can read a situation, think on their feet, undertake a variety of roles. They are valuable people to have, as you can rely on them to turn a seemingly impossible situation around.

If you are a good-guy, you’ll know you are. You’ll quickly recognise other good-guys and naturally gravitate towards them. The capability of a group of good-guys is by far greater than the sum of their individual skills.

If you’re not a good-guy you may still believe you are, but you’re kidding yourself on. And deep down, you know you’re kidding yourself on. The real good-guys will quickly suss you as a faker.

In any case, make sure you have one or more good-guys in your delivery team. Guys you can rely on to take the heat and not buckle.

If you don’t, you may still succeed, but it’ll be a hell of a lot harder for you as you have to deal with everything.

Labels: G, Good Guys

When it is your job to deliver something, it pays to make sure the expectations are set correctly. Whether it is the time it will take, or the functionality that will be delivered, or the money it will cost, always make sure the expectations are set in your favour.

Let’s consider expectation setting for your customer. Firstly, start process early in your project. When you are planning your project, assembling your resources, doing your fairy story (see ‘Estimates’) consider yourself in the role of a tradesman, for example Plumber or Garage Mechanic.

When asked how long something will take, or how much it will cost, by management or a customer, perform the following mime:

• Look them in the eye with a furrowed brow and slightly puzzled expression.


• After a few seconds, purse your lips and, placing your right hand on the top of your head, slide it backwards towards your neck, massaging the back of your neck briefly. (you may place your other hand on your hip for effect, but this dual function manoeuvre is not for beginners)


• Now carefully breathe in through your teeth and pursed lips, a slight whistle at this point is good.


• Now tell them the bad news.

Practice this in front of a mirror until you perfect it.

The bad news will depend on how much time you’ve had to prepare. If you are being put on the spot, think of a number and double it at least, as a starting point. However, if you’ve had time to work out the details, double it and have it on a bit of paper, it will always have more credibility.
On the other hand, when you are passing on your expectations to your team, for example, always go the other way. Set their expectation to ensure the team deliver more functionality, earlier or using less resources. This way, you will have some contingency; either time or Slush fund to play with.

Labels: E, Expectations

It’s such a useful thing that sometimes you can forget the inherent danger of Excel. Lets get one thing perfectly straight, putting a big pile of numbers into Excel and making them all add up doesn’t make it reality. It’s a real shame really because it can all look so nice, especially if you put boxes round the numbers and have some colours, maybe even a funky font.

Of course, the mastery of the spreadsheet is an essential skill and is often the best way to make everyone assume that you are an extremely capable manager. Just don’t start to believe the hype. That’s when it can go wrong. So, assuming we know we are simply dressing to impress and fundamentally lack substance, here’s a few things to make them all ooh and aah at the project review.

• Conditional formatting – make things change colour automatically, usually green for good red for bad. Demonstrate this to people who walk past your desk – they will be impressed.


• Charts, if it’s a report or a comparison, always include a Chart – it takes up space, provides some nice colours, and because it’s pictures, Senior Management, and even Salespeople will think it’s great.


• Use Standard Deviation in a formula somewhere, randomly if necessary. When discussing it refer to it as ‘science’.

Labels: E, Excel

An important thing to remember, even when you are customer facing type of PM, is that one valid answer to a question is ‘No’.

If you say ‘yes’ to every request, every desire, every whim of the customer, you will certainly have a happy customer… …for a while. But when it gets closer to the deadline and you still have a stack of work to do, or you have run out of budget, or you now have every resource in the company working on your project for 18 hour days and weekends, they will start to lose faith in you. And that’s when all those favours you did them and all that wonderful helpfulness and positivity will be forgotten and the knives will be out.

You don’t necessarily need to be nasty about it, in fact in many cases you won’t even need to say the word itself. Just make sure everything you agree to do, will help you achieve the deliverables. And in all cases, make sure you use your big pad of Change Control notes.

But, when you can turn it round and make the person asking the question say ‘No’ for you, then you know you are good at your craft.

Tip: explain to them how much you would love to do what they are asking. Explain how, if it were up to you, you would have no hesitation in doing it. Then when they see how on their side you are, point out to them all the negatives on doing it, such as delays elsewhere in the project, lack of resources, extra cost, etc. If you are good enough, eventually they will see the error of their ways and back down, acknowledging of course how good a job you are doing.

Labels: N, No

Labels: I, it

This is probably the most galling fact of all. You work in I.T. You have a right to expect that you share your working life with well-educated, well-trained, competent individuals. This is why you feel alone. This is why you get frustrated. What will free you from this hell is if you just accept that probably as many as 85% of all people working in I.T. aren’t very good at it.



Arses

In fact, brace yourself, Project Management is probably the most guilty discipline of all. Think about it. How many people have you met he have stumbled into Project Management solely because they weren’t actually any good at anything else and specifically because the role of Project Administrator is very often confused with Project Manager. Collection of timesheets does not a Project Manager make.
Try this test. Give one of your so-called Project Management colleagues this book and if they say things like “That’s terrible” or “Very funny, lucky it’s not actually like that” make a mental label of “Arse” for them in your head.

Labels: A, Arses

We all have to do it but no one knows how. There is no magic formula, there is no way to find the answer all you can ever do is guess and suffer the consequences. There are only a few things you need to find out.

• What is the latest time the customer will allow you deliver?
• What is the minimum amount you can get away with?
• How much budget does the customer have?

Try and work these things out and build your estimate around them. Sure, build some sort of model to justify your numbers, maybe use something scientific looking like standard deviation and use interesting terminology like 'risk budget' and 'contingency'.

Ok, so you still want to try? Right then, on your own head be it, but here is some additional help in case you are still feeling misguided.

What does your gut feel tell you? Come on, your experience must tell you something? Is it 100 man days, 500, 1000? Think of a number, you'll probably be more right than you think. Then to confirm this, use the obvious but often forgotten 'bums on seats' estimate. Count the number of people you have available to do the work, multiply that by your gut feel duration and that gives you a guide to your total number of man days.

Labels: E, Estimation

Bizarrely enough, contrary to what almost every IT training establishment and 'Big Consultancy' firm will try to tell you, Project Management is not difficult.

You need a very basic set of skills: To be able to write, basic arithmetic, a rudimentary ability to interact with people. If you don't have these basic capabilities, you should probably be asking yourself how you managed to get the job you have now.

There's no magic wand for delivering software projects, no black art or burning of effigies, it's all to do with commonsense. If it's the right thing to do, it's the right thing to do, no question.

Plan ahead as much as you can. When things go wrong, as they inevitably do, don't panic or fret, just think about what will put you back on track, then do it. If people question your intentions or
strategy, question them back – things like 'Do you want to take the responsibility for the delivery of the project?' are always good. You can keep the 'I didn't think so', for a theatrical aside.

Always remember that you know better than anyone else about your project – after all, it's your project, you should know it better then anyone else. So, you decide what is required and then take responsibility for making it so. Remember, over 85% of people in senior IT positions don't know what they're doing.

Labels: C, Common Sense

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