Six ways to avoid work on software projects

This article is sarcastic. You can use this knowledge to your own advantage, good or bad.

Project Managers and Middle Managers have the tendency to just sit in front of their computers and make up Great Plans. Gantt charts you have to print on wallpaper tell you -- the helpless developer, the lonely user and any other poor souls that make up the working class -- when you should do a certain task.

Most of the time the planning doesn't resemble anything that looks like reality. You have two options: you can either discuss with your manager how to make the planning more realistic, or you can just comply. If you go for Door Number One, I wish you good luck and all the strength in the world; you will need it. If you are going along with it, just pay attention to the following six rules on how to beat any planning.

Most of the time the planning doesn't resemble anything that looks like reality.

For the task that is assigned to you, can probably avoid finishing within the time frame the planner indicates. To dodge problems, make sure that the manager can put your task on his paper with the status "completed." In essence, that is all he wants. He will be judged upon his planning, not on reality. And this fact is just the loophole you are looking for.

1. Fuzziness is your friend
   The less clearly defined your task is, the better it is for you. Terms like "testing" and "developing" give you the opportunity to yell "done" whenever you feel like it. You might have some small discussions afterwards: "Oh, should I have done that also? You didn't tell me that!" With any luck, by the time this discussion takes place it will be useless to redo the task anyway.



2. Increase dependencies for input
   Make sure that your task can start only when other people are ready with their own tasks. The more of these dependencies you have, the better. With every dependency on someone else you create the opportunity to blame someone else. If you play this card well, management will reduce the amount of dependencies (it is a proper management technique) and you will end up with a very small, reduced task, which will take care of itself.



3. Elastic scope
   
   This is a more advanced variant of "Fuzziness Is Your Friend." Here you will define the scope of your tasks, but with as many assumptions and disclaimers as you can come up with. This is your mantra: "I will do this, but only under the following conditions…" Make a document of assumptions, conditions and disclaimers large enough so no one will read it properly, and leave room to create the scope just right for you.



4. Adding more tasks
   Most people are astounded that this one actually works. Believe me, it does. Most managers are very committed to their plans, the tasks on them and the dates they have attached to them. So, if they can tell everyone that they can keep that commitment, all is well. Nothing has been said about new tasks. If you have only done half your task, just claim the original task is 100% completed and define a new one. Of course with a different name. "Integration Test" can be dubbed "Partial Integration Verification," if you catch my drift.



5. Write large closing reports
   If you work in a larger corporation, you know that people love documenting the process more than the actual product that the process should produce. More managers will read your evaluation report than look at the quality of the software system. Spend a lot of time on your closing documents, the reports that describe how well you did your job. Most of the time you don't even have to perform your actual task. It is all about keeping up appearances.
6. Pure bluff: Who checks anyway?
   In larger projects, or at very hectic moments, everyone is very busy with themselves. They have their own problems and have no real time to take a proper look at your task. Just bluff. Just say you are done. Who will check?