The Project Saboteur’s Handbook

The Project Saboteur’s Handbook

Written by: Anders Abel

Source: http://coding.abel.nu/2013/01/the-project-saboteurs-handbook/#more-2221

 

There are many ways to sabotage a project. Recognizing them is the first crucial step to counter them. In this brief handbook I will present a number of ways of sabotage that I have encountered in various projects. This post is the saboteur’s handbook. The countermeasures will be saved for another post.

Enough of introduction. It’s time to enter the dark mind of a project saboteur…

The Project Saboteur’s Handbook

The key success factor to sabotage a project is to draw attention and drain energy from those areas that are important to make the project successful. Any behaviour that draws the attention away from important work or drains energy from the project is allowed. Use your imagination and creativity to make sure that you never miss an opportunity drag the project one step closer to failure.

Strategy Overview

To give some inspiration on how to make a project fail I’ll present some strategies in this handbook.

1. Focus on border issues to prove your own “knowledge”.
2. Ask questions that you don’t understand the answer to. Keep ask for clarification.
3. Avoid documentation.
4. Avoid clear decisions.
5. Ignore tasks assigned to you. Extra efficient if combined with the two points above.
6. Focus on other’s few shortcomings.
7. Keep meetings unfocused and avoid agendas.

 

Focus on border issues

In a project there are a few key success factors that will have the highest priority. Next in priority are important issues followed by the vast majority of relevant issues. Most projects will not have time to handle all relevant issues.

The saboteur should focus on the next level: The tiny border that is the edge cases that are ignored, but cannot be easily dismissed as relevant. Some examples of questions to ask:

• Can you prove that there are no compatibility issues with patch KB12345 that was just released by the OS vendor? (Wading through release notes for OS patches takes massive time. Presenting proofs take even more time.)
• What happens if a user enters digits in the surname field?
• What changes will be required for the next version of Internet Explorer/Windows/whatever? (Pick anything that is still just a release candidate with limited information available)

These kind of questions are particularly efficient as they serve two purposes at once. They require attention and energy from the technical experts in the project as they cannot be easily dismissed without a proper reply. They also prove for management that the saboteur must have genuine technical knowledge to be able to ask questions that the technical experts can’t answer. The things is that no true deep technical knowledge is required to ask the questions. It only looks like that.

Ask questions that you don’t understand the answer to

Asking a question that indeed has an answer, but that you lack the required knowledge to understand the answer to will make sure that anyone is unbalanced. Ask how it comes that a HTTPS session is secure against eavesdropping when the algorithm is well known. The explanation of how the crypto algorithms works mathematically is complex. As soon as the maths behind the algorithms is mentioned, ask for a simple non-mathematical explanation. If you have anyone in the project that even knows the maths to explain the algorithms this will drive them crazy – simplifying them without loosing the point is terribly hard.

Avoid documentation

Documentation is your number one threat against sabotage. Try to keep documentation to a minimum. Official meeting notes that prove exactly what was said months ago kills a lot of creativity. Without documentation it is always possible to bend the truth to put blame on someone else. The easiest way to prevent good documentation from being produced is to offer to take meeting minutes and then simply ignore the task (see ignored task below). If you offered to send out minutes nobody else will bother to take detailed notes so there will be no written record.

Avoid clear decisions

Clear decisions are similarly bad for the saboteur as documentation. It’s much better to get vague discussions where nobody really can tell exactly what was decided and what should be done. Without clear decisions for the productivity of the technical staff on the project will quickly drop. Without clear decisions there’s also much more room for creatively destroying the project.

Ignore tasks assigned to you

Anyone that’s part of the project will get tasks assigned. The best a saboteur can do is to ignore all tasks. Don’t just ignore doing them. Also ignore any questions about them. Deny any knowledge of the task existing at all. If there is no documentation on the task being assigned to you there is a big chance that you will get away with it. Be as convincing as you can that you’ve never heard of the task. That will make everyone but the strongest leaders doubt that they are correct in that you had the task assigned to you.

Focus on other’s few shortcomings

There will be times when somebody finds out that you are hardly doing anything productive and tries to nail you for it. The best defence is to focus on that person’s shortcomings. Ignore the blatantly obvious signs that you are not doing your job and focus on any small issues in that person’s job. There will always be something. The less issues there are, the more ambitious person and the more painful it will be for that person to have the issues pointed out. Focus will quickly move away from your own failures when your opponents start defending themselves.

Meetings without agenda or structure

The key to productive meetings is structured discussions following an agenda. Do your best to avoid agendas. If the discussion is coming close to an end on a topic it is usually a sign that a decision is about to be made. In that case, you should quickly move discussion away from the issue to avoid a clear decision. With the right skills the same issues can be discussed again and again ad numerous meetings, without ever making any decisions or coming to any conclusion. It will be a perfect black hole for valuable project time.

Drain energy

Remember that the key success factor to successfully sabotage a project is to draw attention and drain energy from those areas that are important to make the project successful. Any way that works can be utilized. You only have to find one way to drain the energy. Those running the project need to prevent all possible wastes of energy. It’s a battle that’s very hard for them to win.