The A-Z of Project Management Survival

G is for... Grunt

2009-07-19T23:00:00.000+01:00

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

2009-07-18T23:00:00.004+01:00

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

2009-07-15T23:00:00.006+01:00

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

2009-07-15T23:00:00.004+01:00

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

F is for... Forms

2009-04-02T22:16:00.004+01:00

Here's a game. You'll like this. Listen carefully.

In any organisation there are essentially two groups of people. People who know stuff. People who don't really know all that much.

In many, many cases the people who don't know stuff try to find stuff out by getting the people who know stuff to fill in forms or spreadsheets. It makes them feel useful. It makes it look like they are doing work. But in the end, they still don't know much stuff and they've just wasted a lot of time.

"Fill this form in so I can approve..." - does that mean they understand?

So, here's the game. When you are in work, just walking round the office, or in a meeting maybe, decide which of the two groups people are in. You'll be surprised by how many people fall into the "gaining information via the medium of forms" gang.

And if you spend all your day getting people to fill in forms then... better not finish that.

M is for... MBWA

2009-03-24T23:00:00.000Z

Management By Walking About (MBWA) is a much underrated mechanism to keep an eye on what is going on in your project.

As things have evolved technically over the years is becomes all too easy to orchestrate, or attempt to orchestrate, your project form the comfort of your adjustable office-chair. Using eMail, Instant Messaging, Text Messaging, etc. to deliver your guidance and expert opinion.

However, while you may like to think you are some kind of techno-mastermind of all you survey, the chances are you're missing out on a lot of the crucial information you really should have a firm grasp on.

If you're only reading the written word, and worse, only spouting it too, you are missing a huge percentage of the other parts that make up that thing we call human communication.

Without getting the real 'word on the street', complete with intonation, attitude and accompanying body-language, you've only got part of the picture.

Have you ever said to yourself, "I didn't realise it was that bad" or, "They should have said there was a problem", then maybe you need a bit more 'face time' with your team, customers or co-workers.

So, If you want to keep on top of what's going on, get off your arse and walk about!

H is for... Heroes

2009-01-24T23:00:00.001Z

We've all seen them, the guys that work all hours, they are always first in and last to leave, they seem to always be in the thick of it, people are always waiting for them to do something before they can move on, they're always on-call, if they're not still on-shift.

There's no doubt that out there there are some of these types, and they will be genuinely good, valuable people who do some really good stuff. Yay them, keep it up guys. You're keeping it all hanging together, thanks! Just be careful when you're crossing the road please.

However, there is another side to this genre though, and you'd be well advised in learning to spot them. These are the self-made heroes. They're not really heroes, they just play a clever game to make people think they are heroes. Really, they are manufacturing a need for themselves, they are making themselves indespensible because no-one eles could possibly do all the stuff they do, know all the things they know or sort all the problems they sort.

Watch out for them, they avoid passing on their knowledge, the learn new stuff and keep it to themselves and, best of all, the real pro's in this area will manufacture problems that only they can fix. Allowing the yet another opportunity to ride in on the big white charger and save the day.

X is for... Xanadu

2009-01-24T23:00:00.000Z

At the beginning of your project, when nothing's really happened and you have a vast pot of cash to spend, you can be excused for thinking that you've fallen into something Samuel Tayor Coleridge novel depiction of the opulence of Xanadu.

Just remember the money has to do you for the duration of the project, not just to buy toys for the project geeks to play with.

Also, this is a time to watch out for other projects, which are starting to feel cash-strapped, coming to you and asking you to fund something for them. You know, "I've been told I need to get some licenses, and we didn't include them in the budget, could you..", or, "We've got this resource, he's quite expensive, but he could do some work for you too, as long as you don't mind footing the bill.", etc.

It's time to double-check your sums and put away your slush-fund, because you're in this for the long-haul.

H is for... Horses for Courses

2009-01-22T23:00:00.001Z

There are hundreds, maybe thousands of tools, templates, strategies, techniques, approaches and methodologies out there. There are lots of really good ones, in fact most of them probably are, or at least were great at what they were developed to do at the time they were developed to do it.

So, it can be a difficult time for you deciding what to use on your project.

Some things will be a given, taken for granted, others will need to be sourced and decided upon. You can seek opinion from your team, peers or even management about wwhat you should use or what approach you could take. But, as the person tasked with delivering the project, it should ultimately be your decision as to what you go with.

The main thing is to use the right tools for the job. If you're thinking of adopting a new methodology, it makes sense to read up on it first and then decide if it would be suitable for your project. It's a big internet out there, there's lots of people willing to share their experience or opinion about just about anything.

Just because it's new doesn't make it good. Similarly, just because it's been around for a while doesn't make it any less relevant today.

What you have to do is balance up the options of the team's experience in the tools/methods the changes in process, the risk of introducing something different.

Use the right thing for the right job, and your life will be significantly less complicated.

Y is for... Yellow Stickies

2009-01-22T23:00:00.000Z

A firm favourite, the Yellow Stickies tend to get pulled out at workshops as a way of capturing opinion from the assembled workshopees.

While workshops, if they are run properly, are a good thing, the widespread use of the yelow sticky as a means for "getting all the issues out in the open" or "having a stab prioritising the workload" is often badly over/mis-used by people that don't know how to run a workshop properly.

How many times have you seen the "facilitator" scurrying away after the meeting, with a huge pile of flipchart sheets covered in stickies rolled under his arm. Odds-on that's the last you will see of them.

Yellow Stickies in a workshop is an example of a Horses for Courses item; if you cant use it effectively, then don't use it.

** You know what Yellow Stickies are. The A-Z isn't sponsored, so wouldn't want to fall foul of promoting a particular brand, like Post-It from 3M, do we now?

L is for... Lame Excuses

2009-01-21T23:00:00.002Z

While you may find some interesting techniques in the A-Z that will help you navigate through the stormy waters of Software Delivery, be careful not to flounder on the rocks of the Island of Lame Excuses.

Always remember, first and foremost that you, as the Project Manager, are wholly responsible for the delivery of the project. It's up to you to mobilise the resources, plan accordingly and steer your project carefully to the Land of Success.

Never, ever resort to, "A big boy did it and ran away", or somesuch nonsense. Poeple will not react kindly to that kind of excuse and will almost certainly think less of you and your delivery ability.

If you have made a mistake, judgement of error, or otherwise hit upon a problem, then stand up and admit it. Take your kicking and move on; consider it an educational exercise, and make sure you put the necessary things in place to afoid falling over that particular problem in the future.

One thing though: Before you admit the problem and take your kicking, best to have the solution to the problem already implemented or, at least, up your sleeve. Otherwise you'll look a real idiot.

V is for... Victory

2009-01-20T23:00:00.001Z

So, you're at the end of your project and it's finally gone live and, best of all, it's working! Well done you, it's a good feeling isn't it?

You'll probably have a bit of a euphoric feeling. Like some other analogies in this guide, it's a bit like winning a battle against all the odds, despite other people and projects. Yes, it is a victorious time; lap it up, the next one is undoubtedly just around the corner. Maybe, like the Red Baron, you can slap a little silhouette on the side of your metaphorical triplane; another one down, now who's next?

Ensure you remember it wasn't just you that made this a success. Make a point of thanking your people, your team, they need to know you are grateful for all the hard work they have undoubtedly put in. Take the time to thank them personally because then they know you appreciated their contribution and that you're not all taking the credit for the success yourself. It will also make it easier when the time comes to recruit a team for your next project; people who feel appreciated will want to work for you again.

This is also a good time to position yourself, with those who have influence, as the go-to guy/gal if you want your projects delivered successfully. that way, you should hopefully have more choice on your next assignment, or maybe just that they will listen more carefully when you make your demands at project start-up time.

V is for... Vapourisation

2009-01-15T23:00:00.001Z

Sometimes you are stuck with people on your project that you could, quite frankly, do without. They may just not be up to the job, or there may be something else they bring to the party that detracts from the team's ability to deliver.

This can happen for a number of different reasons; Perhaps you inherited them when you took over the project. Perhaps they have been foisted on you as a result of a management decision. Perhaps they were sold to you as a guru, or the best person for the job.

The assumption here is that you cannot simply remove them from the project, because you would have by now and you wouldn't have a problem. So you need another way out. One option is to minimise the effect of these people, but sometimes Vapourisation is the only way.

One thing to bear in mind is that whining about your resources is never a good thing. People will think you're just making early excuses for your future lack of delivery, or label you as a whiney project manager. But, more importantly, always remember that it's your team that will deliver the project, under your excellent guidance of course, so it's probably best not to alienate them. So removal by stealth is the key.

One approach is to give them responsibility for the delivery of something, ideally not too critical, and let them prove their obsession with their chosen speciality subject gets in the way of delivering, effectively letting them fall on their over zealous sword. Now, you've proved they're no good, they should be ripe for removal...

M is for... Marginalisation

2009-01-14T23:00:00.001Z

Sometimes you get people on your project that are a danger to themselves, let alone anyone else or your project. On occasion, they are actually OK in terms of their knowledge of the subject matter, but you wouldn't trust them to deliver newspapers.

If this is the case, you may wish to assing them an 'advisory' or 'consulting' role without any real delivery responsibility. They could maybe coach some of the more junior people in your team in their area of expertise. If you sell it correctly, there's a good chance they will be happy in the respect you have in their knowledge.

That way you get the benefit of their knowledge without the associated failure to deliver; just make sure you give them some boundaries and keep a close eye on them.

H is for... Hell

2009-01-10T12:30:00.003Z

Sometimes, when all seems lost, and you think you are in PM Hell, turn to the words of Mr Kipling. No, not the 'exceedingly good cakes' one...

"If you can keep your head when all about you
Are losing theirs and blaming it on you,
If you can trust yourself when all men doubt you,
But make allowance for their doubting too;

...

If you can fill the unforgiving minute
With sixty seconds' worth of distance run -
Yours is the Earth and everything that's in it,
And - which is more - you'll be a Man my son!"

It's worth reading the whole thing, if you haven't already.
Now, we're not saying you should run your project with this in mind, but it may make you feel better when the fan is up to full speed and the shovels are fully loaded.

Taken from 'If' by Rudyard Kipling

V is for... Value For Money

2009-01-09T23:29:00.003Z

If you have to staff up a project from scratch, there's a good chance you will not have all the skills and resources you need on day one. If you cannot beg, borrow or steal the resources from within your organisation, a common way to plug some gaps in your team, or bring in specialist knowledge, is to use contract resource.

Some of these guys are expensive, some are extremely expensive. But you have to weigh this up against what you get for your money. As they say, if you pay peanuts, you can expect to attract monkeys.

However, you cannot assume that because someone is expensive, they are any good; you have to apply the usual sensible measures when you recruit and select the right candidate(s). Check them out, interview them well, make sure they know their stuff and that you think thay will add value to your team.

If the ones you think are the best turn out to be more expensive than you'd planned for, then it's down to you to make the decision on how you balance up your likelihood of delivering with an 'A' team or the cost of failing to deliver with a lesser skillset/capability. That's what YOU get paid for.

S is for... Slush Fund

2009-01-05T23:00:00.002Z

So, you've just been told about your shiny new project, and everything is all exciting and ready for you to stamp your authority on it and tell everyone how it's going to be done. It's great when it happens like that, isn't it? I'm sure you've got loads of time to deliver too...

Well, you'd better get your finger out and start pulling a budget together. You'll be wanting to get all your requirements and estimates sorted out, and your team, and your kit, and your licenses, and desks, and... What are you waiting for? You'd better hurry up, the clock is ticking you know.

Assuming all of that has gone swimmingly and your project is well underway. What happens when something unexpected comes up, like a change in the design means you need a new batch of licenses, or a misunderstanding of a requirement means one of your estimates is woefully light, one of the team takes a lot longer to complete their tasks?

Maybe you have an understanding boss, or a customer with deep pockets and an understanding nature. If so, then you can stop reading this one now and have another sip of ambrosia, provided your at-the-desk masseuse is finished.

If you're still here, then this is when the Slush Fund comes into play. When your budget was compiled, was there contingency included in estimates for tasks that are now complete, are there any things that are no longer required, are there things that could be descoped from the project or deferred to a separately funded phase? Gather all those little pockets of cash together and see if that can be released to make up for your omission/issue. If so, you've probably avoided a bullet, for now.

Note: Some people may surreptitiously include extra dosh in some tasks or over-egg their estimates to include some slush when the budget is originally compiled. Of course, while the A-Z would never condone such a practice, it recognises it is a reality.

P is for... Procrastination

2009-01-04T23:00:00.002Z

There is a school of thought that is rife amongst the more timid of the lesser spotted Project Manager, and that is that if you ignore something for long enough, it will go away.

While this may be true for such things as his acne and his girlfriend, it is generally never true about software projects. If you ignore a small thing long enough, it will become a big thing and when it becomes a big thing, you are more likely to feel the pain.

Of course, if you know what you're doing you will be aware of even the small things on your project and will make a conscious decision on whether you should do something about it sharpish or you can safely let it ride for a while.

What you do about it will, of course, depend on the issue and your own personal style but be sure you do something and don't just defer the decision till tomorrow. Tomorrow will have enough challenges of its own.

B is for... Blamestorming

2009-01-02T14:31:00.005Z

This term will likely be familiar to anyone that's been on an IT project, it describes the point of sudden realisation that there is a problem on the project and a scapegoat is required.

Really it shouldn't work that way, people should undoubtedly be focussing on solving the problem and delivering the project, but these days it seems that there always has to be a post-mortem and a, consequently, a culprit found.

The meeting may take a number of different forms, or have a number of different titles, like "Process Improvement Workshop", or "Post Implementation Review", but in essence it will turn out to be a drains up blame-fest. You can usually gauge how much of a kicking is going to be dealt out by the seniority of the attendees. There may be even a series of blamestorming meetings to get the story straight before the upper management get told the story.

As you attend more of these meetings, you will witness people who have never moved quickly in their lives suddenly acquire the speed and adaptiveness of gazelles being pursued by a cheetah and reknowned trouble-makers will become strangely slippery, as if lubricated with some kind of advanced silicone compound.

Best go prepared to these kind of meetings, because the black spot will need to be finding a home, and you'd be advised to make sure it doesn't unfairly land on your lapel. Of course, if you are a Good Guy and have followed the advice in this guide, you will already be well equipped and have nothing to fear.

At the meetings, watch out for the phrases, "This isn't intended to be a witch-hunt", and, "We're not looking for a scape-goat here".
It is, and they are.

S is for... Sponge

2008-12-28T21:00:00.006Z

The sponge is another example of a PM out of his depth trying to add value to his project.

His project team will be telling this PM there are problems on the project, they will be sending him progress reports coloured in heavily in red felt-tip pen, they will be telling him things like, "We're going to be late", or, "We're easily going to spend double the budget", or, "We need help!"

The sponge will happily absorb this bad news and report to his management that everything is fine, brilliant in fact. So much so, the Sponge will be looking for more green felt-tip pens in the stationery cupboard. He will blissfully continue in this fashion until the point where he can hide it no more. He thinks he's keeping the management happy by telling them what they want to hear and will get gold stars and plaudits in return.

Similarly, any criticism and/or bad news, coming from further up the hierarchy, towards his project team will be soaked up by the Sponge and kept from the poor souls on the team. His management will be telling him, "The business are concerned with the lack of progress", or, "The budget seems a bit tight, do we have enought to complete?", or, "Are you sure you'll deliver what we promised on time." By acting as a Sponge, he thinks he's protecting his team from the bad press.

At the end of the day, it will all explode in his face. Carnage will ensue, with the finger of blame being pointed at everyone and everything.

A is for... Agile

2008-12-11T16:15:00.008Z

First, let's be clear - Agile is a software development methodology, it's not a 'save the world/software delivery panacea', and in a lot of ways it's really a collective re-badging of stuff that's been around for ages.

The Good Guys will recognise a lot of this before, but others will cling to it thinking it will somehow magically make software development faster, better, cheaper, etc. There are plenty of books on the subject and most will tell you it DOESN'T solve everything, it's NOT necessarily faster, or cheaper, and there are certain projects or situations you should NOT use it.

Agile brings with it lots of new exciting terminology and lots of new fabby techniques, or does it? Let's compare Agile with DSDM and XP, or, if you're old enough, RAD or JAD (whatever happened to that), and let's compare it's new fancy buzzwords with, well, errr, plain English really.

Stories: A narrative describing something to be delivered. The old skool will recognise these as 'Requirements' (Epics = High level requirements).
Sprint: A defined period of time where everyone works hard with the objective of delivering something. XP calls them Iterations, DSDM called them Timeboxes in the olden days
Scrum: When the team all gets together to discuss what to do. Sound familiar? Yes, a 'Meeting'
Standup: No, not a comedian, but by now, you are may be beginning to wonder. This is where the team all gets together quickly to discuss what to do, without sitting down. You will undoubtedly recognise this in the real world as a 'Short Meeting'
Refactoring: Restructuring or changing existing code to make it work differently. Yeah right, you may be more familiar with the terms 'Fixing' or 'Debugging'

We could go down to the level of discussing 'dunces hats', and 'visible build indicators', but you're probably getting enough of an idea already. It's all been done before and those in the know have been doing it for years without the daft names. Suffice to say, if you've mobilised a teamlet, who've assigned a story-captain and they're now swarming on a work item to burn down a story, you're already too far gone.

The bottom line is that Agile is like any other methodology du-jour; it's right for some things and not for others, it has useful bits and irrelevant/pointless bits and it has people who know about it and understand it and people who think they know about it but don't.

Watch out for the latter; the methodology evangelists. These are the people who will say things like, 'That's not the Agile way', 'We should have a stand-up to resolve this', 'we must use xyz software to track with' (it'll be a beta release of a freeware hack that only runs on an obscure version of Linux, or a Commodore 64 and requires you to be a seventh level mage to sign in), and generally strut about looking like they know it all.

Agile works best if you can isolate everything from the real world; the project team, their development kit, the users, the testers, the delivered system, all common sense. Strangely, us real world guys know it's just not as simple as that...

Anyhoo, like all methodologies, it's only partly about the methodology, it mainly comes down to the people executing them; if you have enought good people, they will stand a good chance of delivering. However, if you don't, then the combination of that coupled with the use of a methodology new to those people , no matter how new and sexy it is, or wacky it sounds, will likely result in chaos.

S is for... Scoob

2008-12-11T11:35:00.010Z

The working assuption here is that the reader has a Scoob** either generally or specifically. To deliver projects successfully, you need the people that have the Scoobs to help you.

If you're on a project and there's noone else with a Scoob, you're in trouble.
If your management don't have a Scoob, you're in big trouble.
If there's noone else you can turn to in the organisation that has a Scoob, better man the lifeboats.

Unfortunately you can't go the the shops and buy a 'Big Box of Scoobs' to get you out of trouble, but you can do the PM Survival equivalent; find yourself some Good Guys and get them onto the project pdq.

** For the uninitiated, Scoob is short for Scooby Doo which, in turn, is rhyming slang for 'clue'.

L is for... Lost Dog

2008-12-11T11:15:00.007Z

Recognisable from the fact they move quietly from meeting to meeting, with their metaphorical tail between their legs, the Lost Dog generally has a doleful expression on their face.

You'll spot them as the person who always seems to be in all the meetings you go to, but rarely contributes much. Very much the antithesis of the Echo, they will sit quietly, desparately trying to keep up what's being discussed, perhaps nodding occasionally and generally only speaking when directly invited to and then saying a little as they can get away with to avoid appearing scoobless.

Much of this is due to the fact that they feel overwhelmed by the topics being discussed. You will find many Lost Dogs in large organisations, particularly where the technology has moved on and they haven't. They're always busy, mainly because of the number of meetings they need to go to, but also because they're following somone around.

E is for... Echo

2008-12-10T14:43:00.004Z

It's never nice to see someone struggle. But as we know, people who are struggling tend not to stay as quiet as they should. Not being able to contribute is one thing, but using up air-time for the sake of an apparent contribution is frankly a pain.

Another facet of the Competency Mask is the Echo. Someone explains something and then the arse in question says pretty much the same thing again with perhaps only a slight change in wording or emphass. In the worst cases, the repitition is near to verbatim.

This obviously wastes time, but what is more galling is that the repitition is done with no shame, with aplomb perhaps "look at me, don't I sound clever".

No, you don't, you're an arse. You gave it away with that echo. If you get a chance say "is there an echo in here" immediately after. They won't know what you mean but it will make you feel better. Others may snigger.

You'll hear these echo people all the time. Take note of them, it's as good a giveaway as a big badge with 'useless' on it.

R is for... Rug

2008-12-08T11:30:00.005Z

The world is an imperfect place. Projects more so. This needn't always be bad news. Keep an eye out for things going wrong that aren't your fault and lie outwith your control. They can be very useful, particularly if there are other things amiss that your are accountable for.

If you get a rug. Use it. Bury your bad stuff under it and carry on. It's really very simple...

"Yeah, we were on track but (someone else's problem) happened and we couldn't get our stuff completed."

They will come in many shapes and sizes. The obvious ones are usually infrastructure related, server death etc.

Using a rug is simply an opportunistic version of Schedule Chicken. Rather than taking a chance that someone else's misfortune might benefit you. You simply pounce on the chance when you get it. It often makes sense to pounce on it when you aren't directly impacted. No harm in building up some excuses.

Even if you don't have any issues, get used to spotting rugs. Say to yourself "ooh, that's a rug" when you see one. But not too loud. You don't want people thinking you're mad.