Warning: sizeof(): Parameter must be an array or an object that implements Countable in /homepages/14/d120367860/htdocs/inth/wp-content/plugins/wordpress-firewall-2/wordpress-firewall-2.php on line 300

Warning: sizeof(): Parameter must be an array or an object that implements Countable in /homepages/14/d120367860/htdocs/inth/wp-content/plugins/wordpress-firewall-2/wordpress-firewall-2.php on line 300
The A-Z of Project Management Survivial | The Real Art of Project Management and Software Delivery | Page 9

S is for… Scrum Half

Sometimes you might think that dealing with problems is hard. But you’d
be wrong. All you have to do is break it down into the three main
choices and work from there. Think of a Scrum Half in Rugby Union. He
receives the ball from the scrum and can do 1 of three things:

1. Deal with it himself
Tuck the ball under his arm and go for it. You always have that
choice. Deal with it yourself. Often easier but you have to consider
the possibility of a Hospital Pass.

2. Pass it on
The Scrum Half oftens chooses to release the ball to his Stand-Off.
This is often the simplest and quickest choice. Pass the problem on to
someone else. This is particularly useful if the problem you receive is
a bomb and you can get rid of it before it goes off in your hands.

3. Punt It
Take the ball and kick it as far down the field as you can. This may
only delay the problem coming back to you but it might buy you some
valuable breathing space.

Take the problem, look at these three options and take it from there.
But remember, you may only have a split second to choose before 20
stone of sweaty descends on you and crushes you.

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.

    A is for… Appraisal

    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.

    C is for… Change Control

    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’.

    C is for… Consultant

    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.

    A is for… Avoidance of Failure

    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’

    K is for… Kicking (getting)

    As you go though your life in Software Project Management, you’d best learn how to take a kicking. For, 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 at Wimbledon: “I only lost a game of tennis, nobody died”.

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

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

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

    E is for… Ego

    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.

    I is for… Impossible

    “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’.

    G is for… Good Guys

    “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.

    The Real Art of Project Management and Software Delivery