Most of the non-technical precursors of technical debt that afflict in-house work also afflict outsourced work. For example, the planning fallacy affects internal planners, but it also afflicts the bidders for contracts offered by the enterprise in the context of outsourcing. As described in “Unrealistic optimism: the planning fallacy and the n-person prisoner’s dilemma,” Boehm, et al., [Boehm 2016] call this the “Conspiracy of Optimism.” But outsourcing engineering work can introduce pathways for incurring technical debt that are specific to outsourcing.
The risks of incurring technical debt associated with outsourcing are inherently elevated, even setting aside those factors that also afflict in-house activity. When most enterprises contract for development of systems or software, the criteria for acceptance rarely include specifications for maintainability or extensibility. This happens, in part, because such qualitative specifications are so difficult to define quantitatively. That’s why the condition of deliverables relative to maintainability and extensibility is so variable. Outsourced deliverables can best be described as bearing an unknown level of technical debt.
The root cause of the problem is likely a lack of a universally accepted metrics for quantifying technical debt [Li 2015]. That’s why it’s difficult to specify in the vendor contract an acceptability threshold for technical debt. And since the consequences of the presence of technical debt in deliverables potentially do not become clear during the lifetime of the contract under which the debt was incurred, years may pass before the issue becomes evident, which complicates the task of understanding the root cause of the problem.
In what follows, I use the term vendor to denote the organization to which work has been outsourced, and the term enterprise to denote the organization that has outsourced a portion of its engineering work. The retained organization is the portion of the enterprise directly relevant to the outsourced work, but which was not itself outsourced. Among the mechanisms that lead to incurring technical debt in the outsourcing context are the six mechanisms sketched below. Gauging the size of these effects by auditing deliverables or by auditing the internal processes of the vendor could be helpful in managing levels of technical debt arising from outsourcing.
This list isn’t intended to be exhaustive. Quite possibly other phenomena also contribute to technical debt formation in the context of outsourcing.
Progressive erosion of retained organization capabilities
Over time, the enterprise can expect erosion of the engineering expertise needed to manage, evaluate, understand, or, if need be, to re-insource (or backsource) the work that has been outsourced [Willcocks 2004][Beardsell 2010]. Typically, staff who formerly performed the outsourced work do move on to other work, voluntarily or not, either within the enterprise or elsewhere. Indeed, cost savings from terminations and employee buyouts often accompany — and economically justify — outsourcing decisions. But even if the enterprise continues to employ the people who formerly performed the work that is now outsourced, those employees, filling new roles, can become less familiar with the current work and therefore less able to perform it. And since they are now engaged in other assignments, their availability is limited. In the public sector, the organizations that perform the outsourced work exacerbate this phenomenon by recruiting from the agencies they serve [Kusnet 2007]. In manufacturing, Kinkel et al. suggest that, paraphrasing, outsourcing disturbs the formation of internal competence [Kinkel 2016].
In short, outsourcing engineering efforts can erode the ability of the enterprise to perform internally the work that is outsourced, or to monitor or evaluate it when performed by the vendor. Consequently, the enterprise is less able to monitor, evaluate, or retire any technical debt that accumulates in the outsourced work products. A policy that would address this risk is one that would (a) require retained organizational capability sufficient to assess the effect on technical debt of any outsourced engineering work; (b) require attention to technical debt issues in any financial models used in making the initial outsourcing decision; (c) require financial models to include the effects of technical debt and controlling technical debt when deciding whether to extend outsourcing contracts with vendors.
Stovepiping among vendors
Most multi-vendor efforts use a separation-of-concerns approach [Laplante 2007] to dividing the work. That is, each vendor is empowered to use any approach it can, consistent with its own contract and statement of work. In some cases, two or more vendors might have overlapping needs that cause them each to produce similar capabilities as elements of their respective deliverables. Sharing of their results is of course possible, but unless both of their contracts anticipate the need for sharing, sharing is unlikely. Failure to share those results that could have been shared can lead to incurring unrecognized technical debt.
Stovepiping within vendors
With regard to the efforts of a single outsource vendor, it’s possible that different teams or individuals working for that vendor might unwittingly create elements with overlapping capabilities. That duplication could lead to technical debt, or it could constitute technical debt in itself. For example, two teams working for the same vendor might have similar testing needs, and might develop testing tools independently. As a second example, in a version of stovepiping combined with temporal displacement, suppose that one team is unaware that a previous effort for the same customer had already developed a capability that it now needs. That team then might re-create that already-existing capability.
Stovepiping within vendors is less likely when the vendor operates under a single vendor technical lead, and the enterprise interacts with that single lead through a single in-house technical lead. When either side of the relationship is managed through multiple contacts, stovepiping is more likely, and new technical debt is more likely to form.
Loss of continuity in the outsourced engineering staff
Unless specified in the agreement between the vendor and the enterprise, staff turnover or reassignment within the vendor organization, between one version of the product or service and the next, can lead to technical debt in just the same way that turnover in-house can lead to technical debt. With outsourcing, however, the vendor has little internalized motivation to control this phenomenon, and the enterprise likely has less control—and less awareness—of staff assignments within the vendor organization than it does within the enterprise. Thus, loss of continuity in the outsourced engineering staff is both more likely and more likely to lead to technical debt.
Reduced coordination of engineering approaches and business objectives
Lack of coordination between engineering approaches and business planning can cause engineers to create and deploy artifacts that must be revisited later, when they learn of business plans that were unknown to the engineers at the time they produced those artifacts. See “Failure to communicate long-term business strategy.” This scenario is more likely, and possibly irresolvable, when the enterprise withholds its long-term plans from the outsourcing vendor to protect its strategy.
Hiring and retention problems
In some instances, commonly called startup outsourcing or greenfield outsourcing, the work being outsourced has never been performed within the enterprise [Delen 2007]. In these cases, typically, the enterprise must then reassign existing employees or hire new employees to interface with the outsource vendor. These roles are analogous to remote supervisors, except that the teams they supervise are not employees of the enterprise. Hiring and retaining people for these roles can be difficult, because of startup challenges both within the enterprise and within the vendor organization. Recruitment and especially retention problems in these roles can decrease the likelihood of controlling technical debt, and increase the likelihood of incurring technical debt.
References
[Beardsell 2010] Julie Beardsell. “IT Backsourcing: is it the solution to innovation?”, SMC Working Paper Series, Issue: 02/2010, Swiss Management Center University, 2010.
Available: here; Retrieved: February 15, 2018
[Boehm 2016] Barry Boehm, Celia Chen, Kamonphop Srisopha, Reem Alfayez, and Lin Shiy. “Avoiding Non-Technical Sources of Software Maintenance Technical Debt,” USC Course notes, Fall 2016.
Available: here; Retrieved: July 25, 2017
- Separating responsibility for maintenance and acquisition
- Unrealistic optimism: the planning fallacy and the n-person prisoner’s dilemma
- How outsourcing leads to increasing technical debt
[Delen 2007] Guus Delen. “Decision and Control Factors for IT-sourcing,” in Handbook of Network and System Administration, Jan Bergstra and Mark Burgess, eds., Boston: Elsevier, 929-946, 2007.
[Kinkel 2016] Steffen Kinkel, Angela Jäger, Djerdj Horvath, and Bernhard Rieder. “The effects of in-house manufacturing and outsourcing on companies’ profits and productivity,” 23rd International Annual EurOMA Conference, At Trondheim, Volume: 23, June 2016.
[Kusnet 2007] David Kusnet. “Highway Robbery II,” report of the National Association of State Highway and Transportation Unions (NASHTU).
[Laplante 2007] Phillip A. Laplante. What Every Engineer Should Know About Software Engineering. New York: CRC Press, 2007.
[Li 2015] Zengyang Li, Paris Avgeriou, and Peng Liang. “A systematic mapping study on technical debt and its management,” Journal of Systems and Software 101, 193-220, 2015.
[Willcocks 2004] L. Willcocks, J. Hindle, D. Feeny, and M. Lacity. “IT and Business Process Outsourcing: The Knowledge Potential,” Information Systems Management 21:3, 7-15, 2004.
Other posts in this thread
- Non-technical precursors of non-strategic technical debt
- Failure to communicate long-term business strategy
- Failure to communicate the technical debt concept
- Technological communication risk
- Team composition volatility
- The Dunning-Kruger effect can lead to technical debt
- Self-sustaining technical knowledge deficits during contract negotiations
- How performance management systems can contribute to technical debt
- Zero tolerance and work-to-rule deliveries create an adversarial culture
- Stovepiping can lead to technical debt
- Unrealistic definition of done
- Separating responsibility for maintenance and acquisition
- The fundamental attribution error
- Feature bias: unbalanced concern for capability vs. sustainability
- Unrealistic optimism: the planning fallacy and the n-person prisoner’s dilemma
- Confirmation bias and technical debt
- How budget depletion leads to technical debt
- Contract restrictions can lead to technical debt
- Organizational psychopathy: career advancement by surfing the debt tsunami
- The Tragedy of the Commons is a distraction
- The Broken Windows theory of technical debt is broken
- Malfeasance can be a source of technical debt
