1. Maintain a written glossary of domain terminology. It’s amazing how often the developers and the customers think they’re talking the same language, but they’re not. Misunderstandings like this are a common source of “assumption errors,” which are a leading cause of wasted effort.

2. Maintain a written “Scope In/Out” sheet. Be explicit about what’s in scope for this project (for this phase of the project) and what’s out of scope.  Jealously guard the scope.  Do it in writing.

3. Make sure everybody who generates and consumes time estimate numbers looks at them the same way. Don’t let an optimistic estimate be taken for realistic or pessimistic one. Beware of using +/- ranges. They are meaningless when talking about software development. Much better is to use degrees of resolution (No confidence/WAG -> Low confidence -> Med confidence -> High confidence). Do a work-breakdown analysis on any large task, recursively, until it is the sum of 2-day or smaller chunks. Any estimate that’s longer than 2-days without a breakdown to back it up cannot be trusted.

4. Create written Use-Cases/Scenarios to communicate user-interaction requirements — especially when it comes to describing exceptions to the rule (things like handling the sale of alcohol or tobacco, processing returned merchandise that’s saleable vs. damaged, the difference between 50% off vs. buy-one-get-one-free, etc.). The Use Case is an amazingly powerful tool for eliciting requirements from a non-technical customer. To start, you have to write the scenarios yourself and get the customers to sign-off, but once they see where you’re going with them, they’ll start writing their own in the first place.

5. Hold daily scrums (stand-up meetings). Each team member should cover three things: (1) What they did since the previous stand-up meeting, (2) What they plan to do before the next stand-up meeting, (3) Any perceived impediments to getting it done.