• Make sure the outsourcing contractor documents what has changed in the system (when modifying an existing system in a type of project where we just hand it to them with a spec).
• We need to be prepared to provide acceptance resources to keep things moving.
• Don't forget to have an acceptance plan, too.
• Don't forget to specify the programming language if you care about it. The project they were working on was mostly VB.Net with a little C#. We wanted all new development in C#, but didn't specify that. I'm glad they just happned to pick C# for some new modules.
• Teach the outsourcing people your standards. (Of course, you need to have some first...)
• Ideally, I'd love to have the outsourcing people integrated with our internal processes, such as source control systems, change management, bug tracking, etc.
• If they're doing UI work (either desktop or web), you better talk about graphics. Who's providing them? How will they be provided? What formats? Will they be sliced? If so, how? Etc....
• Be sure to have good test data and scenarios.
• We needed to provide some better techincal specifications. We provided a good functional specification, but could have provided better techincal specifications in areas where we cared about the technical aspects of the solution.
• If we care about performance of the solution, we better discuss that...

Of course, a lot of these things are just a part of good software development practices, anyway (but many organizations don't have a lot of good practices). If you have good practices in place, it's a lot easier to add something like outsourcing. When everything is chaos internally, guess what? that will probably migrate to working with your outsourcing partners, too.

It's important to have a good relationship with your outsourcing partner. Don't be trying to nickel-and-dime things. We had many places where we could have done better, but, thank goodness, we had a good relationship and things went well.