Write tests at the known "pain points" of the application. Code that breaks often or is generally of higher risk is a good place to start, as it helps to build a front-line of defense in this area and exposes the team to the scope of the unit tests in that application.
Every time a defect is opened against the application, going forward, try to write a unit test to expose this behavior. It will let you know when it is fixed and hopefully prevent it from being introduced again in the future.
Additionally, look for code that needs to be refactored. Any refactoring effort should be prefaced by the creation of unit tests. This helps to ensure that it was working both before and after you have made your changes. Refactoring can be tough in the beginning, because of the risk of the "ripple effect", where one breakage can wreak havoc through the entire application in unexpected fashions.
