I previously created a manual for aspiring "Project Breaker" developers (see The "Project Breaker" Handbook ), and according to some unscrupulous learners, these tricks have been tried and tested. But it also became a nightmare for project managers. Therefore, to see through the conspiracy of these saboteurs as soon as possible, and to carry out effective anti-sabotage, is the key to the project turning defeat into victory.
Here are some tips for project managers and developers who want their projects to succeed, to help you effectively counter project saboteurs. Even if there are no spoilers in the project, these tricks are worth mastering, because these are some good project development habits.
Know yourself, know your enemy, and win every battle.
To successfully deter vandals, you must have a solid understanding of them. If you can find a motive for sabotage, even better. But sometimes it's too late when you have the information to counteract it. The best way is to pretend to take action against disruptive behavior, see how members react, and then identify the real disruptor.
Documentation
The number one weapon against saboteurs is documentation. Always jot down project decisions (even if someone else is taking formal meeting minutes, keep important decisions in your own notebook). At the beginning of a project, there is no way of knowing who will be the saboteur, so it's a good habit to document it at all times at the outset.
Make sure to clearly document action points for each project step, including owners and deadlines. In the minutes, each resolution should have an action point to ensure that those resolutions are implemented. This is very important because action points are easy to follow. In the following meeting, the project members should be asked to report the latest progress and record it.
Often, the first sign of a saboteur will be procrastination on a task assigned to him. When he is seen through, documents, meeting minutes will become powerful evidence.
Clear the meeting agenda and decisions Make
sure the meeting has a clear agenda and let everyone know before the meeting. Make sure the right decisions are made at the meeting and take notes.
Spoilers often interfere with any decision or divert important issues being discussed in the meeting elsewhere. However, a clear meeting agenda and a strong facilitator will ensure an orderly meeting.
When necessary, create a little conflict
If you have no choice but to create a little conflict. In this case, don't hesitate, conflict as early as possible is easiest. Over time, the conflict could escalate, and it would be bad if it erupted in time.
Avoid conflict
This is the opposite of the previous advice. The previous one is about creating a little conflict when you have no choice. When the actions of the saboteurs do not seriously affect the project, the conflict is unnecessary.
Use modest words wisely to avoid conflict
Project saboteurs get entangled in fringe issues and waste precious project time on them. He will ask some very difficult questions or some nonsensical questions very aggressively. At this time, if you are also very aggressive, it will inevitably cause conflicts. So, try to be humble, and you might embarrass the saboteurs and stop doing this.
For example the following discussion:
Developer: It's all my fault, I didn't consider this situation, but is it more risky than user spelling mistakes?
Destroyer: Maybe... not! (sorry at the beginning)
Developers: It will be very difficult to prevent users from typing their names incorrectly, so let's just skip it and trust the users, okay?
Spoiler: Maybe you're right, let's move on.
But it does not rule out that spoilers will continue to make things difficult, such as:
Developer: It's all my fault, I didn't consider this situation, but is it more risky than user spelling mistakes?
Spoilers: We have a responsibility to prevent users from making mistakes. Numbers are not part of the last name.
Developers: Are numbers a special case, not typos and other errors?
Spoiler: But numbers really shouldn't be in last names, we have to check for them.
Developers: It's a good idea to take the time to detect numbers, but other typos are not checked?
Spoiler: shouldn't it be hard to detect numbers?
Developer: It's not difficult, but it takes time to implement.
Spoiler: There should be standard code on the web. You have to learn to search the internet for existing solutions. I think it's common sense, you have to improve!
How to deal with this situation? Conflict is about to break out. You can find a higher-level leader and let him decide. The premise is that you want to make sure that the upper-level leader thinks the same as you.
Isolate the saboteur in the project
If the saboteur is not as strong and provocative as in the above example and insecure, then it is a good strategy to leave him in the project, no one likes to be left aside, Especially the insecure.
Power is crucial.
For a saboteur to successfully sabotage a project, at least he must have some say in the project or have a backer behind it. If he doesn't, then there's absolutely no need to worry.
If the saboteur has some power and you don't have enough power to deal with it, then you want to make sure you have an organization behind you. If the saboteur asks management to intervene and label you a troublemaker before you point out the saboteur, that's a very bad situation, and I don't know what to do.
In the end, I warn everyone that if someone wants to sabotage the project, he will do everything possible. In addition to the above countermeasures, you can also "see the tricks and dismantle them". What do you have a good suggestion for this?