A few months ago, I discussed a project that had gone awry. Things got bad and in the end, they did what most teams in this position would do: They blamed it on the contractors and fired them.
Of course there is more to the story. I was actually in the 2nd volley of programmers. There were 3 or 4 more volleys after that.
It is hard to imagine any IT department hiring, blaming and canning that many contractors without anyone getting suspicious and eventually coming to one of these conclusions:
- It seems so unlikely that all of the contractors were to blame.
- Several other places don’t seem to have this problem with contractors.
- Is it possible that there is a common factor here, other than the contractors?
Survivor, Work Edition
Surprise! Eventually, someone suggested that maybe the problem wasn’t the contractors. So, that only left the employees. Since nobody could identify a way of resolving the problem, they stuck with their current pattern and started acting-out the TV show “Survivor”. Where you form alliances, and blame others until eventually, everyone gets eliminated. In the end, nobody was a survivor. There were no winners.
It was a bad situation, but like any bad situation, there were several lessons to learn from it. Maybe you could learn something from it too. Hopefully you cannot relate to any of these symptoms:
- If people are blaming the contractors, it is probably not the fault of the contractors. Your most likely suspects are the ones pointing fingers. Contractors are always easy targets, which is one reason why they get brought-in for large projects.
- If there are lots of contractors on a project, keep watch for lesson 1 (usually from PM and/or his boss). Scrutinize the paperwork early-on and ask how it works and what to do if it doesn’t work. Ask how to tell if it isn’t working. An honest PM will be glad to show you the ropes, because he has nothing to hide. A dishonest one will tell you he has got it covered.
- Ask what is meant by “done”, it should take all of 60 seconds to produce a document with a checklist that itemizes the steps and details that go into “done”. (because it was written weeks or months ago and people are watching it closely)
- You are not going to find success in a book. A book is merely a guide. You still need to employ other successful techniques, such as: start with the end in mind and be ready to change your process to make it fit. Resistance to adaptation is usually an indicator that people don’t really understand any of it. In which case, it probably won’t work very well (if at all).
- If people can’t give you straight answers you should pull them aside and ask them what is really going on.
- If the boss or the boss’s boss (etc.) isn’t aware of all of the problems, that should be a red flag. A problem that doesn’t exist (according to the boss) is something that can’t be fixed.
- There is no substitute for experience. No, wait. Sorry, the substitute for experience is learning from your own mistakes. That type of experience is hard-earned. Then again, you might make your own mistakes and not learn from them. Bon chance.
My point of all of this is not to fling dung at those people. They probably thought they were doing the right thing. My point is to inform/warn you, that if you ever see these symptoms, be aware of the expected outcome. There is lots of good advice out there for handling a bad situation. Also, sometimes it is nice to have a horrible anti-pattern (like this one) documented, so you could show it to somebody who CAN do something about it.
Good luck. I hope you never need to refer back to this article. Ever.