The A-Z of Project Management Survival

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.

Labels: N, Nepotism

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.

Labels: F, Flawed

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.

Labels: O, Ostrich

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.

Labels: B, Bermuda Triangle

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

Labels: U, Use your tools effectively

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.

Labels: Y, Yesterday

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.

Labels: S, Scoping-Sword

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.

Labels: W, Workshop

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:

1. They fail to say no.


2. They fail to delegate.


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

Labels: O, Overload

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.

Labels: D, Dambuster

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.

Labels: R, Rescue

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.

Labels: G, Grapevine

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.

Labels: C, Competency Mask

There is a very well-worn phrase that tells how "all good managers delegate". This is indeed true, but it doesn't take the story far enough. In addition to delegation, you have to trust the person too. And that means, tell them what you want them to do, when you want it done by and then leaving them alone. If it isn't going to happen, trust them to tell you as soon as they know.

The simple fact is, if you can't trust them, if you need to hand-hold all the way then they are maybe a good candidate for a role re-alignment. After all, there isn't any point having anyone in a professional environment that you can't leave alone to complete a task.

Trust is also a key tool in people development. Generally inexperienced people are never too sure how good they are or what they are capable of. Your job as a manager is to understand their limit and to push them to it or just beyond. Trusting them them to get there.

Again, trust is not something that a fearful arse can do. Which is why people tend to hate working for them.

Labels: T, Trust

As discussed previously, one of the most useful tools in the armoury of the Project Manager is common sense. This, coupled with a healthy dose of pragmatism will help you deliver projects that work.

Take a look at your project. No, not your Microsoft Project Plan, that’s not your project, that’s your plan. Take a look at the project, the objectives, the requirements, the timeline, the resources, the environment, the dependencies, the risks, the issues, the external factors, the team structure, all of these things. Now, ask yourself some questions: “is this the best way to do this?”, “is this the right way to do this?”, and the most important one, “will my project deliver?”

Just because the manual or somebody else in your organisation says you should to do it a certain way does not mean that is the right way for your project. Take the pragmatic view, do what needs to be done to deliver the project.

Labels: P, Pragmatism

They call themselves Project Managers but all they really do is collect timesheets and other such frippery. You need to spot these people quickly and ignore everything they say with regard to delivery as the very fact that they call themselves Project Manager signifies that they are an arse and therefore will not obey the law of silence.

Once you have spotted them, you can have fun with them because they will be constantly scared so ask them tough questions, make them make on the spot decisions and generally wind them up. Obviously, ignoring any responses you may get.

Labels: T, Timesheet Collector

Your team are the single most import element in the success of your project. They equate to a lot of the eggs in your metaphorical project-basket. If you cannot rely on the individuals in your team to do their best for the cause, then you really need to consider whether they are suited to a career working for you.

Sometimes you can have a go at re-aligning their attitude, but you can only change a person’s behaviour and not the person, so 95% of the time you will find they will eventually revert to type. Bear in mind, the longer you carry the baggage, the more it is costing you, and the less return on your investment you are likely to get.

Add to this the negative effect they have on the team and project that you will have to recover afterwards, and you should be arriving at one conclusion: it’s better for all concerned to jettison the excess baggage sooner rather than later.

No-one said this job was easy, or pleasant, but the mark of a good manager is being able to do the tough things with equal professionalism and clarity.

Labels: J, Jettison

The most infrequently used and most powerful of all managers weapons. Try it, it can be a real treat. The next time your customer says "This isn't good enough, why is it going to be late?" just reply with a simple "It has taken longer than we thought it would."

The thing is, there is very rarely an good substitute for the truth. If you genuinely believe that the truth would be counter-productive then the only viable alternative is silence.

Also, being absolutely honest with the people working for you is imperative. Remember, as a manager, there is generally very little you can do to directly influence the outcome of things. So having a team of people who trust and believe in you is the key. You can get this by showing them that you are an honest and trustworthy individual.

Arses avoid the truth through fear as they believe that somehow the truth is likely to get them into more trouble. The truth is at the core of all damage limitation. Some quick, sharp, upfront honesty can go a long way to sorting out the most complex of issues.

Labels: T, Truth

Its something that almost all text books won't mention but is to blame for more mistakes that almost anything else. As we have already established, most people working in IT are not very good at it and, those that know they are out of their depth, are typically either paralysed or hamstrung by fear. Decisions made in the context of fear are almost always bad ones. Conversely, a good way to spot a Good Guy is see that someone has no fear in any situation.

Fear does very strange things to arses. It has a tendency to make them avoid the truth and to concoct and intricate web of nonsense that they believe sounds more plausible. It also makes them very tetchy and have a strong tendency to snap at people for no reason. Almost always this is because people want to avoid a kicking and are not understand the basic rules of damage limitation.

Sometimes the only thing that stops an Arse being a Good Guy is their ability to handle their fear. Often they are intelligent, decent people who, through lack of bottle alone, make an arse of things. If you are not scared, you are thinking clearly, so always take fear out of the equation.

Labels: F, Fear

Zealous individuals are more active that intelligent, so can be pointed kamikaze like at problems coming at you like a train. They can then be blamed, and action taken to remove them, saving the project manager by diverting blame - he is seen to have taken decisive action.

Labels: Z, Zealous

It’s often said that it’s not what you know, it’s who you know.
Well, if you are to survive in Project Management, you need to a foot firmly in both camps.

You don’t need to know every intricate technical detail of your project, you will have people that have that covered for you. And, of course you will be able to bluff your way through any probing that may come your way. Make sure you have your generals in place.

You don’t need to be on intimate terms with everyone in your organisation. However, you should take the time to work out who will be able to help or hinder the success of your project before you decide to practice your character assassination techniques on them or their projects. Get some good contacts in other projects.

What you absolutely, without question, need to know is what is going on. Both within your own project and in other areas that affect your project. So practice that oft underrated management methodology of MBWA (Management By Walking About).

Talk to people, suss out who they are, how they affect your project, how they fit in to the general scheme of things and of course whether they fall into the good guy or arses category. Find out how their projects are doing and what problems they are encountering, and how they are resolving them. Look listen and learn - store all this up, one day it will come in handy.

Labels: I, Information

Let's face it, even if you are a good guy and you put all the best-practice you learn from this guide into your life, things are going to go wrong sometime. Of course this is 99% likely to have been caused by external influences, because of course everything under your control will be, well... under control.

This is where knowing what you are doing comes into play. You will of course have seen it coming, your awareness of all the information available to you will have primed you. The earlier you see it coming, the more time you have to formulate your plan of action to turn the 'problem' into an opportunity for the benefit of your project.

The key is to be as up-front with the problem and your proposed solution (don't forget that bit) as it is sensible to do, and to the right people, at the right time. No point in telling your Financial Director that your project needs an extra $500k, because someone forgot you might have to pay for software licenses, on a Friday afternoon, in the middle of his month-end reporting. He is likely to and, in fact legally entitled to rip-you-a-new-one before you even get to the end of the sentence.

You need to be all over the problem as soon as you see it coming, and find ways to limit the pain that is likely to be coming down the line. Consider carefully your options, and the rest of this guide will give you plenty of ideas; Can you change control it? Can you do it another way? Can you sell it as a better way to do it? Can you call in favours? Can you get someone else to carry the can? The more experience you have, the more creative you will get.

Sometimes it's better to hold your hand up early and take your lumps then, than wait till the issue reaches its full magnitude and get a bigger kicking then. After all, it's hard to be hung twice for the same thing.

Labels: D, Damage Limitation

People, especially customers, forget the real definition of an estimate. Its an estimate. Not a guarantee. But because they forget this they are generally unhappy if a delivery is going to be 'late'. And with lateness comes blame. And, good guys don't get blamed. Its the arses fault.

Good guys get out of this blame problem by getting good at the ancient art of Schedule Chicken. In every delivery, there is almost always a set of dependant deliverables. To win the game all you have to do is bet that one of the other deliverables will deliver late and, crucially, declare they are going to be late before you have to. Therefore, you gain the extra time their slippage offers.

So, the easiest way to for you to get some slip in your project is to let someone else do it for you and, presumably, take the blame.

Schedule Chicken should be played with caution and definitely not by an arse. Watching an arse attempt to do it is however, very funny. This is particularly good when an arse is playing schedule chicken against you and you know you are going to deliver on time. Supply misinformation that suggests to him, off the record, that you might be a bit late. He'll rub his hands together in glee hoping that you have given him a way out of his own slippage. This joy will be short lived as he finally declares that he is unable to deliver one day before the project is due and is ripped a new one.

Labels: S, Schedule Chicken

At comedian-school (if there is such a thing), they teach you that timing is everything.

The same is true in managing a project, and how proficient you are at getting the timing right will often be the key to glorious success or cringing failure.

Sometimes you will need to act immediately, usually to quickly defuse the potential onset of panic, a state often induced by people suffering from 'little knowledge' syndrome.

Other times you should bide your time and wait for things to pan out, often issues will resolve themselves or at least clarify themselves to the point that you can quickly determine a solution.

To some, the understanding of when and how to act will come naturally. Others will be able to hone this skill with experience. Managers who don't fit into either of these groups will be those whose projects you will eventually be asked to rescue.

Labels: T, Timing

Optimism is reserved for misguided souls and high-level management.

You need to be better than that, you can't sit around and hope it'll all turn out for the best. You'll be dead in the water if you subscribe to such fanciful notions, look around you at all those failed projects.

One thing you need to remember is that you need to make your own luck to be in control your project's destiny. Few bosses hand out gold stars for, it wasn't my fault. Not even McDonalds do that.

Think ahead; put the necessary steps in place to prevent the bad things happening, get the right people (see good-guys) involved to make sure the right things do happen, and when people say you were lucky, that worked out well, you can afford yourself an inward wry smile.

Labels: O, Optimism

Perhaps not always closely associated with Project Management, Tennis should never be far from your mind. It works like this. When a customer is waiting for something from you the ball is on your side of the net.

This is bad but not disastrous. You don't necessarily have to give them what they want to get the ball back over the net. By simply seeking clarification or asking them a question you can easily get the ball back on the other side of the net. This is good. The heat is now off and you can concentrate on the bigger issues. Practice batting the ball back as often as you can and you will quickly learn how this strategy gives you a more relaxed transition towards the grave.

If tennis isn't your thing, think of the little clocks they use in chess. You're job is to keep the customer's clock ticking. Take great glee when you slam the switch on your little clock down.

Labels: T, Tennis

You would think that there won't be many instances where silence can be your friend. But you'd be surprised. Sometimes you will feel the need to contribute "I'm in charge here, I should be saying something." Most of the time you should fight this urge.

Admit it to yourself. There is an awful lot you don't know about and are wholly unqualified to even speculate on, never mind actually contribute. On these occasions, don't burble nonsense because of some misguided need to take part. You'll just look like an arse. So shut it and listen. This isn't about you and your ego, its about getting the problem solved.

You could always try and be useful and supportive. Try phrases like "You guys have this one covered, let me know if there is anything you need me to escalate."

Just don't say things like "Have you tried turning it off and on?" Its not helpful and your team will have a lower opinion of you based on an increasingly correct notion that you are an overpaid waste of oxygen.

Labels: S, Silence

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.

Labels: S, Scrum Half