Project managers contract for skills, staff, facilities, special tools and methods, and experience not available or not available at low enough risk in the project team itself. Some contracts begin as “team agreements” wherein two companies agree to work together in a prime contractor-subcontractor role, whereas other contracts are awarded to a sole source, selected source, or competitive source.
Contracting cannot eliminate project risk; project risk can simply be made manageable by transference to a lower-risk provider. For the project manager, the primary residual risk, once the contract is in place, is performance failure on the part of the provider. The provider may run into unforeseen technical problems, experience business failures elsewhere that affect the project, or be subject to external threats such as flood, fire, or earthquake.
Both parties seek to minimize their risk when entering into a contract. The provider will be inclined to identify risks early enough so that provisions in the contract can cover the risks: more money, more time, and assistance in various forms.
The project team will be inclined to seek performance guarantees and the means to reward upside achievement or punish downside shortfalls. Each party invokes its risk management plan when approaching a contract opportunity.
The majority of IT outsourcing deals, especially those that focus solely on cost, fail to meet the initial objective.
When you’re looking at external service providers and their contracted prices, keep in mind that service providers very often lowball their bid, essentially undercharging on the front-end of a long-term contract and expecting to make up the loss in later years.
Huge cost savings in the first year can evaporate as change fees and unanticipated add-ons bring the price up; often to the point at which there are no long-term savings at all.
The message: Don’t take pricing at face value.
You have to understand your external service provider’s business model and how the provider makes a profit. You also must respect that the external service provider does indeed need to make a profit to continue in business and serve your organization.
Decision Tree Analysis
While most organizations implement strategic sourcing initiatives for the purposes of saving money, other reasons for implementing strategic sourcing include improving provider performance and minimizing risk.
Decision trees can help you form a balanced picture of the risks and rewards associated with each possible course of action throughout the insourcing versus outsourcing decision-making process, especially when flexibility is built into contract (or SLAs in the case of in-house providers).
In short, decision trees help you make the best decisions on the basis of existing information and best guesses. As with all decision making methods, decision tree analysis should be used in conjunction with common sense. (See my article on Developer.com for further discussion of this subject.)
A Little History
Systematic strategic sourcing was initiated by General Motors in the 1980s and soon became a common strategic business tool. Many companies worldwide reviewed their purchasing activities and initiated strategic sourcing programs in response to the rise of China as a global manufacturing hub after its accession to the World Trade Organization in 2001.
The Commonwealth of Pennsylvania launched one of the most successful strategic sourcing initiatives in the country in 2003. To date, the initiative has driven $180 million in annual savings, while helping the Commonwealth quadruple its minority and women business enterprise participation rate.
Linking IT and Business Value
Remember, strategic sourcing considers the long-term goals of the enterprise when capitalizing on opportunities. The goals should be measurable ones such as revenue growth, or revenue per employee, or new product development time and have dates associated with those goals. If no metrics exist for a value, get or negotiate one with your business colleagues.
Marcia Gulesian is an IT strategist, hands-on practitioner, and advocate for business-driven architectures. She has served as software developer, project manager, CTO, and CIO. Marcia is author of well more than 100 feature articles on IT, its economics and its management, many of which appear on CIO Update.