Today we are going to illustrate some key aspects of enablement chain analysis on a specific example: software development outsourcing, more specifically — its offshore variant. This is a particularly useful exercise as besides its utility to exploring the power of enablement chains, it will also shed some light on outsourcing-related issues; something many organizations engage in and not so many happen to benefit from. So, hopefully a win-win.
We will start in the simplest imaginable manner by capturing the most primitive picture we have in mind, which could be something as follows:
Let’s try to bring some clarity as to the business benefit. One of the key reasons organizations outsource is cost reduction. The other common one is access to a potentially larger pool of labor thus providing better scalability in terms of hiring new talent. Let’s stop there and capture what we just learned on our enablement chain:
Usually, the cost advantage organizations are looking to have is on the order of 50%-75% of domestic rate. Reality, however, can paint a much more complicated (and much less encouraging) picture where the precious numbers may actually cost us dearly, unless certain focused effort is applied in that regard. Let’s explore this a little deeper. For that we are going to focus the following question:
Does outsourcing inevitably lead to such cost reduction or are there some factors that moderate the connection?
Well, the answer is: no, not inevitably so. And a big reason for that is a whole class of phenomena that one can characterize as hidden costs of outsourcing that can be very significant and yet hard to put your finger on it. Here are some factors that must be in place to exercise the desired benefit:
• Alignment. Tasking remote team members gets you only so far. Proper alignment in terms of what, how and why to build requires sustainable and significant overlap across involved locations, which in case of offshore outsourcing is inherently difficult to attain. The actual manifestation of misalignment is actually in both building the wrong thing and building it the wrong way. Despite its superficial simplicity, it is often pretty hard to catch this problem early enough, when the cost of fixing it is still tolerable.
• Mitigated delays. Different time zones impose yet another problem: extra wait time. Often a question that could be answered in 2 minutes—should all the participants be in the same time zone—may take the a full 24-hour cycle. This ingrains a multitude of small delays that may have a significant cumulative effect of the group’s productivity. Those delays need to be systemically addressed.
• Full devotion to a common goal. That is not always the case with offshore outsourcing. For starters, you are dealing with a different organization and, as such, it has its own priorities. What’s interesting, however, is that even if its not a different organization but an offshore subsidiary of the same company, it still manifests some behaviors that are not so well aligned with the common objective. Namely, remote offices tend to invest in showing that they are of value and that the business relationship should continue or, even better, expand in its capacity. In addition to all the non-value-added “we-need-to-look-good” activities, that naturally emerge as a result of dealing with a geographically remote entity, there are also contracts that tend to over-emphasize what’s easy to measure (scope, time, for example), often at the cost of the actual value delivered.
• Effective risk management. “Effective” means that issues transpire early and there is enough time to address them before more stuff gets layered on top of an existing problem. For multiple different reasons, including cultural impact, customer-vendor pressure and others, remote groups may end up favoring delivery of the good news over the bad one, thus delaying and amplifying the effect of impediments encountered in the development process.
• Different facets of the skill. There is a little trick to saying: “The full cost of an in-house Java developer is $100/hr but we can find a remote one for just $35/hr”. The reason it is tricky is in that it usually isn’t just knowledge and experience in Java that you are looking for. One has to take into account their exposure to organizational context, understanding of the enterprise architecture, business domain, specific technology frameworks and their local customizations, etc. When you are hiring someone new, expect a learning curve. Furthermore, offshore format may impose additional challenge: some commonly shared metaphors at the HQ may be quite foreign to people from remote locations simply as a result of fundamental differences in their countries’ economies and people’s lifestyles. Something that is a habitually established notion in countries like the US (the concept of credit score or social security, for example) may appear unfamiliar or even exotic to some locations in Eastern Europe or APAC and thus impose additional layer of complexity in communications.
As a result, we are arriving at an enablement chain of the following kind:
All of the added factors moderate the connection between outsourcing and the desired outcomes we envision to attain from it. One may think of them as of “valves” on the pipeline. But I wouldn’t recommend going too far with that analogy.
Our next question will be as follows: what needs to be done in order for this enablement chain to actually work as expected? In other words, are those new connections that we’ve added going to just work no matter what or do they need enablement of their own? Well, clearly there are things that are vital for the chain to actually work, such as:
• Regular travel
• Extensive remote communication
• Growing skills locally
These, in turn, need enablement of their own: on the one hand they require regular investment of time by leadership and various subject matter experts and additional funding will be needed, too.
Besides what’s been presented, there are some factors that influence the entire chain, such as:
• The chasm between those who make a decision to outsource and those who will have to face direct consequences of this decision (a negative factor, obviously)
• Lack of proper feedback mechanism that would allow to understand if the outsourcing strategy is working out or not (also a negative)
• Development leadership is quite enthusiastic and eager to make this work at all cost (a positive factor)
The first two seem to be reinforced by the traditional stage-gate mentality. Our enablement chain will look as follows:
The chain allows us to conclude a few interesting things. First and foremost, we seem to have a better understanding of what kind of enablement is needed for outsourcing to work in our case. In fact, if it does look a bit complicated, that is for a reason: we actually are dealing with a complex decision and it has been a problem that such decisions are approached through unreasonable oversimplification, omitting the bulk of critical enablement that has to be in place. Now, our thought process as based on this diagram may inform a decision to continue on or to scrap the idea. One way or another, it will be based on a far better approximation than a mere comparison of domestic vs. offshore hourly rates and the job pool sizes. We may realize, for example, that as an organization, we are not prepared to invest in regular travel, all additional communication, extensive virtual knowledge sharing, etc. Or on the opposite, that we are totally willing to accept the investment because we have reasons to believe that we can still benefit from the model.
Second, if we were to continue, we would want to know what areas of our enablement chain should we expect to have the highest impact on the outcomes. This brings us to two important elements:
A) leverage points (in blue), and…
B) problem areas (in red)
The logic behind these elements is quite simple: leverage points is where you primarily want to focus your enablement effort and problem areas are what is inhibiting good outcomes and thus should be addressed. From both of those the organization derives action items in pursuit of the desired outcomes.
As a little commentary to the article, have you noticed how quickly the complexity of the “chain” has grown from the two connected dots to a whole cobweb of factors and enablement connections between them? Please note that all the diagram does is just reflecting the relationships that are out there. In other words, every time you look at an enablement chain like this and think “Oh goodness, this is quite complex”, keep in mind that your actual decision domain is complex and all the diagram does is simply reflecting that and helping you navigate through possible choices. This prompts an important takeaway that one of the goals here is to appreciate the complexity of the environment and make a judgement based on a reasonable consideration of important enablement factors and their connections.
Lastly, unless proven differently, every diagram is a hypothesis and thus requires validation. But this, as well as some de-biasing techniques is a matter of future articles.