This is LoserMentality applied to SoftwareManagement. Please consider that I don't mean to imply that ManagersAreMonsters, only to characterize what ManagementIdeas are likely to make a project fail.

The following rules are just a recollection of what I've seen. Feel free to add your own. Make sure it is the bosses' view, not the developers' view.

Also notice that although the project may fail, the IncompetentManager may succeed.

1. IrresponsibleResponsibles: Assign responsibilities to subordinates so that they can be fired when a goal is not achieved. This is not necessarily an AntiPattern, unless the manager knows for sure that the assignee won't make it. See AnAcceptableWayOfFailing, MakeOthersLookIncompetent.

2. MandatoryUnpaidOvertime: Force team members to work 20 to 80 unpaid overtime hours per week in order to demonstrate to upper management that the manager has "authority" and that team members are doing all that is possible despite the fact that there are no concrete results.

3. AtLeastTwice: Repeat all the information in the documentation several times. CopyAndPaste everywhere.

3a. CoverYourAssets mixed with AtLeastTwice: Repeat all requirements in the documentation several times, BUT emphasis different objective in each instance. E.g. The project goal is repeated three times in different places, emphasize each of cheap, good, fast, respectively in the three instances. No matter what criticism is raised against the project, you now have prior documentation proving you have considered such cases; it's just that the team failed to follow your orders. Less extreme versions can be seen all the time with "management directives" that contradict one another.

4. AnAcceptableWayOfFailing: A good excuse is all that is needed. Your goal is only to stay on your job because managers know they have good jobs, and that it would be too hard to get a better job. Since the manager makes the strategic decisions, they may make the project FailOnPurpose, while at the same time look surprised, and if a developer wants to ring an alarm, ShootTheMessenger. See MakeOthersBecomeIncompetent.

5. RatRace: The ones who try to impress with good ideas and try to lead projects (see InformalLeaders) or specific parts of a project are ignored until their bosses consider them incompetent. This is part of MakeOthersLookIncompetent.

6. HireOnlyBeginners: Negotiate even the last cent with every potential employee. Hire only the rookies who can't negotiate. This is part of HardNegotiator and MakeOthersBecomeIncompetent.

7. BigProject: If the project finishes early, it will be considered easy. If it finishes late, it will be considered hard. Nobody wants to work in an easy project. Therefore it is better to finish late, but not so late as having a RiskOfCancellation.

8. BigEstimates: All developer estimates are big because they are slackers. Managers always cut time in half just because of that, or simply they set impossible goals without asking for estimates. This is part of MakeOthersBecomeIncompetent. Also to succeed you need to LieToYourManager, and your manager knows that. Actually he expects that, and you would be surprised how angry he can get if he does not achieve that goal.

9. DoNotLetOneHandKnowWhatTheOtherDoes: Originally said by Jesus''''''Christ, it was interpreted to mean DoNotLetEmployeesKnowWhatOtherEmployeesDo. This is part of PutSubordinatesAgainstEachOther.

10. HideYourWork: Hide your pending tasks, hide what you have finished and hide all the decisions made, so that nobody can criticize you, copy or undo what you have done. This is the opposite of RapidFeedback and OpenCommunication.

11. MilkCup: Tell upper managers that all subordinates are equally capable. This doesn't give them enough information for them to make informed decisions. This is part of MakeYourselfNecessary, although it doesn't really hurt the company or the project. Or does it?

12. FearCulture: Fire somebody from time to time so that subordinates realize you are in control. FearCulture leads to BrownNosing.

13. IncentivateGossip: Do not say negative things about people, especially about your boss, but motivate others to publicly speak negatively about their own bosses. This is part of ManageByGossip.

14. ChargeExpensively: So that clients can't BadMouth you, even if the product sucks. Besides, now you have money to fix it in the next version.

15. VerifyEverythingAtTheEnd: Do not verify any intermediate product because you declare that verifying intermediate products is a waste of time. The opposite of TestDrivenDevelopment and RapidFeedback. And of course, the possibility that the verification may fail is not planned for, to show that you have full confidence in your team.

16. ShortenSchedulesOvernight: The project seems to be producing output as planned. Try to see if we can work harder if we ShortenSchedulesOvernight. This means that you don't have time to make sure everything works fine before you release your work products. Similar to VerifyEverythingAtTheEnd. See MakeOthersBecomeIncompetent.