A Case Study in Classic Mistakes

Hi everyone, this is my first post here and I plan to write often here now. Thanks Roy for pulling me in as a co-author. I do write at other my weblog here and Roy does it here. Roy has written some interesting posts there. So do visit us!
Ok, this post is about the Case study put up at the yahoo group > GMPIT. I have gone through the doc file and I find that it is common place in most organizations. I have faced this myself several times and here is my learning:
1. Never project timeline without talking with the team and at least add some buffers to accommodate the unknown and based on team personalities you are dealing with. Make sure you know your team well. If not, read each members previous appraisal sheet and resume, if possible. It is not uncommon to have an over-committing guy on your list. So that should be factored in.
2. Team is the key to a successful project. Ensure that there are no personality issues amongst peers. If there are these challenges and you do realize it after the project has been initiated, change the communication strategy and let everyone talk through only you so that the gaps are minimized. It would be ideal if the team has worked before together to successfully deliver a project earlier. If there are new recruits, ensure that the peers are a part of the interview process and that there is some acceptance there. I have seen 'handpicked' teams fail just because of personality issues.
3. Never accept any requirement change or RFEs in the middle of the project unless you can analyse the impact and buy time for that. Make sure that each stakeholder is aware of the impact. If you are not heard, escalate it. Note that your neck will be on the line if you miss the delivery date.
4. Never get into appeasing others. You are digging your own grave by doing it.
5. Throughout the life cycle have a daily status meetings even if it is across geographies. This ensures that there are no gaps and everyone knows what is to be done 'tomorrow'. This may sound like hypothetical but this works. In time bound projects, specially where there is a penalty clause, it is utmost essential that everyone knows his/her daily target and the problems faced are brought to the table in time. Imagine a programmer telling you at the end of the week that since he did not getting the database design document, he worked on something else and is still waiting for it. Daily review is a must.
6. Think proactively. In addition to daily chores of co-ordination and communication, and monitoring and control, one skill that really helps is being proactive. For example, if you know that you might need a database architect at some point during the project, find one NOW. You may not hire him but may give him a heads up on when you might need him.
7. Be very careful in what you communicate. Casual statements may sound rude or even get misinterpreted across geographies.

These are the key things that come to my mind. Do read the case study - it reflects a very typical scenario in the software development firms and would be fun discussing that in the class.
Cheers!