Ivar Jacobson is a father of components and component architecture, use cases, aspect-oriented software development, modern business engineering, the Unified Modeling Language and the Rational Unified Process. He can be contacted at www.ivarjacobson.com
Let's be realistic. In a column like this I can only give you a hint of what you as a buyer need to do when it comes to outsourcing software development projects. However, it is amazing how many outsourcing agreements would benefit from the basic advice I present here. But note that "basic" means that there may be exceptions.
Split the work into smaller, separately defined pieces that potentially can be given to different vendors.
Separate work that is exploratory in nature from work that is mere production. Production can be calculated at a fixed price, whereas exploratory work can't reasonably be calculated in advance. For instance, don't ask for a fixed price until you know the key requirements (say 60-80 percent of all requirements), and until you know how you want it to be built (you must have an architecture that is implementable).
It is beyond human ability to specify all requirements for software upfront. Don't accept a contractual model where all requirements have to be specified and agreed upon early. Even worse is to agree on requirements upfront and then pay an unspecified amount for each change. This is nothing less than horse dealer contracts.
Outsourcing software development without an architecture is like asking someone to build a house without an architecture. You would never do that. However, for software, drawings are not enough. You need to make sure that the architecture can be realized. All important risks (performance, etc.) must have been eliminated. That requires you need some executable code - usually 5-10 percent of the final code must be in place before someone can calculate a fixed price.
As for a house, you need to inspect at certain points to make sure that the work is on track. Inspection in our case must include executable code to be meaningful.
Now, this is not easy to do. Still, this is just the basics. For large outsourcing projects such as building an enterprise wide SOA system, the required competencies are much higher.
You need to be able to split the work among several subcontractors. Thus, you need to set a building standard. Otherwise different vendors will deliver non-compatible software. It is not enough to specify what platform to use, but you need to specify how to make drawings (UML for example), what design practices to use (use cases for example), when inspection needs to happen and more.
The general advice is to split the work in smaller manageable pieces with fast deliveries. Think big, but buy small! Western companies outsourced big M$ projects to India. Japanese companies are not giving up control that easily. Their outsourcing contracts to China are in the order of $100k. Many western companies are now taking back (insourcing) their software to maintain and develop it at home. The new strategy is to insource the business critical applications, but outsource less critical software. Reflecting on this, it seems we are going back to where we were before the outsourcing frenzy started.
Again, if you don't have this competence or you cannot get it, don't even bother to outsource your software development. And, competency is not enough. You need to be smart!