|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
Softpanorama Search
|
Version 0.85
Copyright 1998-2006, Dr. Nikolai Bezroukov. This is a copyrighted unpublished work. All rights reserved.
"Any system built without in-house talent produces out-house results." Doug McIlroy |
| "The
IT systems are your brain. If you take your brain and outsource it
then any adaptability you want (becomes) a contract negotiation".
Bill Gates |
| "We trained hard... but
it seemed that every time we were beginning to form into teams we would
be reorganized. I was to learn later in life that we tend to meet any
new situation by reorganization: and what
a wonderful method it can be for creating the illusion of progress while
producing confusion, inefficiency and demoralization."
Roman author Petronius Arbiter |
Attempt of Classification of Hidden Problems in IT Offshoring
IT offshoring as a sign of internal problems
The loss of operational flexibility
Systematic Overestimation of Savings from Offshoring
Strategic risk of divided loyalty
Demoralization of staff at large
Long Term Implications of Offshoring
Offshore software development and, to lesser extent, moving software maintenance oversees creates complex and expensive to resolve and contain problems that are usually swiped under the floor in the quest for quick buck. In all cases, but especially in "Total Offshoring" cases, those problems tend to increase with the age of the relationship.
In this paper we will try provide a critical assessment
of a primitive offshoring mythology that completely disregards numerous and complex
risks that separation of any function by organizational boundaries, and large distances
(along with cultural and language differences) entail. We try to show that
many inherent in offshoring factors are connected with the additional
complexity of the multi-vendor environment in comparison with the internal provision
of the same services. This additional complexity tend to offset the cost savings "in a long
run". This is especially true for the "custom software development" type of
offshoring products, the type the author have most experience with. Unlike production of commercial software, the production (and
consumption) of commercial offshoring services leads to dramatic increase in
the level of complexity of IT management and creates multiple levels of
dependencies from the outsourcer, the dependencies that tend to increase with
time.
A classification of most important risks is proposed. Loss of flexibility, divided
loyalty, demoralization of staff and the difficulties inherent is distributed development
and managing distributed workforce requires more complex
and more costly coordination that saps a lot of talent and energy of both programmers
and, especially, managers on both ends of the phone line, so to speak. It should
be stressed again and again, that mitigating such
risks requires top level of management talent. We will argue that such talent usually
is not present in firms attempting offshoring as offshoring in more then one way
is a sign of internal problems of IT department with the excessive bureaucratization
as probably among the top.
I think few writers on this topic understand the scale of the loss of operational flexibility that is inevitable due to more rigid and formalized nature of outsourced development and maintenance as well as shift in attitudes of the remaining staff. And that alone can be very damaging to the competitiveness of the organization, the very notion that brought offshoring into the spotlight. We will also try to show that outside of few well defined and very finely specialized areas offshoring usually increases, not decreases the level of bureaucratization of IT departments.
People are better then institutions
Prince Peter Alexeievich Kropotkin
This paper is mainly limited to issues connected with software development. It does not cover other areas of offshoring in details and its conclusions are inapplicable outside the state scope of the paper. When we are taking about offshoring in this paper the term should be understood as "offshore software development/maintenance".We will generally distinguish between outsourcing: hiring other organization to perform certain or all IT functions and IT offshoring. The latter is a special type of outsourcing when the substantial part of work (understood as a software development work in this paper) is transferred into other country. Often this country is India (the largest software offshore in the world) or other South Asian country, although offshoring to Eastern Europe, Ireland and other lower wage countries is also practiced but to more modest extent.
India's exports of software and services such as call centers and back-office operations totaled $23.6 billion from March 2005 to March 2006, up by 33% from a year earlier [National Association of Software Companies (Nasscom) data]. It's unclear how much of this money is related to pure software development efforts. Offshoring can also be performed via multinationals, for example IBM:
IBM has invested $2 billion in India in the past three years. The $6 billion investment announced today will go toward the cost of increasing its workforce, expansion of IBM's facilities in the country, and projects such as education and health that the company is working on with the Indian government, said Shanker Annaswamy, managing director of IBM India. IBM did not, however, say how many additional people it will be hiring in India. IBM's Indian unit is already the largest of any country outside the U.S.
As part of the investment, IBM is setting up in India the first in a new kind of IBM service delivery centers that deploy processes and technologies to automate IT services delivery, the company said. After the pilot is complete, the technologies will be rolled out across other IBM service centers. It is also setting up a Telecommunications Research and Innovation Center at its lab in India. The new center will serve as a key resource for IBM's telecommunications companies around the world, the company said.
We will not explore "multinationals-bounded" type of offshoring in this paper and concentrate mainly on the type of the relationship where outsourcer with its software development specialists is mainly based in foreign country with minimal (often via intermediary or tiny local office) local country presence. We also will not explore small teams outsourcing efforts, when a couple of high level software developers are cherry-picked in some remote country and are paid to work on the complex, challenging project for a particular foreign company. This paper is mainly about institutional outsourcing of programming projects that usually involves considerable number of people on both ends of the phone line, with offshore software developers organized as a separate legal entity -- outsourcing company.
According to the Yankee Group statistics, the offshoring market is estimated at 11% of IT or about $150 billion globally. Fortune 1000 enterprises spend, on average, about 3% of their revenues on IT ( the figure varies from 7-9% in financial sector to 1% or less in manufacturing industries).
India is the largest offshore destination with approximately 1 million of IT workers involved in offshoring (2% of worldwide IT revenues and workforce). There are approximately 5 million IT workers in the USA. That means that total Indian IT workforce approaches to 20% of the USA IT workforce. The vast majority of the revenues of the Indian software developers come from large, established companies. The average sited saving are 20%. The numbers mentioned in IT press can vary form 20 to 80%.
Even from limited analysis of large software development offshoring deals in the USA, it's clear that after three-five years many companies run into fundamental problems. One important, almost unreported trend is that the savings tend to diminish with the age of outsourcing/offshoring relationship, but dependency on the outsourcer tent to increase with the age of the relationship.
Like with marriages not all offshoring software development relationships ends peacefully. And not all of the them produce healthy children -- software for a particular company. While cross-border software development problems are usually carefully swiped under the carpet, in few cases the resulting problems became so severe that they leaked to the press. AT&T Wireless was a good example of the latter, the company where the key ingredients of troubles were mix of SAP/R3 deployment problems and offshoring, not just pure offshoring. SAP/R3 adaptation to particular company can be considered to be a pretty complex software development project with SAP/R3 as a development toolkit.
As a rule of thumb, the press coverage tends underreport the risks of IT offshoring while advantages (and there are several of them too, including, of course, potential cost savings) are systematically overhyped:
According to a recent CFO Research survey, the most critical areas for technology delivery — and those that present the toughest challenge for companies — are selecting implementation partners; implementing hardware, software and process redesign; and change management and staff training. To improve their chances for success, companies need to focus on risk analysis, both within the company and with their partners and strategic vendors. While most companies factor operating performance, cost of technical failure and security into their risk assessments, few consider the risks of misalignment with business needs, regulatory compliance and HR/organizational risk.
It looks like the level and the severity of problems connected with offshore software developemnt is company size dependent. Large organizations are vulnerable to wider array of offshoring software development problem and the severity of each generally increases with the size. Moreover many offshoring software development problems that we will discuss below in less acute form are typical for any large multinational corporation and are inherent for any project with staff separated by large distances as well as cultural and language barriers. At the same time smaller firms in many cases can use specialized services provided by outsourcers more successfully.
In this sense offshoring in a large companies might be connected to more general problem of the level of management talent in a particular (usually "old") organization (Software development offshoring is often inversely correlated with the level of understanding/appreciation of IT by top management). Or it might be that the chain of events that starts with offshoring has some inherent destructive effects of the company IT management (cuckoo effect ? )
The first step in understanding the situation is to recognize that in a world
of software development
offshoring
Kafka begins to make sense. I am far from being so naive to claim that my observations
are completely right for all offshoring software development relationships. Like in marriages there
are some made in heavens. I am talking here mainly about an average case
without too much mutual love (and respect) and about specific areas of
offshoring
of non-standard
application development and subsystems (with lion share of Web frontends
development) as this is an area where I have the most experience.
For standard IT functions and subsystems like WEB hosting, mail, etc risks are
slightly easier
to contain. But risks are raising dramatically when the function is less standard
and software development is one such function. One example production-related
supply chain applications are directly linked to the competitiveness of the
company as companies with full scale implementation of SAP/R3 suddenly realized.
And they are more difficult to outsource.
In those cases it is important to see a different perspective which is often hidden from the view by somewhat sycophantic IT press (we all like free subscriptions and don't ask question who is paying the money at the end of the day, don't we ;-)
As a first step to managing risks, many countries require companies to conduct risk assessments. The latter usually tries to identify top risks and evaluate how serious each risk is. May be this paper can provide some help in identified risks for the companies that are entering the path of IT offshoring on non-standard applications.
In no way I would like to try to discriminate between programmers or managers of different nations: there are many talented individual programmers (and managers) in any nation, especially in nations with high quality university education as well as in any nation with a large population pool.
|
In no way I would like to try to discriminate between programmers or managers of different nations: there are many talented individual programmers (and managers) in any nation |
Still this is not exactly the matter of the level of talent involved. Even if the talents pools are equal or even the other side is superior (actually, especially, if the other side is superior), offshoring is never a risk-free option. Moreover due to complex interplay of distances, cultural differences and income levels it is very difficult, if possible at all, to understand all the risks involved when the contract is negotiated; there is no free (cost cutting) lunch: complex ( and expensive to solve with the framework of the relationship) problems inevitably surface in any sizable offshoring project.
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:
IT offshoring usually a sign that "Something is rotten in the state of Denmark" in this case in IT department. The most plausible assumption is that the internal IT department reached such a high level of bureaucratization and that management position are occupied by incompetent people who manage to get promotion due to political factors inherent in excessive bureaucratization and first of all favoritism and nepotism (the latter is much more common in modern organizations then people assume). Often IT department became a roadblock for operational units, not a helpful function that the company values. That also means that the feedback from business to IT management is dangerously weakened and business units do longer not care if IT department is internal of outsourced, judging that it cannot be worse. In many cases they are deeply mistaken.: if IT management itself is part of the problem and if talented IT managers are no longer with the company the offshoring only amplify those weaknesses.
This danger of management incompetence on both ends on offshoring chain, and first of all gross incompetence in the host company is the question that is rarely discussed in mainstream IT press. In one of rare articles on the topic How companies court disaster in offshoring deals published in Computerword OCTOBER 30, 2000 Geoffrey James wrote:
The days are long gone when top executives were so computer-illiterate that they refused to have a computer on their desks. But there's still an impressive amount of executive stupidity floating around. That's particularly true when it comes to offshoring, especially when such deals go sour.Problems in offshoring deals are far from unusual. According to a recent Dataquest study, more than half (53%) of all offshoring customers report having renegotiated a contract, and in nearly one-quarter of these renegotiations, the vendor lost the account.
As a result, litigation and arbitration over failed offshoring agreements is now a big growth area in computer law, says attorney Tobey Marzouk, a partner at Marzouk & Parry, a Washington law firm that specializes in such cases.
A big source of offshoring failures is the way that offshoring vendors tend to "sell high," pitching their projects to the CEO rather than to the IT staff and managers. One of the perversities of corporate culture is that outside experts are often more respected than inside talent, and thus many projects get sold to top management, which then pushes the IT group to go along even when IT knows that the project is impractical.
Another common piece of stupidity is top management's refusal to hire a lawyer who specializes in offshoring litigation during contract negotiations. While it's true that many companies have legal staffs, software litigation is a relatively new field, and few lawyers have either the legal or the technical training to understand the issues involved. Offshoring contracts must be written carefully so that they identify exactly how performance will be measured, with clear acceptance standards and testing procedures. "That way, you can hold the vendor's feet to the fire to make sure problems are fixed," says Marzouk.
When failed offshoring projects end up in court, the knee-jerk reaction of top management is sometimes to fire the IT manager who was the project liaison. That's monumentally stupid, according to James Johnson, CEO of The Standish Group International Inc., a research organization in West Yarmouth, Mass. He tells the story of one small company that "paid the vendor $20 million and found out that the resulting system not only wouldn't work, but that it would cost $20 million a year to keep running." The IT director - a former employee of the vendor - was subsequently fired. But when the case went to court, the former director appeared as a hostile witness, causing the company to lose its lawsuit.
There are several additional factors that need to be mentioned:
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.
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).
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:
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.
|
Typical IT offshoring with its flawed motives and inadequate assessment of the risks involved sows the seeds that later germinate into the contractual dispute. |
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:
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.
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.
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.
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.
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.
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).
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.
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."
Long term implications of offshoring are the problem that is the most difficult to understand. We can only speculate here. But there are two large areas that we can try to address based on circumstantial evidence:
As we mentioned above, offshore offshoring requires very strong management that involves far more communication and management travel than would be expected at first. With enough management talent, over time, any difficulties can be worked out, but it takes tremendous amount time and energy for a strong relationship to be built. the problem is that skills management is a very scare resource that is difficult to find and difficult to maintain and burn-out atmosphere of a typical offshore software projects. Additional cultural differences also creep in.
Generally employees are more willing to share with people they trust and who treat them fairly. Socialogists have found that people tend to engage in knowledge hiding if:
It is easy to see that all three conditions are met in a typical offshoring situation.
On the other side of the fence outsourcer is reluctant to share the ideas that might undermine its revenue base. That means that "business as usual" is a preferable mode of operation for both sides, no matter how counterproductive it is for the organization as a whole.
Companies worry about cross-border offshoring not only because of the potential loss of jobs, which is manageable, but because of the potential loss of brainpower. After an offshoring, the activates that were outsourced move across the border. At the time of the deal it is difficult to understand all the implications including to what extent the activities outsourced are of vital importance for the future of the company. Thus, the loss for the company that outsourced It services becomes twofold.
This danger of brainpower loss is an objective fact - it cannot be brushed aside, labeled as old-fashioned protectionism pursued by people who don't understand the imperatives of globalization. It goes deeper than that. And it cab have political implications that can eventually cost jobs the very executives who initiated such moves. In many companies executives who pushed for offshoring of important parts of business are viewed internally like something in between idiots and traitors. Of course such feelings are masked by obedience, but such deeply held views never help to achieve a career success.
I feel that the only way for a country feel safe in the current world is to ensure that it has the cutting edge industries and an educated workforce that keeps learning. But offshoring undermines the very motivation for learning. Moreover it partially cuts off the oversees talent, who "under previous regime" was motivated to come and settle in the country due to higher standard of living. There is simply no jobs for those people.
Think of the world economy as a ladder. On the bottom layer are the countries
producing natural resources as well as countries which produces only agricultural
products, textiles and some low-tech goods. Toward the top are economies, which
make sophisticated computer electronics and first of all CPUs, software, pharmaceuticals,
plains and medical equipment. The latter are cutting edge technologies of today. In the middle
layers are all the other nations, manufacturing "cutting edge technologies of yesterday"
everything from steel to autos and less sophisticated electronics. Viewed
in this way, economic development is simple: everyone tries to climb to the next
layer, get into more advanced and more lucrative industries.
This works well if the topmost countries can constantly create new industries and
products. That allows older industries to move overseas while fresh jobs are generated
at home in new industries. But if innovation stalls then the country found itself
in trouble as in the absence of protective tariff barriers that help to preserve
existing industries despite existence of cheaper foreign competitors jobs are moving
to loser cost countries. That means that without new industries on the horizon,
offshoring can do for IT the same it did for manufacturing jobs earlier.
History does offer cause for worry. There was a period, from 1973 to 1985 (1985
was the start of PC explosion) when technological change contributed almost nothing
to growth, according to government data. Not coincidentally, that was also the same
stretch when U.S. manufacturing became vulnerable to foreign competitors and eventually
largely disappeared.
In IT initially only low-skill software and support jobs were the ones sent to foreign firms. But now we are seeing better jobs, even new development jobs, going overseas. While "top guns" still can survive, that creates a grim situation for less-skilled American workers employed in IT. Before, they could take, say, call-center jobs or operator jobs or even "code monkey" jobs, prove themselves, acquire more skills and advance to better-paying positions. But with those type of jobs leaving the country there’s no longer the ladder that you can climb up. You need to go to Wall Mart or McDonalds, get a "Mac job" and stay on this job for the rest of your life.
While "outsource or perish" zealots are trying to connect offshoring to avoiding business closures now, its biggest impact may be longer term. Quantity eventually turns to quality and with a wide array of mid-level professional jobs moving offshore some structural changes might be underway in the US economy. It also means that for current students the career you studied for -- and spent a lot of money on -- probably won't sustain you for your working life. This structural change could result in a far worse job picture 10 or 15 years down the road. All this talk about retiring baby boomers is just a hot air. Despite this generation retirement the U.S. workforce may face frequent career changes and downward pressures on wages.
Charley Reese once mentioned the other dimension when he discussed off-shoring manufacturing jobs, but I think that this is applicable to IT too:
Manufacturing jobs are the gateway to the middle class. Losing them is lowering our standard of living. Losing them because the federal government does nothing to stop the loss is poisoning Americans' belief in their own government. Eventually, America's defense needs will become dependent on foreign imports. Allowing that to happen is treason by fools.
We can view this situation also under another angle. One important nor
rarely openly discussed incentive for offshoring is dismantling of
a current lucrative IT labor sector. Understanding that the expected side effect
of offshoring is "devaluation of IS/programming jobs" and putting most programmers where they
belong from the management perspective ("proletariat of mental labor" if we reuse
old cliché here make understanding of some paradoxes inherent in offshoring
easier. If management actually is preoccupied with shifting the labor to
devalue the jobs the last thing that they care is if the companies in India or
Philippines or elsewhere are perfect or not. The offshoring provider can be well a "Potyomkin village" type
of a company, not capable doing any useful job at all (and some probably are). But
if the purpose is to dismantle the labor sector this situation it's still OK.
As long as they can push the reorganization and related layoffs to produce cost
savings the game is still worth the candles: IT budgets drops to the level below
1% in large non-IS companies and most of the hate wave goes in the direction of
offshoring companies, not the current management. If survivors might not be able to cope with the increased workload
that's a separate problem. And it's not bad if offshoring
completely fail as long as the period is a couple of years or more; then in
two-three years there is a new situation and new career opportunities
(as in saying "if you can invade the country do it; later you can hire whatever
you want to justify the decision").
In this respect the important side effect is that excesses of Y2K and Internet
bubble can be eliminated and 40K of slightly depreciated dollars
is now again a viable salary for a pretty highly trained Unix admin/programmer in
the USA. Moreover the level of unemployment among IS personnel is sufficient for
find any kind of qualified peoples for reasonable (from management point of view) prices.
And complex contract jobs now sometimes go for "net" $20-30K here in the USA
without any India. That actually might mean that dollar was revalued, not
devalued in this particular areas.
While outsourcing is often performed in the name of efficiency, outsourcer is not motivated to perform the most efficient job. The key reason the outsourcer is in this business are profits and the ability to "milk the cow" by exploiting the existing complexity of the infrastructure and inefficiencies for reaping additional profits are two factors that makes outsourcer reluctant to implement any significant improvements. If in addition the vendor feels the company reached the condition of "vendor lock in", the offshoring vendor has the upper hand in any strategic negotiations and can explicitly (or better implicitly) raise the prices without raising the quality of service.
This
level of dependence increases over the time with the first milestones reachable
probably in three to five years of relationship. As soon as local talent is gone
the organization lost important part of the organization IQ. That usually
correlated with the drastic deterioration of quality of management staff.
Dumber organization makes dumber decisions, especially the most important
architectural decisions. And no amount of glossy presentations about
quality of service, six sigma courses or
certifications can change this situation.
The implicit pressure to cut costs also play important role in deterioration of
services with the time. I heard interesting stories about how Indian companies now are suffering
from the competition from Filipinos, mainland China and like. They might be losing
some offshoring contracts because it you want cheap labor, India is no longer
the only place to go, not it is the lowest bidder. That means that there is an
increased pressure for Indian firms will try to find offshoring subcontractors to do
part or all the job to save costs. In
Computer Counsel Six Issues Facing Offshoring Service Providers - Computerworld
this item is worded pretty explicitly:
Does the service provider have the freedom to move services offshore or use subcontractors as a cost-savings approach?
Consideration
To reduce costs, your offshoring contract should provide that you may relocate services and work with subcontractors of your choosing. The customer will require you to negotiate appropriate confidentiality provisions and may attempt to assert other limitations on these rights. The key to securing this right is to guarantee clients seamless, high-quality service.
At the end I would like to remind again very apt observation of Bill Gates "The IT systems are your brain. If you take your brain and outsource it then any adaptability you want (becomes) a contract negotiation".
While a universal phenomenon, nepotism and corruption are more prominent in Asia then in the USA. As offshoring companies pay above average wages they are natural dumping ground for all sorts of relatives of influential politicians and top IT managers. That means that such companies have high internal overhead and top heavy bureaucracy. Here is one telling comment related to the lowest type of offshoring, helpdesk offshoring:
When we debrief the Indian reps, they always say the same things: "Sir, I did the necessary and escalated the call. The customer has become irritated." "Sir, the customer asked me something new. I have pooped myself and now must ask for an upgrade of the incident". "Sir, I am not prepared for this. I have a decent job that pays me a living wage solely because of who my parents are." The caste system is alive and well, and working for all the Kumars and Rajs of the world, thank you very much... "I graduated first in my class with a master's at age 21 in English studies, but I only learned by rote and cheated most the time. This is acceptable."
[Harrison2005] Warren Harrison The Sabateur Within IEEE Software. From the Editor
[NTAC2005] United States Secret Service National Threat Assessment Center (NTAC) Insider Threat Study
[HBS2004] The Offshoring Revolution HBS Working Knowledge
[DiamondCluster2005] DiamondCluster2005OffshoringStudy
[Noble2005] Scott Noble Why Offshore Offshoring Projects Fail - IT Observer 20 May 2005
[Vaughn2005] Terrence Vaughn Who's to Blame for Failed Offshoring, 3 - Computerworld
[James2000] Geoffrey James How companies court disaster in offshoring deals Computerword October 30, 2000
[Bertch2003] Wesley Bertch How Offshore Offshoring Failed Us Network computing | October 16, 2003
3.10 Offshoring - Grundschutz Manual 1.7
Poor communication stymies IT offshoring - IT Week
Buyer Beware - Offshoring - CFO.com
Offshoring Risks Worry the Wary - Offshoring - CFO.com
Copyright © 1996-2009 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
Disclaimer:
Last modified: August 15, 2009