10 Signs You Don't Really Know Microsoft Project

PMConnection gives us 10 Signs You Don't Really Know Microsoft Project:

1. You manually create a Project Summary Task
2. You "hard code" dates
3. You don't input the teams estimated Duration on all tasks
4. Your tasks don't start with a verb
5. You assign Predecessors to Summary Tasks
6. You assign Resources to Summary Tasks
7. You never inspect the critical path tasks
8. You never search for (or eliminate) Resource Over-Allocations
9. You never Baseline your schedule
10. You never update your schedule to align with reality

Interesting, but why are these things signs that you don't know MS Project (or any other project-setup tool for that matter)?  Here is my perspective on these statements above.

1. I think this is a purely mechanical aspect.  It's a waste of effort to create an overall summary task, but I don't think it really affects calculations and the end result.
2. Hard-coded dates are a definite mistake.  At best a project plan is an educated guess of what is going to happen in the project.  Activities never take exactly the time allotted to them, and there are those surprises that throw off timing.  It's much better to status the project regularly and keep in communication with the team on what activities are active in the current time period.
3. Without estimated durations, you cannot even claim to have an educated guess as to the project time line.  However, I have used default durations to build templates and to play around with the project network.
4. Another mechanical aspect of building project networks, but having tasks that are actions is a nice way to be clear about what is involved.
5. Summary tasks are merely visual place holders for users.  They shouldn't contain predecessor/successor links or any other data that will end up confusing project calculations. 
6. As above.  Assigning "Bill" to the summary task will not show the proper loading for "Bill" over the time involved in that task.
7. Neglecting to inspect the project plan is not a good idea.  But neglecting to inspect the "critical path" is a sure way to execution problems.  This is the longest path through the network, and mistakes here will derail the project instantly.  (I prefer checking the critical chain, but it's the same result.)
8. The nice thing about Critical Chain Project Management is that it attempts to remove resource allocations resolve resource contentions in the identification of the critical chain.  And then execution of the project uses buffers to manage situations where resources become over-allocated due to the natural task variations during execution. [Corrected on 2 Feb 2012, thanks to a reader comment.]
9. The baseline helps compare what you thought would happen to what is really happening during execution.  I prefer monitoring the buffers provided by CCPM software.
10. Good execution of projects requires that you update the activities in the project with what is happening.  Otherwise, the educated guess you had at the start of the project becomes a pretty picture for your cubicle with little connection to reality.  CCPM execution of projects cannot work without regular "how much time remaining" updates on open tasks.

What about some other signs?  One of my favorites is signs that you don't know how to execute a project (holding people to the dates in the original plan, forced-multitasking, assuming local success creates overall success).