Project Management - What Not to Do

I appreciate santhosh knowledge and thanks for giving such important tips.

Some more mistakes: 
1. Use of Thumbrule estimates
2. Not giving importance to Quantity Survey in Construction Projects
3. Risk Management and Contingency planning neglected
4. Project Plan considered to be a document alone and not a tool to be aligned with.
5. Not monitoring or measuring progress effectively
6. Preparing Project schedule with too many or too less number of activities.
7. Doing additional works without approved rates/ prices negotiated.
8. No legally bound contract signed while issuing sub projetcs /  packages to sub contractors.
9. Highlighting extent of progress and performance in varying magnitude among various stakeholders.
10. Not  performaing Stakeholder Analysis

its gr8.....thnx 4 sharing this..

good to see this, here are some more list which I had prepared 8 years back. Some of them may be covered earlier and some may be obselte,
1.Ignore the overall schedule submitted to the customer (This is the one send to customer initially, which he should have agreed)
2.Schedule the tasks to the resources as and when they complete the  earlier work.
3.Schedule each tasks in such a fashion that developers will be barely able to complete the tasks even if he spends 16hrs a day
4.Use the first half of  each phase of the project to R&D and decide how should we attack the problem. Participate all the resources for this brain storming sessions. Make sure every one gets confused and each of the junior employee feels, the work ahead is going to be tough.
5.This can be better mismanaged by selecting  one piece of activity. Asking all the team members to look into this piece and ask them to jointly come up  with a way or methodology to be adopted. Or alternatively, you can ask one person to do this activity and ask the rest of them to wait till he comes up with a document and then decide whether to follow this or should the cycle be repeated.
6.Bottom line, make sure actual project activity should start only after half the elapsed time is over. This should be repeated for each phase of the project.
7.Never do a periodic impact or causal analysis to find out  how the project is progressing. It is a waste of time!!
8.Any changes asked by customer should be incorporated. Incase at some point of time, customer or your delivery manager points out, you are slipping the time line, postpone some of the functionality  agreed to be delivered as part of the proposal
9.Never give a clue to the stake holders (DM, customer or the team ), when the project will be over. Even if they ask, confuse them with all the activities. Best method is if any one ask for incomplete tasks list , provide them with list of all the tasks and tell them only a part of the tasks were completed during earlier cycles
10.Never keep any record of  any reviews or testing carried out
11.Invest good amount of time in preparing design document, but never update these document for any changes occurred later. 
12.During coding of each unit, do not code important sections of the functionality, so that it can be incorporated at the end of Unit testing, just before Integration testing. Some of the common routines to be done for all the units should belong to this set. Do not even provide any provision to plug in it later. It has to be incorporated only by modifying each and every units of code.

very interesting list...a few more...

- Do not take the changes through Integrated Change Control Board
- Never baseline your documents of approved changes
- Never communicate the true status of the project
- Never do periodic progress reviews
- Do not take sign-off from customer on deliverables

if you think of it, the list keeps increasing...

Good to see something different ( what not to do) I wanna add few more to it...
Forget about budget
Don't communicate with your virtual teams
Never work in team...