6 Ways To Beat Any Project Planning
24. Feb, 2009 
0 Comments
Edit: Just to make sure… this is not “real” advice. This is just a sarcastic post about behavioral patterns and it should illustrate for example why you must be clear on goals and tasks. It should make you more aware, so you can spot these patterns.
[SARCASM]
Project Managers and Middle Managers have the tendency to just sit in front of their computer and make up Great Plannings. Gantt Charts you have to print on wallpaper, tell you, the helpless developer, the lonely user and 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 either discuss with the manager to make the planning more realistic, or you 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.
The task that is assigned to you, can probably be not be done within the time frame the planner indicates. To avoid problems, you have to make sure that the manager can put your task on his paper on 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 explicit your task is defined, 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 afterward: “Oh? should I have done that also? You didn’t tell me that!” But with any luck, at the time that this discussion takes place, it is useless to redo the task anyway.
2. Increase Dependencies For Input
Make sure that your task can only start 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 some one 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. “I will do this, but only under the following conditions…” If you make the document of assumptions, conditions and disclaimers large enough no one will read it properly, and leave room for you 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 make commitment about their plannings, the tasks on it and the dates they have attached to them. So, if they can tell everyone that they can keep that commitment, all is swell. Nothing has been said about new tasks. If you have only done half your task, just put the original task on 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 more the documents over the process, 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 more 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 Anywayz
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?
[/SARCASM]
excellent experience & good reporting & auditing
Bas, liking the new layout, and I LOVE this post. You may be joking, but these are all good survival strategies when projects get really tough.
Shh
THat's suposed to be a professional secret!
A great list. Personally I'm surprised how often these techniques actually work.
By the way: now you should come up with 6 techniques to deal with 6 ways of beating project planning.
Thanks guys and girl
“6 techniques to deal with 6 ways of beating project planning”
now THAT s an interesting idea!
Great list, im amazed how good you described my job! And to know that im really good on all of them makes me feel nice… By the way… im looking for a new project to work on, any ideas??
Nice post!
Bas,
I don't know where you work, but in any of the firms our company work with our project management teams or we advise as the Program Management architects the above behaviours would get you fired on the first day.
Hi Glen, you are quite right. This is not meant as “advice”.. this is just a sarcastic post about behavioral patterns i have witnessed and it should illustrate why you must be clear on goals and tasks, it should make people more aware.
This surely isn't any “advice”… I'll put a disclaimer on top of the post … I thought that it would be clear.. apparently not.
That was a Cool Post!! Too Good man..Keep it up..)
Great post!! Such words of wisdom…