O is for… Options

When your project, or indeed life is getting you down, always remember you have options.

Even when it may seem like you have no choice in something, believe us, you do. You perhaps just need to briefly take a step back from the coal-face and think bigger, or wider, or longer term.

Some people seem content to just let the world, and everything else, wash over them and accept the consequences. You’ll know lots of those people in life; they’re the ones that moan a lot about how bad everything is and how they never have any luck and how nothing ever changes. Well, there’s a reason for nothing ever changing, and that is because nobody’s done anything about it.

Believe it or not, there are people out there that enjoy their job. You can be one of them too! The trick is that you need to work out what your options are and make your decisions based on what you have open to you.

There are lots of examples in the A-Z about what to do in certain circumstances. Be creative and think about how you can apply them to your situation to gain the kind of outcome you would be happier with. Sometimes you need to include some of the more radical, even ultimate, sanctions in your options to give yourself some clarity on your situation.

You always have options.

You may not like the options you have, but you always have options.

U is for… Unavoidable

You may find yourself in the situation where something bad is going to happen and it appears to be unavoidable.

You need to do two things:

  1. Check that it is indeed unavoidable. Don’t take other people’s word for it, it’s your project; make sure there’s nothing you can do.
  2. Go through your available options. You do have options, you just need to decide which ones you want to consider and which to rule out.

Just because the dictionary definition of Unavoidable says, “Impossible to avoid or evade”, doesn’t mean it’s all bad. Given it’s going to happen, you should probably try to make the best of it.

So, can you perhaps;

  • Include some other bad news with this event, in a clever, 2-for-1 deal? No point in being hit twice when once will do now, is there?
  • Descope what you were originally trying to deliver to exclude some tricky stuff. And maybe pick those up as part of a new project/budget later.
  • Slip your project on the back of this bad news. It may have been close to slipping anyway, so grab yourself some leeway.
  • Get some more budget? You may have been short already and this issue will probably have wasted some of your budget.
  • Get some more (or better) people on your team. With better people you stand a better chance of delivering.

You’re looking for a way to turn a short-term negative into a mid- to long-term positive. Be creative!

In summary, batten down the hatches to ride out the storm and adopt a damage limitation strategy.

Finally, make sure you don’t get yourself into that position again.

Z is for… Zero-cost

In the world of software delivery, nothing is for nothing.

This is a key principle you absolutely need to get embedded into all of your team at an early stage in the project. It’s well worth taking the time to make sure, as it will potentially payback big-time in the long term.

The assumption is that you start off knowing what you need to do. If you don’t, then you have bigger problems to sort out; so best you do that first.

Still here? Good, you must know what you’re delivering. Now, anything to be done in your project should be assessed against what you need to do. If you do actually need to do it, fine, get it done. If you don’t need to do it, ask yourself why are you doing it?

There are many good reasons to do things you don’t actually need to. But with each of them comes a cost to your project, either in time, manpower, resources, or a combination of things. The cost of doing stuff certainly isn’t zero.

It’s up to you to assess that cost and weigh it up against the benefit of doing it. Then you work out what you can get back for it.

The cost side will generally be straightforward; do the sums.
The benefit side can sometimes be a bit more tangential; Maybe it will make things easier for your project later, maybe it will make things easier for someone else, maybe it will expand the scope of your project, in a beneficial way.

Once you’ve worked that out, you can then work out what you can get in return. Maybe you can get some extra budget, from another project, or someone will owe you a favour, or maybe you stack up some brownie points, or improve your credibility, all of which is worth something.

K is for… Kicking (giving)

As mentioned previously, there are times in your career where you will, sometimes through no fault of your own, be on the receiving end of a kicking.

Conversely, there will be times when you find yourself in the position of being able to give one out.

This will be a true test of your mettle in terms of the kind of Project Manager you choose to be. Are you going to be the kind that turns into a Tazmanian devil and rips up the furniture in a blur, leaving everything in your wake destroyed, and a lasting impression?

Perhaps that’s not the best way to gain the respect of your peers and team, after all you likely need to work with these people again, don’t you?

Sometimes the more subtle approach is called for. Besides, if you’ve hand-picked your team and taught them well in the ways of software delivery, then they probably know that they deserve a kicking and will be beating themselves up enough about it. Perhaps a quiet word will be sufficient to steer the ship back on course.

In any case, just remember; what goes around comes around, and your next kicking may not be too far off.

Q is for… Question Everything

It should go without saying, but I’ll say it anyway; question everything.

Whether it’s quotes from suppliers, statistics from your techies, reasons (or excuses) for issues from others involved in your project, you should check for the facts. The more confident you can be in the information you have to hand, the more in control of your project you are. And the more in control of your project you are, the fewer are the number of surprises that are likely to spring out of the woodwork to bite you in the ass.

Now, since you are reading the A-Z, you’re of course a pragmatist; you will know that things will still come out of nowhere to keep you busy, but no point in having avoidable hassle now, is there?

The converse is true too; don’t just question the bad news, verify the good news too. If your team are telling you, “Everything’s fine, we’re on target”, make sure you’re happy they are. After all, if it turns out they’ve been a bit over optimistic, it’ll be you that has to take the bad news to the customer.

So, take nothing at face value, listen to what people have to say, read what they send you, soak up the vibe. At least ask yourself if it makes sense to you and, if it doesn’t ring true, take it up with the source.

Also, if you’re not getting the level of information you want or need, go and ask for it, don’t wait for it to come to you – who’s running this project after all?

There’s a fine line between keeping on top of everything and paranoia. You want to be treading that line like a true pro. That way your troops will respect you rather than think you’re trying to do their jobs.

If you make assumptions and don’t question them, good or bad, you’re leaving yourself open to all sorts of potential future anguish. Best not.

J is for… Jargonaut

Have you been in a meeting and someone starts using buzzwords when they speak?
Do they use them repeatedly, even stringing them together to draw attention to their awareness?
Do they use them out of context?

If so, you may be in the presence of a Jargonaut. These guys fiegn knowledge of a subject by using jargon, often with amusing affect when in the presence of people who actually understand the context of the terms.

In days gone by, they would perhaps be “leveraging the synergies of a holistic cross-platform collaborative approach”. But they’re getting much more subtle now. So watch out for some of these things:

You’ll hear new age Jargonauts:

  • “Talking to a presentation”
  • “Working in the Enterprise space

Granted, some of these are always going to creep into general conversation, so don’t jump to conclusions. But if someone does this more than once, or in quick succession, you should be raising an eyebrow. If they use them constantly, you know you really are in the presence of brilliance.

G is for… Grunt

Not everyone can be a star, and there are many people who do just fine not being a star. They don’t crave the limelight, they don’t particularly want the attention, they just do a good, solid job and are happy that you thank them for doing just that.

These kind of people are essentially your grunts, the engine-house of your team. These are the guys that deliver stuff for you, day-in, day-out. You need them on your team.

If you have a team full of experts and stars; let’s call them Prima-Donnas, you will spend all your time massaging their egos, making up for their shortcomings, apologising to people they’ve annoyed or upset and stopping fights between them. They’ll take up a lot of your valuable time.

While you absolutely do need both in your team, you need to watch out. If you want your team to deliver, and not just postulate and come up with whizzy ideas, you would be well placed to make sure you have a high Grunt to Prima-Donna ratio.

R is for… Railroader

The railroader is the kind of person that will use his personality and blind determination to force his ideas through, regardless of other popular, or learned opinion.

You’ll easily be able to classify a Railroader when you encounter one, they typically talk over other people, usually starting when the have a grasp of an idea and think they can run with it. At this point, they genuinely think they know better than everyone else in the room, including the person who was talking.

You can try to go toe-to-toe with a Railroader, and keep talking over them but unless you have the presence or seniority to carry it off and they stop, it can quickly degenerate into a babble-fest where the rest of the assembled group will be wondering what’s going on.

One strategy is to use distraction to shut them up, like the magicians do. I don’t suggest the, “Look, an eagle!”, approach. More the open handed-stop signal, holding up your finger or pen as a blocker, hand on the shoulder, other ways to knock them off their stride. But be aware when they’ve sussed what you’ve done, they’ll just start off again.

The best strategy is to let them talk themselves out first. Then pitch in with the real solution, as it’s highly probable they have not grasped the whole situation and have gone off half-cocked.

That way you end up looking like the one that knows what they are talking about, which is about right.

X is for… Xenophobia

To offshore or not to offshore: that is the question.

If you’ve worked any length of time in IT and/or worked for any of the larger companies, the subject of offshore will have undoubtedly come up. The bean-counters love the idea of offshore. Usually with the disheartening cry, “It’s so cheap. The rates are less than half that of our guys. We can’t lose.”

Well, let us tell you here, loud and clear, yes you can. Big time.

We at the A-Z are not Xenophobic, far from it, we like to think of ourselves more as stupophobic. We are firm believers that there is no golden arrow, no global, one-size-fits-all solution to any and every IT problem. Lots of things need to be considered on the path to successfully delivering IT soluions.

Whether it’s India, Malaysia, Russia, Israel or any of many other locations where extremely unit-cost resource are waiting to do your bidding, the deal is the same: use them only if it’s the right thing to do, and do it under the proper conditions.

You wouldn’t recruit a someone off the street who showed you an impressive CV and let him loose on your most complicated, business critical code, in the same way you wouldn’t hand your car keys to the first person you met at the shops.

So treat it the same way you would any other recruitment-for-purpose task. Define the roles, review the CVs, interview the best candidates; test them if appropriate, locally if necessary. Only when you are sure you have people capable of doing what you need them to do should you consider taking them on.

Like you would with any newbie, define clearly what you want them to do and monitor their progress closely. If they are delivering successfully, give them a bit more responsibility. You should be able to reasonably quickly gauge the calibre of your new recruits. If they’re no good, then get rid and replace.

Don’t underestimate the management overhead of having a separate offshore team. That’s your, or your team-lead’s, time we’re talking about so it’s important time.

In summary, don’t immediately discount the idea of offshoring, but if you are going to do it, do it right, under the right conditions and with the right expectations set beforehand.

S is for… Surely

“Surely” is a word that should not be in the vocabulary of the vigilant Project Manager. Uttering phrases like, “Surely the customer knew we would…” or, “Surely the software is able to…” or even, “Surely they don’t expect…”, means you have made assumptions.

When you make assumptions you are leaving yourself open to all sorts of problems down the line that will, of course, materialise at the worst possible time.

Assumptions are a bad thing and are best left to the amateurs. Since you’re a good PM you will be keen to be across everything in your project and you will have thought throught the ‘What-if’ scenarios, giving you time to put any mitigation plans into action.

So, do your homework, make sure you know what is going on and don’t get caught with your pants down. But surely you knew that…

The Real Art of Project Management and Software Delivery