- 5.1 Framing the Problem
- 5.2 Activity-oriented Teams
- 5.3 Shared Services
- 5.4 Cross-functional Teams
- 5.5 Cross-functionality in Other Domains
- 5.6 Migrating to Cross-functional Teams
- 5.7 Communities of Practice
- 5.8 Maintenance Teams
- 5.9 Outsourcing
- 5.10 The Matrix: Solve It or Dissolve It
- 5.11 Summary of Insights
- 5.12 Summary of Actions
This chapter is from the book
This chapter is from the book
This chapter is from the book
5.9 Outsourcing
When IT-B work is outsourced, we need to take care that the resulting team design does not violate the conditions of responsiveness, autonomy, mastery, and purpose discussed previously. Otherwise, business outcomes may be at risk. For example, the CapEx-OpEx distinction results in separate contracts/teams/vendors for development and maintenance. Some organizations go a step further and outsource even IT operations to a different team/vendor under a separate contract. The rationale is to stick to core business competency and outsource everything else (let vendors compete with each other for our slice of IT). Depending on how critical an application is for revenue generation, this strategy of “divide-and-conquer IT” can be frustrating at best and suicidal at worst. Internet businesses and ISVs typically outsource little to none of their IT-B. This is simply because having to orchestrate between three teams/vendors for every new feature is a huge drag on the ability to go to market quickly.
Equally important, the feedback loop is badly constricted at contractual boundaries. Designing formal, service-level agreement (SLA)-driven protocols of communication between business, development, IT operations, and maintenance is a recipe for bureaucracy and indifference.
Outsourcing along outcomes is better than outsourcing along activity lines—that is, consider outsourcing application A to vendor X, B to vendor Y, and C to vendor Z (Figure 5-6) rather than handing development of A, B, and C to vendor X, IT operations to vendor Y, and maintenance to vendor Z (Figure 5-5).
)
Figure 5-5 Avoid activity-oriented outsourcing.
)
Figure 5-6 Adopt outcome-oriented outsourcing.
Outsourcing outcomes (or suboutcomes) is the first step. The next step is to ensure that the vendor follows the same practice while internally organizing for delivery of the outcome. Many vendors adopt a utilization-friendly, activity-oriented organization internally, thus defeating the intent of the outsourcing configuration.
On the other hand, it may be that your business doesn’t change that often or your application isn’t strategic. If so, it is useful to ask, “Why make (build)? Why not buy?” SaaS is mainstream. It is likely that someone is offering your bespoke application as a service. At the cost of some tweaks to your business process and a one-time migration, you might end up with a better application at lower cost. The SaaS vendor in turn is likely running a fully in-house IT-B setup.