Softpanorama Bulletin
Vol 25, No.02 (February, 2013)

Prev | Contents | Next

Inhouse vs Outsourced Applications Development

Below we will try to classify the problems that are already known and reported in the literature, but are usually swiped under the carpet in mainstream discussions of offshoring. This is just the first attempt of classification of the known problems as such it is definitely not complete. Still I hope that even in present form it might be useful. Here is the list of seven risk areas that are the most important to understand and, if possible, contain in any large scale offshoring effort:

1. A sign of internal problems: management greed and/or incompetence-related risks
2. The loss of operational flexibility
3. Systematic overestimation of savings from offshoring
4. Strategic risk of divided loyalty.
5. High attrition rate and incompetence-related risks
6. Demoralization of staff at large
7. Long term implications of offshoring

A sign of internal problems: management greed and/or incompetence-related risks

There are several additional factors that need to be mentioned:

• Excessive greed. In small companies outsourcing is often is used as the mean of survival due to severely limited resources. Outsourcing in large public companies is more often then not is driven by the greed of the corporate oligarchy and is an attempt to capture additional rents at the expense of rank-and-file workers. Corporate oligarchy recently became completely unleashed and that led to the financial crisis of 2008 (see Control Fraud).

  IT is not an exception from this epidemic of greed. Corporate oligarchy (failing at anything other than increasing bottom lines by starving research, disinvestment, and squeezing pay of IT personnel) managed enriched themselves to the detriment of companies. Conversion of IBM from a tech giant to the copy of Wipro is one telling fact (IBM to Workers Avoid Layoffs by Outsourcing Yourself). IBM has laid off more than 4,000 workers in the U.S. just in 2009. As Yuves Smith noted (naked capitalism, Aug 25, 2010):

  Let's see, average CEO pay was 49 times average worker pay in 1980. As of the most recent tabulation, 2008, it was 319 times average worker pay. And since that was the worst year of the crisis, and top level pay was therefore a tad subdued, one can expect the gap to have widened since then. Tell me: do you really think the CEOs of 2008 are more than five times better, on average, than their 1980s counterparts?

  Do you even believe that pay for performance works at the CEO level? The evidence suggests the opposite. In IT, CEO pay is inversely correlated with performance. Pay being correlated with underperformance is particularly strong with particularly well paid CEOs. From a 2009 study:

  Compensation, status, and press coverage of managers in the U.S. follow a highly skewed distribution: a small number of 'superstars' enjoy the bulk of the rewards. We evaluate the impact of CEOs achieving superstar status on the performance of their firms, using prestigious business awards to measure shocks to CEO status. We find that award-winning CEOs subsequently underperform, both relative to their prior performance and relative to a matched sample of non-winning CEOs. At the same time, they extract more compensation following the award, both in absolute amounts and relative to other top executives in their firms. They also spend more time on public and private activities outside their companies, such as assuming board seats or writing books. The incidence of earnings management increases after winning awards. The effects are strongest in firms with weak corporate governance. Our results suggest that the ex-post consequences of media-induced superstar status for shareholders are negative.

• A lack of internal project management skills to keep control over the relationship. Top quality project managers is a rare bread of managers and to get them in outsourced environment is very difficult. In a highly bureaucratized environment such people are usually non-existent. And if you project managers are really weak, the situation that is typical for many outsourced environments, the outsourcers can do whatever they wish with the company.
  
• Smell of socialism: gradual deterioration of quality and standards of service. All those fake paper reports about quality of service often does not worth the paper they are printed on because of fundamental alienation of outsourced workers from the interests of the host company. The dirt is systematically swiped under the carpet but the real situation is that the quality of service usually deteriorate to the lowest common denominator pretty quickly. Management of host company has no alternative but to close eyes on the problems because it was the initiator of the move and accepting blame discredits the management. The only bright spot in such a situation is that misery usually loves company.

  With time the problems that the company might now facing with the quality of service can directly affect the bottom line.

Amplification of the management missteps

Few, if any, offshoring firms can be objective and unbiased in making decisions, especially if they are recommended by the managers of the client company. More then anything else the position of offshoring firm turn people into sycophants. They usually never question the "revelation" of the client managers even if they are disastrous for the company. Client is always right. That can lead to huge architectural blunders that doom the project independent of the level of execution. Those things are not limited to offshoring but happened often with complex projects like ERP, especially in case big consultant firms are involved. Several large companies went out of business as a result (FoxMeyer, AT&T Wireless, etc), several were severely hurt (Hershell, etc) .

And the facts suggest that you can get bloated and plain wrong architectural solutions very easily. Bloated Java applications with expensive IBM middleware when scripting languages solution or TCL+C architecture might be a better deal are not that uncommon as outsourcers are not really interested to find the best solution for a particular project and need to take into account the interests of other clients that might be different or diametrically opposite to the real need of the company and preferable architectural solutions. Even excessive componentization can byte: as Java class library hell term aptly demonstrate. Generally componentization helps but only to a certain extent. If overused it became itself an overhead.

Too often offshoring means substituting quantity for quality. This creates additional architectural risks. As Fred Brooks noted long ago the real problem with using a lot of mediocre programmers instead of a few good ones is that no matter how long they work, they never produce something as good as what good programmers can produce.

Also offshoring operations are often operated by a greedy middlemen, not by talented managers. Even if talented manager are available, hopping backwards and forwards on short visits usually does not help; the key management (and their families) have to be relocated to lower-cost markets. And that goal is rather difficult to achieve. In a letter to Computerworld about the article Who's to Blame for Failed Offshoring Terrence Vaughn aptly noted:

In the article "Internal Resistance Can Doom Offshore Projects," Rick Pfeiffer claims that 60% of offshored projects that fail can be blamed on some (local) worker tied to the project. Sure, and as everyone knows, 76.3% of all statistics are made up.

I have a better statistic, and it's true: Top management is in charge of 100% of all IT projects that fail. First they push a hopeless IT project with no relation to the real world, and it fails. Then they fire most of the local workers and announce that they are offshoring IT projects, to the loud acclaim of industry pundits and stock analysts everywhere, while the CxOs rake in millions in stock options. Then, when the offshored IT projects also fail, they blame it on the few remaining local IT workers.

The loss of operational flexibility

This is very important, I would say fundamental problem with offshoring. When offshoring done on cost grounds alone they usually create new (still mostly unrecognized) dependencies that deprive the offshoring company from much of the operational flexibility and by requiring too much procedures and paperwork encourage Soviet-style bureaucratization (and corresponding type of bureaucrats). Typically security departments are direct beneficiary as security-related spending tend to grow dramatically as a defensive reaction of the organism. The main consequence of the bureaucratization is the loss of flexibility, and sooner or later this lack of flexibility can come back and haunt the company.

In the recent interview Bill Gates noted that "The IT systems are your brain. If you take your brain and outsource it then any adaptability you want (becomes) a contract negotiation". After you negotiated the contact any flexibility you used to have is lost as every change explicitly or implicitly become a contact negotiation. And without proper and timely adjustments there is additional risks that a process will became less stable and reliable with time. If architectural issues are decided by outsourcers, then essentially the company becomes a hostage of outsourcers as it no longer has brain power to access the options and the architecture (and thus the costs) are by-and-large controlled by forces outside your control. That is much more serious risk that many PHB assume: the line between architectural decisions and implementation decisions is pretty fuzzy. There is also associated brain-drain risk � if you outsource important CS functions, you irrevocable erode the capabilities within your firm and it is not clear for whom you are training the engineering talent at outsourcer (see below about attrition risk), the talent that after training will look for a better position in the other company. When problems arise, your own staff can often get management cooperation more quickly, with less bureaucratic overhead inherent when two corporations are involved.

The fist category of factors that lead to loss of flexibility is connected with additional standards, policies and procedures that are usually introduced due to offshoring. Such standard are often written by extremely incompetent people, or by corporate careerists who sense the opportunity for promotion in this environment. The rule is not to try to force something down developers throats and make them conform to a standard is constantly ignored. This usually costs money, sometimes a lot of money. Also the whole atmosphere starts smell socialism.

The other important aspect of the loss of flexibility (that we will discuss under a slightly different angle later) if that the offshoring company can eventually acquire the critical mass of know-how and talent pool in a particular area. In this case the host company became a client of offshoring company not vise versa. Even worse, in more then one way host company became a hostage of the outsourcer: in this case it is outsourcer who can dictate the rules of the game and who is the only party who understands the precise nature of the tasks involved and can conceal this knowledge for his own advantage from the other party. That usually is helped by the demoralization of the remaining staff in the company that outsource a particular IT function.

In a typical offshoring mythology there is no connection between IT architects, programmers and coders as it they are completely isolated and one can be outsourced while the other kept. To put it in other words (or in wider view) this myth ignores an intrinsic links between architectural issues and implementation issues).

Systematic Overestimation of Savings from Offshoring

In comparison with in-sourcing (bringing programmers, managers from other countries to the country where the project is performed or creating a subsidiary in a foreign country) IT offshoring has higher risks and a lot of hidden/unanticipated costs. It requires complex multi-level coordination and a very precise understanding of the architectural issues related to tasks. Typically unforeseen communication, travel and management costs over the project duration absorb drastically more resources than company originally anticipated. Even simple cases often contain unanticipated difficulties. Most would agree that Dell management is better then average, still they found out that even such simple task as offshoring of mundane support of regular Windows PCs created a lot of tension with enterprise customers.

There's little reason to believe these sorts of risks could prevent jobs from going offshore. Particularly during rough economic times, management often views the need to cut costs to be an absolute priority. The typical explanation is that the choice isn't offshoring or keeping jobs here; it's offshoring or going out of business. But the real questions are:

• Whether this is an absolute necessity for many companies and does it really save costs if everything is "calculated in" in comparison with preserving local IT staff.
• What are the long-term implications ? What will be the level of dependence on outsourcers in, say, ten years period ?
• What are long term implication of the trend for the country as a whole ?

As for the first question my impression is that often offshoring is not an absolute necessity, but is a layoff in disguise. In this case it does not matter what quality is provided by offshoring firm as it will be only a temporary one, anyway. IBM often is used by big companies is such a way; people are first transferred to IBM and then after a year or so are laid off, but not from the original firm but the new one and that alone provides sometimes a significant cost savings.

Offshoring of IT operations can carry more immediate and more damaging risks for the reputation of the companies than it is commonly assumed. Generally handing price pressures by choosing a sole low cost supplier (and then usually increasing this pressure by trying to renegotiate the terms downwards) is asking for troubles.

Strategic risk of divided loyalty

When you transfer a process to a third party, it can behave in ways that are opportunistic. It might cut costs at your expense, or use the knowledge for benefits of the direct competitor. There are many facets of this strategic risk and the list below is far from being exhaustive:

• Security overhead. In no way outsourcers view the host company as benefactor. The situation is more complex and one of the important component of this complex view is "a milk cow." This component stimulate direct and indirect forms of abuse of corporate infrastructure. Software licenses that outsourcers use might have legs. The differences in income are just too big not to produce substantial backlash, especially when outsourcers are seeing who is getting all those plush salaries. Very high differences in pay for a similar job are always source of the implicit or even explicit tension and sometimes even anger.

  That means that offshoring increases the probability of abuse of privileges, stealing of software licenses activation keys, fraud, industrial espionage, abuse of facilities for training and unrelated to contract purposes/activities (especially job search). Those "transgressions" are much easier because of the demoralization of the internal staff (see below).

  To counter those risks the company needs additional investment in security. But enforcing distributed security is qualitatively more complex thing than enforcing local security. It's very difficult to understand who is really sitting being the terminal 10K miles away connected via VPN and what he/she is doing without huge monitoring infrastructure that might eat substantial part of cost savings, if those still exist. Remote employees are remote in more than one sense. And increased security risks inevitably gradually increases security costs. There is also a tendency to play security risks for the political advantage by the remaining managers. That in turn create substantial additional overhead and the class of people aligned with surviving management staff and interested in maintaining and enhancing the status quo, no matter how harmful for the company it is. There is some subtle synergy between interests of security staff and interests of outsourcers. The case where the current head of IT security previously was the key figure in offshoring of the IT operations are not that uncommon.
  

• There are direct incentives for offshoring vendor to be inefficient. The more resources it uses, the more the outsourcer company pays. And to ensure that even more revenue flows to the vendor tomorrow. In a paradoxical way the outsourcer incentives at least partially are in direct opposition to the company efficiency goals. Moreover the inefficiency of offshoring vendor often stimulates the host company employers to create a parallel, "shadow" infrastructure duplicating the tasks.
  
• During the renewal of the contract the strategic shift of power may be already in place. The company that outsource is particular function needs to think not only over the term of the initial contract, but also what will happen during renewal. It is not that easy to make sure the other side doesn't have all of the bargaining power after several years and that the only option for the "host company" will be walking from the renewal. This is where offshore offshoring is getting really crazy.
  
• "Soft landing" might be problematic. There is always a possibility that at one point the relationship should be terminated and it its recommendations of Lord, Bissell & Brook state:

  Vendors typically ignore or only casually address what happens when the relationship ends and how the customer reconstitutes its operations, transitions to another offshoring vendor or simply winds down the operation. Given the relatively high incidence of prematurely terminated offshoring agreements, it is critical for the parties to structure and document a disengagement process that aligns the parties' interests and adequately addresses the financial and operational issues presented by early termination.

  If a company stops working with the offshoring firm, then all the intellectual property transferred in process might be lost or even walk to the competitor.

  Does the service provider own the work that it develops on a customer engagement?

  Consideration
  Your offshoring contract should clarify which party owns work performed rather than leave this matter open to question or later negotiation. Vagueness could lead to conflict later on. You and the client should clearly define ownership of the contracted work, whether it's software, business processes or other intellectual property developed over the course of the contract.

  Change of ownership is one of the most underappreciated risks. If offshoring company is not doing well it is often sold and you face the consequences.
  

• Limited Remedies. As stated on the page of the legal firm Lord, Bissell & Brook

  Practically all vendors' first drafts include significant limitations on their liability under the offshoring agreement. These limitations include caps on damages, exclusions of consequential damages, limited indemnification rights for the benefit of the customer, and broad indemnification provisions protecting the vendor. Such limits cause customers to have limited or no recourse against a breaching vendor and potentially exposes the customer to massive losses. Understanding these limited remedies and the practical impact of such remedies can be difficult. Negotiating remedies that provide practical and meaningful protections for the offshoring customer is often one of the most adversarial and difficult elements of the offshoring contract.

  Creation of exit strategy is very expensive and channeling tasks. Generally the longer offshoring continued the more difficult it is to execute a sound exit strategy without incurring substantial losses, That's why change of ownership is one of the most underappreciated risks. If offshoring company is not doing well it is often sold and you face the consequences.

High attrition rate

Attrition reaching 15% to 30% per year is typical for Indian offshoring firms (especially those with boiler room mentality) (NYT data). That means that firms which outsource IT have permanent problems due to "outflow" of skilled programmers and "inflow " of fresh programmers to be trained.

• Retraining as a systemic problem. There's no better way to become a good surgeon than by experimenting on a live patient and now the patient is the company which outsourced the IT services ;-). The quantity of highly skilled people in India like in any other country is very limited and in no way most of them are patriotic enough to stay in India longer than absolutely necessary. In such an environment abuse of resources for training, architectural missteps and additional leaks of intellectual property are inevitable. Too often, a piece of code and the institutional memory of what it does and how it does it walks out the door when a developer leaves a company. It is important to understand that with attrition rate 30% in the three year offshoring project there might be no developers at the end who were present at the beginning of the project. Still the truth is that even low level developer that is working on a particular module of code often possesses a lot important knowledge some of them can be classified as intellectual property with legs, the property that the company may not even know he/she possesses.

  Therefore even if you are lucky and managed to find qualified people for a particular project and get some real (not imaginable/result of aggressive and deceptive marketing typical for offshoring companies, as is often the case) experts expect that those people will soon be gone. Why should they work for a salary 5 times less than they can get elsewhere ? If we are talking about equal opportunities, is not this a discrimination of a kind ?

  And in most cases the picture is much bleaker: while getting your money and training using your resources outsourcers rarely managed to meet the expectations in application development projects and even more rarely to produce that product that is really worthwhile. Often the net result is an increased software bloat and smelly architecture. Even companies with split workforce (as is the case in many startups) are having tremendous difficulties operating two distant team and keep them productive all the time and keep both locations secure despite the distances. As one friend summarized his management experience/frustration: it's better to have a team in provincial USA then in metropolitan country X: in country X you usually either have too much security that semi-paralyze people or not enough to keep things from flowing out". And here we are not taking about offshoring but about employers of the same company who are in the same boat and thus have higher level of loyalty and enthusiasm; often those people are additionally motivated by options to buy company shares in case the company will go public and the possibility to move to, say USA in case of success)

  That means that in application development often using a smaller local team is a move that is more cost-effective and productive than dozens or even hundreds of outsourced coders, no matter how you slice the task in hand. In programming quality never can replace quality. And that's probably the only way to get important code which actually works, not those repetitive cut-and-paste monstrosities called "software" nowadays.
  

• Hidden Labor arbitrage within offshore country itself. Labor arbitrage refers to the practice of reducing costs through the use of low-cost labor; it's not uncommon for offshore firms to outsource part of their job to even lower cost provider. The folks who came to work were paid hourly and varied widely in quality. They have even lower loyalty then the staff of the main offshoring firm but still they often have an equal access to data procedures and algorithms. And often their survival strategy is to do the minimum amount of work possible.

Elevated insider risks

The intellectual property used in offshoring transactions includes the materials the vendor uses to perform the services, such as its pre-existing know-how and the know-how developed specifically for the customer. Customers typically share their know-how with outsourcers although much of this know-how the customer does not want shared with its competitors. In call centers companies were making themselves vulnerable to insider theft. Call center collect lots of data about customers and gave ready access to it to employees who, in turn, had easy access to the internet. Think about such simultaneously present factors as centralized data, high turnover of personnel, easy distribution of stolen data. Here we have subtle dangers that typically get superficial treatment in the press, such as the risk of leaking corporate intellectual property or data to third-parties. How you know that your customer data did not grow legs in offshore environment, or the algorithms procedure or logistics that give your systems a competitive edge, is not sold to the highest bidder or just given to local businesses? Who owns, and more importantly, who has the continuing right to use such know-how can be controversial issues, especially after the relationship ends.

If after the relationship ends the customer does not have the right to use a wide range of intellectual property the vendor used to perform the services, then termination of the relationship could be very costly and burdensome for the company. Addressing topics such as derivatives, residuals and know-how providing a competitive advantage to either party are very difficult and costly and require high level of skills from the managers, lawyers and key specialists of the company. And both managers and key specialists are usually demoralized by offshoring. That's like fighting infection with weakened immune system.

"Truth in advertising" is usually absent and the company often buys "cat in a bag"

There is a notion that Webster calls "the thermocline of truth" the thin like between facts and fiction similar to the thin zone that separate warm water from the cold in the pool. The ability to distinguish facts from fiction is usually absent during the negotiations. Outsourcers are usually pretty creative in marketing: a guy who just finished Novel courses can be sold as an experienced Netware administrator to unsuspecting offshoring lover. It the guy is clever enough, in most cases he will became experienced Novell administrator, but only a year or two on the job; your company job. The same is true about all those fake "The Hero of Socialist Labor" style certifications like ISO-9000 or Capability Maturity (CMM). This is a systemic problem. A lot of people in offshoring companies are neophytes that are marketed as top specialists. Many are recent college graduates, and do not have industry experience. Many will learn quickly. Some will not. The latter are the most dangerous, especailly if important project due to them reached stage when only euthanasia can help:

Euthanasia for the project might be the best course, but people often have too much heart and money invested to end it.

One technique for preventing a disaster is to add some humility to the endeavor. Invite a third party to review your work - a reliable consultant, an academic or a buddy CIO.

An outsider can "walk into the project setting for 20 minutes, talk to a few people and come to the conclusion that things have run amok. But people inside may not even be aware," Keil said.

Greyhound Lines Inc. in Dallas, for example, seemingly didn't know anything was wrong with its new reservations and logistics system - until it went live and 12% of its customers went away mad in one month.

Though specific individuals might learn from their own mistakes, those lessons aren't transferred to any collective IT consciousness.

"The people with that [failure] experience aren't always the people in authority the next time that situation arises," observed Kevin Hickey, a former head of IT at Trumbull, Conn.-based Oxford Health Plans Inc. "The fact is, hubris will always be with us."

And then there's what Webster calls "the thermocline of truth." Swimmers know that lake water separates into warm and cold horizontal bands. The area between is a thermocline.

In IT groups, everyone below Webster's "thermocline of truth" knows the project is sinking, while everyone above it thinks things are fine. Senior executives can be oblivious. They aren't involved enough, they don't want to have to face a failure, or underlings are afraid to tell them, he explained.

"You can see that persist almost until the point where the project is supposed to be delivered," he said. "Then, suddenly, it's, 'What do you mean this will take another six months?' "

That was part of the sorry plight of Fort Worth, Texas-based AMR Corp.'s Confirm reservations system. Confirm managers are even said to have orchestrated a cover-up.

Overall, IT culture is such that problems, especially expensive ones (which hold the most valuable lessons), are hidden. Programmers write around buggy code rather than tear it apart. Managers revise project specifications to reflect what they did instead of what they should have done. Senior IT leaders neglect to tell their bosses the bad news.

Most companies are too embarrassed to analyze their failures, said Effy Oz, an associate professor of management and IT at Pennsylvania State University in Great Valley.

"People will say, 'There's no time, and we're not paid to have these discussions,' " Oz said. "The CEO has to be a very confident person to say, 'These things happen. Let's learn from it.' "

The average loss in an abandoned project is $4.2 million, according to Oz. The blowups in Computerworld's top 10 list cost much more than that. And, if history is any indication, they will happen again.

Inherent inefficiencies of offshoring due to additional centralization and breakout of lines of communications

Business units may also feel that they lost the control to the extent they cannot do their jobs effectively and secretly to recreate a given IT function duplicating costs. The individual and collective desire for control, and the motivation behind receiving and doling it out, creates a politicized atmosphere that lowers morale and has other unintended results. In many cases the information given by outsourcers, especially about the business side of the project, is often not true (to say the least).

• Early warning signals are lost. Outsourcers are inclined to swipe the dirt under the carpet.
• There is no clear process ownership.
• Timely problem resolution is hampered by people who do not understand company infrastructure as they serve several companies simultaneously. This is one problem with outsourced helpdesks but in no way it is limited to them. Theoretically you can have higher quality people in outsourced helpdesk due to pay differential, but in reality there are problem even in maintaining the existing level of quality as the people on the other side of the line do not have all the implicit knowledge about your company infrastructure and essentially behave like "problem resolution database browsing monkeys". Add the language and cultural problems and you have what you deserve.
• The gap between system administration and developers grows really wide, which leads to performance and stability issues. Sysadmins would build out a platform that's based on what they thought, and then developers would come throw their code on it, and the two didn't blend very well.

Demoralization of staff at large

Offshoring is considered by internal staff as the race to the bottom. Often they charge top management with the hypocrisy. A key factor that set the stage is that many employees are seeing the brass as compete hypocrites, who cut heads without cutting their salaries and benefits. That badly affect the level of trust and breaks lines of communications. Employees start interpreter both the situation the company faces and the values that company adhere differently than the brass. Of course some level of hypocrisy is unavoidable in an organizations, but at some point quantity turns into quality and demoralizations kicks in.

Disgruntled or unethical employees may be looking to get revenge on an organization. This is very dangerous, because such people know the organization from the inside. The disgruntled employee may know the procedures that are in place, and the best way to bypass them. Be careful when you talk to former employees.

If loyalty is undermined, the behavior of those who survives significantly change. They feel to be "the next in line" and behave accordingly even if this is not true. Typically top IT workers who survived brutal downsizing adjust their professional outlook. "I Thinking "I can be next and I don't try as hard as I used to," they say to themselves. "I used to work 60-to-70-hour weeks and even do work at home on top of that. Now, I'll do my 50 and not make myself sick."

Most will perform fewer discretionary actions that would promote organizational effectiveness. Such actions would include helping co-workers, not complaining about trivial problems or speaking approvingly about the organization to outsiders. In one servey four in five of the survey's respondents confessed that if requested, they would forward company sensitive information to a former colleague, even if they were now working for a rival firm.

While it's obvious that no one should work at the expense of her health, that "I don't try as hard as I used to" comment is the typical sign of demoralization. That means that the company is now facing the danger that existing IT staff keep distance from the job and from management and avoid "putting soul" into it. People who'd seen keep their distance from the job and no longer put in 100% effort. "I won't make the same mistake again by being dedicated," -- a typical sentiment goes -- "It isn't worth it." Wisdom is, in large part, a product of experience, and experience comes with age. And, like any shrinking commodity, experienced workers will increase in value as their availability declines. It therefore seems counterproductive for the companies to estrange the very people who possess a shrinking resource on which it ultimately relies.

That means that firms that went through a transition to outsourced operations, need to compensate not only direct loss of talent and "know how" but also account for a substantial demoralization of staff. Demoralization is a very dangerous (and very costly) problem that actually can cost organization more money then it expects to save via offshoring. More then 80% of act of sabotage in the USA are performed by disgruntled insiders and anger is the main motivation for such attacks. But even without sabotage the possibility of harming the company taking into account typical difference in professional competence of IT managers and key specialists (Dilbert effect) are endless: sending the company in the wrong direction like Ivan Susanin classic can cause more damage then most direct attacks by a disgrunted emploee. Procuring unnecessary services is another rich with possibilities path of "less resistance". There are various rather subtle forms of revenge that people who know the ropes can use, if they are really disgruntled. Bringing some monster, expensive but semi-useless "enterprize software system" that otherwise company would be wise enough to avoid is just the most benign trick in the repertoire. Cases where huge expensive servers were bought when a small server would suffice, onsite consultants were indiscriminately awarded $200 per hour wages as well as huge contract cost overruns, etc., are not that infrequent if demoralization kick in. Some companies actually are only one disgruntled employee away from a full-blown BSA investigation [Wired News Dumped Workers Find Revenge ]:

A programmer who worked on a website for an entertainment company said in an e-mail that he turned in his ex-employers when his contract was abruptly terminated.

He asked BSA not to identify him because the company he filed the report on was giving him "a great reference."

But he said he was happy to see that his former employer was fined $473,000 for software piracy after the company's internal audit turned up software that the company could not prove it had purchased.

"We were fired with no warning, the bosses got sweet severance packages and everyone else got a week's pay," the e-mail said. "While the security guards were marching me and my fellow now-unemployed, ex-coworkers out of the building, I figured why not turn them in? I knew they were using hot copies of programs and anything I could do to cause my former employer pain seemed like a great idea to me."

Those who are interested in the effects of the demoralization process can read an excellent work by Professor Tamotsu Shibutani Derelicts of Company K A Sociological Study of Demoralization".
Classic fiction book by Jaroslav Hasek The Good Soldier Svejk : and His Fortunes in the World War is also a recommended reading ;-). It exposes what is called the "power of the powerless" -- subverting authority from within while seemingly going along with the grandiose designs of the ruling elite. Joseph Heller once said that if it weren't for his having read The Good Soldier �vejk he would never had written Catch-22.

In some cases remaining employees can explicitly or implicitly align with outsourcers in stealing software activation keys, using facilities for unrelated to job functions (especially for job search), etc. Here is one interesting comment:

What WILL slow down and even stop IT offshoring is the elimination of IP rents. At present the American OWNERS of the enterprise collect all the rent (return to monopoly ownership privilege) on the software created by the foreign producers. Outside US borders the price of the software is minuscule as pirated copies are easily obtained. Only Americans pay the inflated (rent seeking) prices. Same with pharmaceuticals. Middle class Americans pay the toll as Bill Gates gets richer and richer. If the Indians are as good as the Americans at producing software then why does Bill Gates need to get the rent, and why does software cost so much? It is my understanding that Indian manufacture of pharmaceuticals is much the same kind of deal and if not then the Chinese probably do the pharmaceuticals for sale in places other than the USA. Again: Americans pay all the rent.

The American producer's anger with the Indians taking the jobs is misplaced. The anger should be directed at our own government and its continued reward to rent seekers. If the software were priced exclusive of rent, then we would all (Indians and Americans alike) benefit from the comparative advantage. But as it is, so called, "free trade" is merely exacerbating wealth disparity in the USA and keeping foreigners from realizing the full return to their efforts.

First of all it's very difficult to separate architectural issues from implementation in all but trivial software projects. The second thing is that implementation difficulties serve as a feedback and the reality test for architectural decisions and if this feedback is absent there is a tendency to stick to the first chosen architecture and suffer consequences.

Also a good talented programmer is more then 10 times more productive than an "average" programmer (meaning one that has no aptitude for the profession, and who went in just because it seemed an easy and clean way to make good money). This was well known for decades. Also now quantity of low level coders can create the sound design for the project. If you are talking about architectural issues, then situation is more complex. Of course there are talented programmer of any nationality. But why they should work for pennies for an outsourcer instead of moving to countries where he/she can be paid more is unclear. In any way it's important to stress that a good programmer will simply create programming product of a quality that average programmers never can create. No matter how many of them you can hire...

As Doug McIlroy aptly observed "Any system built without in-house talent produces out-house results.". Bill Gates quote reproduced above is also on to something here: the possibility to outsource all future innovation and become a hostage of the offshoring vendor is too high to ignore. Also the companies who offshore programmers because they're "expensive" is participating in decimation a the next generation of engineers/software architects and, paradoxically, the next generation of IT senior management. The threat of offshoring makes it unattractive for younger generations to entering the field. Especially when universities charge arm and leg for junk courses under the disguise of brand names on their buildings (the crisis in computer science education and the quality of the tenured faculty is another story). Actually in large universities education is semi-outsourced too: often instead of top professor the students are exposed to a recent graduate with a strong accent. And it is he, not the students who is the major beneficiary of the course he is teaching.

You also need to access negative PR consequences for the company that attempt offshoring. Public opinion in the USA became very skeptical. As the refection of it some politicians start to voice their reservations and may push some laws that change the playing field: on the op-ed page of The New York Times, Senator Charles Schumer recently asked "whether the case for free trade ... is undermined by the changes now evident in the modern global economy," particularly offshore offshoring. His answer? A resounding "yes."

NEWS CONTENTS

• 20040712 : Bracing for Backlash ( Computerworld )
• 190821 : Roll Your Own Future by Maryfran Johnson ( Roll Your Own Future, )

Old News ;-)

[Jul 12, 2004] Bracing for Backlash

Computerworld

One day, the political windstorm around offshore outsourcing will blow over. One day, the inflated numbers on both sides of the debate will be debunked. One day, the last angry letter from a displaced American IT worker will be published.

Unfortunately for IT managers everywhere, that day is not today.

The emotional backlash against any plans to outsource technology jobs overseas -- regardless of how economically or competitively driven -- is a force to be reckoned with in today's IT workplace. It dampens the morale of even the most valuable, talented employees, as we saw recently in our Best Places to Work in IT survey [QuickLink a4610]. One reader sent us a note last week suggesting that we include "foreign outsourcing statistics" in future Best Places reports, thereby revealing how many U.S. citizens are part of the IT head count of the companies on our list.

Negative reactions can blast back from customers as well as from affected employees, as Dell and Lehman Brothers discovered when they had to pull customer service operations out of India. Despite a few other widely publicized retreats, the majority of Fortune 1,000 companies are forging relentlessly ahead with offshoring plans -- albeit with greater stealth, in hopes of avoiding bad publicity.

The bottom line driving what Gartner calls an "irreversible megatrend" is always the same: cost savings too compelling to ignore in an open, interconnected global marketplace. "To outsource offshore is not a political decision on the part of the company. It's an economic decision with political ramifications," says Mike Hoyt, CEO of Paradigm Works. He's one of our sources in "Damage Control" [QuickLink 47609], a story about how IT managers can cope with the offshore backlash.

One impressive example of a company dealing effectively with the backlash problem is Union Bank of California, which created a "sourcing management office" to handle any concerns that might harm its reputation with customers. The office's duties include handling all communications about the bank's offshore plans.

The preventive measures we discuss in our story basically boil down to having honest, frequent, candid communication with everyone involved. CFO magazine gave similar advice last month in its cover story about offshoring, noting that the majority of the 275 financial executives surveyed had no intention of canceling their offshoring plans, despite the backlash. Some 42% of those CFOs said they were realizing net savings of more than 20% from their offshore projects, and 64% were planning to increase offshoring levels.

So where do companies go wrong in communicating their outsourcing plans? Let us count the ways. They overlook a basic communications plan for internal or external consumption (the offshoring version of a "don't ask, don't tell" policy). They fail to explain why a given project is going overseas or how such decisions are made. They try to downplay the negatives about workforce changes. They hide their plans for as long as possible, then look guilty and act defensive when the news leaks.

Some analysts are predicting that the backlash will fade away by next year, and I hope they're right. But in the meantime, IT managers must brace for the backlash and deal with it decisively.

"You don't want rumor to overtake reality," says Michael Treacy, co-founder of Gen3 Partners, an outsourcing consultancy. "In the end, you can only politicize so long, and then the facts will prevail."

Maryfran Johnson is editor in chief of Computerworld. You can contact her at [email protected].

Roll Your Own Future by Maryfran Johnson

AUGUST 09, 2004 | Computerworld

Now here's a real classic on the comeback trail: developing your own applications. Sounds so retro, doesn't it? The kind of thing start-ups do when the CEO doubles as the chief product engineer and surrounds himself with a cabal of MIT grads writing code. So what's going on when large pharmaceutical companies, insurers, hotel chains, health care providers and online powerhouses like travel firm Orbitz are found, in this day and age, productively rolling their own?

Computerworld reporter Gary H. Anthes answered that question last week in his cover story about the many sensible, cost-saving and even surprising reasons why companies build their own applications rather than buying into more packaged software ["Roll Your Own," QuickLink 47884]. What he uncovered flies in the face of conventional wisdom that buying is better than building -- a belief assiduously promoted by software vendors of all sizes.

And no wonder. The lifeblood of so many software companies increasingly flows directly from their maintenance and support fees, which have risen to nosebleed levels of 18% to 25% annually to offset the economic drag of lower sales in recent years.

Take Oracle as Exhibit A. When the database maker posted its financial results in mid-June, the single biggest factor cited as offsetting its slow-moving application sales was rapidly growing revenue from those fat fees for software maintenance. That revenue is increasing nearly twice as fast as new license revenue, CEO Larry Ellison said.

But it's not just the high cost of applications and their hefty annual fees that are driving development of homegrown applications. Ranking high as reasons for this approach are dissatisfaction with complacent vendors that don't respond quickly enough to user needs, and dismay over software suites overloaded with features and fiendish complexity. At Reinsurance Group of America, for example, a $35 million global enterprise administration system that was developed in-house not only fueled a competitive leap past the company's rivals but also was vastly preferable to the nightmare alternative of integrating more than a half-dozen commercial packages to provide similar capabilities.

Yet the greatest reason of all to roll your own is the ability to tailor IT to your business, to control the fate of applications too vital to trust to outside developers. It's about enabling (may Nicholas Carr forgive us here) a competitive edge that really does matter.

At Reliant Pharmaceuticals, for example, CIO Ron Calderone wisely heeded user resistance to complicated sales force automation tools and built a relatively simple system using speech recognition technology for the field agents. A packaged SFA system would have cost $4 million to $6 million, Calderone reckoned, but he delivered just what his business comrades needed for about 15% of that.

"Simple and inexpensive" are often the magic words associated with the best in-house application projects. We're hearing that mantra more often these days, particularly as open-source software carves inroads at the enterprise level. As Orbitz CTO Chris Hjelm put it in our story, "We are largely an open-source shop, so when we think about buying software, there's a general aversion to it."

The "buy vs. build" debate will no doubt go on forever. But the combination of open-source software with sophisticated development tools and standardized Web services is dramatically changing the face of that argument. When companies go looking for technical creativity, innovation and a competitive edge, they won't be buying that off anybody's shelf but their own.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater�s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019