Myths of Outsourcing: Laws of Determinism

Determinism is the belief that a state or action implies an outcome. The universe exists because humans exist; without humans, no universe. Another example is that earth is flat because you can not see it curve. There are numerous outsourcing myths that build on this thought process. I am a disciplined organization; therefore, my quality, productivity and/or time-to-market is above average. But, do beliefs imply an outcome?

Myth: “Processes imply efficiency.” This is one of the most firmly held beliefs in the software engineer world. CMMI Level 5 organizations are efficient because they are CMMI Level 5. However, processes are only a single step, a framework into which other attributes must be mapped to create an outcome. Other attributes act as enablers for processes. Training and motivation are examples. Selection of a sourcing agreement solely based on simple determinism ignores the complexity of the real world. A simple assessment of Level 5 does not assure that organization produces functionality faster, better and/or cheaper. Let’s set the record straight: there is no direct relationship between process discipline and efficiency. The linkage is between the good processes, process discipline and efficiency. The linkage is between good processes and efficiency, between using discipline to replicate random movements and replace it with concerted action.

Myth: “High process discipline yields higher quality.” As with efficiency, process does not intrinsically yield higher quality. Software engineering is a set of processes driven by people and the inputs into the process. Sourcing scenarios include not only your source, but your own staff and the processes you have in place to interact with the sourcer. People’s interaction with process requires ability both in terms of how to use the process and knowledge of the domain and tools. Failure in any of these categories will defuse the capability of any process. Audits or assessments of process capability are good tools to establish a starting point or to measure change, but they are single-point-in-time measures. Constant vigilance is required to guarantee that capability and ability are matched. There are innumerable stories of organizations that have been assessed in the past and have slipped back due to changes in management or personnel after the assessment.

Myth: “Outsourcers that advertise providing higher quality software also provide functionality faster.” Functional quality is often a contra-indication to time-to-market (data indicates that typically the higher the required quality the longer it takes to build). The relationship between speed (time-to-market) and quality can be expressed:

The graph is derived from a sample of a project with similar sizes (900 – 1000 FP) for organizations with similar process disciplines (CMM Level 3). The goal must be to decide on the needed level of quality based on organizational culture and timing needs.

Maintenance and support of high-quality software applications are a separate discussion. Here the data suggests a very strong relationship between quality and reduced support costs. If your outsourcer will be supporting the application on a fixed contract, it would behoove them to have the highest quality feasible to improve their margin. If you pay for support on a time and materials basis, I commend the follow comment I heard during a recent process assessment: “Why would I want to improve the quality? I get paid to fix the bugs.”

Myth: “I am reviewing sourcing options. One organization can prove they are efficient, and if they are efficient they must be effective.” Efficiency and effectiveness are sometimes thought of as synonymous (or at least related) terms. Efficiency is typically the result of repeatable processes and there is a presumption that given a process, effectiveness will spring into being, Measuring effectiveness typically relies upon the perceptions of the end user. When a project is delivered, gets the job done and the user feels good; it must be effective. Processes can help create an environment that is perceived as highly effective, but just as easily done badly they can create more overhead than needed. How many time have you heard, “I do not know why you doing that deliverable. I did not ask for it!.”

Myth: “I pay for results.” We have an expectation of certainty when we source projects or whole groups of work. The expectation of certainty is grounded by messages like “this project is critical, maintenance is routine and buying a COTS package is like buying a dryer” (I actually heard a senior project manager suggest that to his project team). There are many tactics to help manage variance, for example developing service level agreements or other metrics, implementing CMMI and just demanding that our outsourcers get it right (this tactic usually includes pounding on the table). These tactics are means to insulate ourselves from variance. None of these tactics negate the reality that we are “paying our outsourcers to try,” while actively pursuing risk reduction strategies. Information technology, whether in-house, outsourced or near-sourced or package-driven, is predominately a human game. The human interactions required to deliver and maintain functionality represents the intersection of multiple non-linear systems. The tactics we apply are constraints that are critical to bringing order out of chaos; however, let us not confuse order with certainly.