The saboteur's guide to software projects

One of the funniest reads for large orgs is the declassified "Simple Sabotage Field Manual" (1944): the CIA (then OSS) guidelines for the Resistance on underhandedly destroying productivity.

A few years back, I took a sharpie and highlighted for a friendly client which destructive ideas (especially in chapter 11) are deeply ingrained in their corporate policies and culture. 😅

Based on that, let me introduce the "Saboteur's Guide to Software Projects": a tongue-in-cheek playbook for 100% guaranteed project failure.

The list is open to contributions — feel free to share your evil suggestions below!

Failure-Seeding Planning #

The planning phase sets the foundational traps that will detonate later.

1. Always insist on making software projects as large as possible. Nothing is out of scope.
2. Point out that some agile projects also fail, and so insist on doing waterfall. Blame outside factors (procurement, budgeting, etc).
3. Insist that the software can be only launched to users when every last part is ready.
4. If someone insists on at least phases/milestones, make sure that no actual software gets released: make the milestones about "deliverables" which are documents.

Requirement-Minefield Specs #

Requirements are perfect for planting further landmines.

1. Find people who believe they know what the end user needs (project managers, bosses, etc): let them specify, so half the actual requirements don't get specified.
2. If you must have the real end users specify, then insist on detailed specifications, in writing, before any code is written. They will specify only the business functionality, and completely forget about the parts they don't see, like interfaces, user administration, monitoring, backups, etc.
3. Over-specify some things that are actually incredibly expensive to implement, like 100% uptime.
4. Use a lot of vague expressions like "immediately", "user-friendly", etc.

Division-Sowing Organization #

Project organization is your foundation for inflicting delays — primarily by increasing handovers: create as many independent-but-not-autonomous parts as possible, so none can achieve anything without coordinating with others.

1. Bring in consultants to help organize the project. Don't start anything before their recommendations are ready.
2. Establish at least two management forums with different agendas where the project will be discussed regularly. There should be as little personnel overlap between the forums as possible.
3. For other software systems that your project interfaces with, demand weekly status meetings, with as many participants as possible, for the whole duration of the project.
4. Make sure that only managers attend these status meetings and enforce a strict agenda, to avoid accidentally creating a forum where technical people can discuss technical details.
5. Do not disseminate important information in topical channels but rather only in direct messages, and only to half the people whom it might concern.

Morale-Crushing Development #

Development is hard to sabotage with a good team — so crush morale instead.

1. Even if parts of the software are ready, do not release them to real users.
2. Insist that developers come into the office all the time, and make sure the office provides as many distractions as possible, preventing deep work.
3. Insist on documentation as early as possible, possibly in advance. Discredit other, less expensive methods of information transfer as "not serious".
4. Don't do automated tests, insist that they slow down development and make refactoring harder. (Nevermind that you don't actually allow time for refactoring.)
5. Strict firewall rules! Require detailed documentation and approval for every port opening request. (Firewall openings only on Wednesdays.)

Endless-Testing Nightmare #

At this point the software is "feature complete", and stakeholders assume that it's nearly ready for go-live after a quick testing round.

1. Actually, since the software has never actually met the reality of the end users yet, it will be full of wrong assumptions, missing critical details, and big parts will end up never used.
2. Try to still delay putting the software into the hands of the end users. Other people (managers, testers, etc) who believe they know what the end user needs should do acceptance testing.
3. This phase allows for a lengthy and many-rounds manual testing and fixing death loop that can last for months.
4. This is the phase where the inadequateness of the initial specifications will come to light. Nevertheless, label every change as "bug" (not "change request") thus destroying the team's morale further.
5. Delay paying suppliers until your huge pile of "bugs" (actually change requests) are 100% completed. Their bosses will run after their money, and so make their teams implement your changes cheaper and cheaper ways, thus letting you lower overall quality to the rock bottom.

Knowledge-Destroying Ops #

In this phase, your focus should be on destroying know-how and cementing the project into an unchangeable state.

1. Make sure that the software is operated by people who were not involved earlier. If you have a dedicated OPS team who doesn't DEV, that's perfect.
2. Immediately let go of any suppliers, and spread every internal developer out to different projects.
3. Double move: Fire some key people now (thus destroying knowledge) who you can later scapegoat for the inevitable failure (thus securing your own position).
4. Leave behind immense amount of useless and misleading documentation. Your earlier documentation will help a lot here, it's guaranteed that all of them are out of date.