The Design and Implementation of laffer1

I started wriing this entry with a real world experience I had today.  Instead, I think I'm just take some constructive points from the situation.

1. When making a big picture roadmap with many IT projects, understand what each part is trying to accomplish.  You don't need the how for the first draft, but you do need the why.
2. Don't create three level deep diagrams of one component in the system that interoperates with other peices not even discussed yet. 
3. It's ok to talk about when you need a project complete, but don't start makin details timelines or final deadlines until the requirements are known.  You can't plan how long something will take when you don't even know what it is you're planning.  If you have a hard deadline, start with absolute necessities first.  Good software can always be enhanced.
4. Don't assume everyone is against your idea.
5. When you're asking someone to spend a great deal of money on a project, take the time to write down why you need it..  It really is the least you can do.
6. User stories are one way to obtain an initial list of requirements, but they do not replace a techical oriented view before one starts work.
7. When writing user stories, you must capture ALL of them or it is useless.  One user case left out could dramatically change the requirements for a project.  Programmers do write themselves into corners.
8. Reading one book will not make you a good project manager.  Reading this list won't either.
9. Don't trust any one website for information on software.  They can be wrong.  Some IT websites suggest products because vendors paid them or gave them an insentive. Others just have a bias.  For example, I might suggest  BSD because I prefer it to Linux.  That doesn't mean Linux isn't useful in many environments.
10. Programmers need to sleep sometimes.