Agile Zone is brought to you in partnership with:

I'm a software developer working as a senior consultant at Kentor in Stockholm, Sweden. My core competence is as a technical specialist within development and system architecture. In my heart I am, and probably will remain, a programmer. I still think programming is tremendously fun, more than 20 years after I first tried it. That's why my blog is named Passion for Coding.  Anders is a DZone MVB and is not an employee of DZone and has posted 83 posts at DZone. You can read more from them at their website. View Full User Profile

The Project Counter-Sabotage Handbook

01.21.2013
| 1947 views |
  • submit to reddit

A project saboteur is a person doing his/her best to sink a project and cause it to fail through a variety of methods. Effective counter sabotage to identify and deal with project saboteurs as early as possible is a key success factor to any large project because there will always be a saboteur somewhere…

Know Your Enemy

To successfully counter any sabotage attempts you need to know your enemy. You definitely have to know what behaviour you want to counter. If you can find out the motivational factors for the sabotage it is even better. Often it is not possible to defer counter sabotage until the reasons for the sabotage is identify. In that case it is best to start acting against the destructive behaviour, watching the saboteur’s reactions to find out who he/she really is.

Counter Sabotage Methods

There are a number of basic methods for project counter sabotage. Most of them are good habits for any project, so go ahead and use them anyway. If no saboteur shows up in the project, practicing these habits has probably been good for the project anyways.

  • Documentation, Documentation and Documentation.
  • Meeting Discipline.
  • Take Conflicts when Needed.
  • Avoid Conflicts.
  • Use Humbleness Wisely.
  • Take the Saboteur Hostage in the Project.

Documentation

The number one weapon against a saboteur is documentation. Always keep notes (even if someone else is doing official meeting minutes, take your own notes of important decisions). At the project start there is no way to know who will eventually come out as a saboteur so to start with good documentation is a way to identify the saboteur(s).

Make sure to always create clear lists of action points with a responsible person for each as well as a due date. All decisions taken should result in an action point in the meeting minutes to make sure that the decision is carried out. Action points are important because they are easy to follow up. On the next meeting the AP list should be checked off as everyone reports their progress.

The first signs of a saboteur will typically be dragging behind on assigned tasks, missing not just one deadline but most of them. When the saboteur is identified, the documentation trail is invaluable to use as a proof to management.

Meeting Discipline

Make sure that meetings have a clear agenda that is distributed in advance. Make sure that proper decisions are made and noted in the meeting minutes. A saboteur will want to make any decisions unclear or kidnap the entire meeting to not talk about the important issues. A good agenda and a strong chairman will ensure that the right things are discussed and that decisions are made.

Take Conflicts when Needed

At some points there will be no choice but to take conflicts. In that case don’t hesitate: Taking the conflict as early on as possible is easiest. The longer the conflict can grow stronger in the dark, the worse will it be when it finally explodes.

Avoid Conflicts

Contrary to the last advice, some conflicts are not important. If some of the saboteur’s behaviour has no severe implications for the project, it might be better to just let go of it. Winning every single battle is not a good strategy to win a war.

Use Humbleness Wisely

When I’ve discussed the previous posts in this series with people I’ve often heard the point that humble questions help

- What happens if a user enters digits in the surname field? the saboteur asks.
- Maybe I’m stupid, but is that risk even relevant compared to other typos people might make in their names?

Let’s pause there. The reponse will make most people switch the brain back on and then be somewhat embarrassed.

- What happens if a user enters digits in the surname field? the saboteur asks.
- Maybe I’m stupid, but is that risk even relevant compared to other typos people might make in their names?
- No, probably not.
- Protecting a user from making typos in their own name would be hard, can we just skip it and trust the users?
- Yes, you’re right. Let’s move on.

In this case a humble question made the other person think and withdraw the suggestion. If this was a true project saboteur the outcome would probably have been something else.

- What happens if a user enters digits in the surname field? the saboteur asks.
- Maybe I’m stupid, but is that risk even relevant compared to other typos people might make in their names?
- We have to protect the system from any incorrect input. Digits are not part of a surname.
- Isn’t digits really a special case of typos – where other typos will be more common?
- Digits are incorrect in a surname field, we have to check against them.
- Is it a good idea to spend time on identifying digits when other typos will be undetected?
- It shouldn’t be that hard to just check for digits.
- No, it’s not hard, but it still takes time to implement.
- That should be a standard thing to check, so there should be standard code for it to be found on the Internet. You have to learn to search the Internet for existing solutions before rolling your own. I thought that was common sense, you have to improve!

That’s a worse outcome. The humble question ended up with the saboteur establishing (an of course incorrect) fact that you are not searching for existing solutions before rolling your own… This is a case where a conflict might be needed. Not that I’m suggesting that it is possible to persuade the saboteur. But make sure that other people present don’t get the saboteur’s incorrect fact established as their own truth.

Take the Saboteur Hostage in the Project

With a saboteur that is a bit less provocative and conflict minded than in the previous example it is sometimes a good strategy to get the saboteur involved in the project. If the saboteur is an insecure person that feels pushed aside by the project this might be a good strategy. Nobody likes being pushed aside and neglected and an insecure person will probably take it harder.

Power Matters

Regardless of the saboteur’s strategies and the type of saboteur there is one thing that always matters in the end: Power. If the saboteur is without power it will be an annoyance, but not a problem. It’s when the saboteur has some kind of power to put behind the sabotage methods that there is a problem. If you have power enough yourself to counter it, you might have to resort to (sometimes ugly) demonstrations of power. I think that to some extent this is mostly a problem in Sweden and other cultures where hierarchies are less strict.

If you don’t have the power yourself to handle the saboteur it is important to make sure that you have backup from your own organisation. If you engage in a conflict that you know how to win, everything can be destroyed if the saboteur gets a manager to interfere before you have made it clear to everybody what the saboteur is up to. In that case you loose. The saboteur now has established you as a trouble maker and got away with whatever sabotage was under way. (I’ve been in that situation myself, and let me tell you: it’s a very bad situation).

Counter Sabotage is Hard

These are some of my thoughts, influenced by reactions I’ve had on the previous posts in this series. If you have any other or better suggestions, please leave a comment. There are as many effective counter sabotage methods as there are saboteurs, so please share your favourite method.

This post is part of the Project Saboteurs series.
Published at DZone with permission of Anders Abel, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)