Sunday, 06 February 2011 00:00

More Jobs Shipped to India

Rate this item
(0 votes)

Ship leaving port

Friday brought news of another company outsourcing part of their IT. The details are sketchy, but it appears that all the COBOL programmers (many counting days until retirement) are going to have their jobs moved half way around the world. Soon after, it sounds like the IT infrastructure and operations will follow. Friends lamented about more jobs going overseas. I had to ask what other options management had. I did not hear any alternatives.

To the dismay of my cohorts and their potential pink slips, I am less concerned about outsourcing the administration of servers, networks, and base applications. For most companies, those are not the systems unique to their mission. These days, those functions are utilities. However, outsourcing customized systems that are at the heart of how a company does its business and distinguishes itself to its customer, is very risky. It may be the only option now; however, it could have been avoided.

 No One Here Can Do The Work

First, look at reality. There are no new COBOL programmers coming out of American universities. The least sexy area of study in the computer science department is COBOL—if you can study it. The name even makes you want to yawn—Common Business Oriented Language. The people that know COBOL started in business fresh out of college in the 70s. Simple math puts the younger ones close to their sixties.

Outsourcing Core Business

The risk? Knowing the language is only a small fraction of the knowledge required to maintain a system. Losing the understanding of how the few million lines of code run, the subtleties of how they support the business, and interaction of the modules is a huge risk. No amount of documentation will ever replace the experience that came from changing one line off code that left of a municipal tax. It was not enough to make the invoice run look real low, but three weeks later when taxes were due, someone in accounting noticed something very wrong.

The Politically Incorrect Option

One option, if you cannot find trained students, is to bring the COBOL developers onshore. The expense is higher, but the technical risk much lower. The real problem is the massive political undertaking. Headlines reading "Unemployment At Record Highs, Company Hires People From India," would be a public relations nightmare. Politicians would spin it this way and that to make it beneficial them or detrimental to their opponent.

Management has been painted into a corner. Unfortunately, they are holding the paintbrush. The solution is never getting to the point of obsolescence.

Averting The Situation

We all know the answer. When we buy a house, we know we have to do maintenance. Small items, like painting and replacing carpets, are done on an as needed basis, and can be postponed when budgets are tight. Replacing the roof or rotting LP siding are projects that we think about years in advance—before the wind, the rain, and the bugs encroach. To protect our investment, we modernize the entire house, adding a garage, or remodeling to add another room or two. If it looks like the neighborhood is heading into disrepair, we sell as quickly as possible and move to a better investment—one that will take us into the future securely.

Unfortunately, businesses that are stuck with difficult to maintain, twenty-year-old systems only have themselves to blame. They chose to try to get one, two, three, or more years out of that "roof" and now the upgrade is getting to be impossible, since no one works on slate roofs anymore. Averting this problem needed impetus a decade or two ago. Taking the expense and challenge to upgrade systems, migrate to newer technology, and stay in the mainstream instead of letting technical debt increase incessantly.

The winners are the people in India, China, or Vietnam that are getting new jobs. The losers are corporate America that has just found another way to kick the can down the road another few years.


The lure of postponing system replacements for short-term savings and improved quarterly reports only delays the inevitable. These projects are tough; they are laden with minefields and booby traps. The only path to success is a superlative team, strong planning, and contingency funds. When it is all in place, plan a little more. But, it goes nowhere without the team. This requires leadership and continuous training of your staff in the technology that aligns with your company's strategic plan.

(You do understand how technology relates to the strategic plan, right? Okay, you had better spend a few days digesting the strategic plan, getting your team together, and building a technology roadmap.)

Read 5160 times

Related items

  • Process Mapping

    Process is at the core of any business. It makes work predictable, repeatable, and transferable. Without it we cannot scale our businesses. However, process can be a bane to making progress. Processes that work for a $10 million company have difficulties supporting a $30 million company. Trying to scale them to a $300 million company will not only fail but not address the issues that larger companies have that were never dreamt of in a smaller organization. Processes need to be discarded, revamped, and built—all of that without creating an overburdening bureaucracy.

    Anytime you need to go someplace, you first have to know where you are. Processes are never static and your company's current state is probably far from where you think it is. Hence, the first step is mapping out you company's current state followed by defining the future state. This is more than a logical map of the process; it must also include physical maps. Whether your process is solely to provide a service (say, website development) or physical (say, manufacturing) there are logistical issues that complicate the process flow. Without fully understanding those nuances, future state processes will not reach the desired efficiencies.

    For more information about process mapping fill out the form to the left and we will get in touch with you.

  • Success vs Culture

    The other day a Latvian student contacted me for my views the connection between culture and success criteria—an important and intriguing topic. After working in Taiwan, Singapore, Korea, Japan, Israel, United States, and Canada, I wear many scars of both blatant and subtle cultural violations. I also know that within a culture one person's success is often another person's failure. So, after dispelling concerns about clicking on some random email link, I completed her survey (please feel free to take it yourself). In the process, I struck up a friendship with the student, Kristine Briežkalne, who is studying at Riga International School of Economics and Business Administration . She has some interesting views and presented me with a Venn diagram showing four frames to a project (business, client, project management, and growth perspectives) and how they intersected. As the diagram is part of her Master's thesis, I will let you ponder the how to label the overlapping areas (an eye-opening exercise).

  • Kill The White Knight

    There is a reason we do not teach classes on fixing failing projects. Many a cynic feels that we simply do not want to teach our trade, however, our reason is far nobler—we should be teaching prevention rather trying to create white knights to save the day. It is the same philosophy as building a fence at the cliff's edge rather than an emergency room at its base. Our language is replete with idioms telling us to look past the symptom and address problems at their root cause. 'An ounce of prevention versus a pound of cure' or 'a stitch in time saves nine.' Please, feel free to supply your own in the comments. Unfortunately, most of our businesses loathe this philosophy, waiting to address an issue until it is irrefutably broken.

  • Tales of an Expert Witness: Sex, Lies, and Video Tape (Part II)

    Trust relationships, certifications, and standards sound like such a safe harbor. These sound like such great words in a proposal or statement of work. How could you possibly go wrong building a trusted relationship with a customer by committing to follow a standard? In fact, this can burn you… in court.

    No one ever starts a project with the goal of ending up in court. In fact, litigation may never cross your mind; after all, you have built a trusted partner relationship. Taking a few cautionary steps, however, will make your life easier if you end up in that ill-fated litigious position. Your best chances for success come long before you enter the courtroom—even before the project starts.

  • Comparing Organizational Change Management Models

    A few weeks ago, I set out to write a post on the comparison of various organizational change management (OCM) methodologies and realized that would be a disservice to my readers. It would simply drag you down the path of implementation while failing to focus you on building the foundation. The pressure was too much and I have relented to numerous requests on making that comparison. The caveat is that juxtaposing these models is not comparing different varieties of oranges or even apples and oranges; we are surely comparing the peel to the fruit they contain. Hence, comparing methodologies like Kotter's model (the peel), Prosci's ADKAR (the core), and General Electric's Change Acceleration Process (the whole fruit) need a different approach.

Leave a comment

More Info on Project Recovery

Tell me More!

Please send me more information
on fixing a failing project.

Rescue The Problem Project

Internationally acclaimed

Image of RPP

For a signed and personalized copy in the US visit the our eCommerce website.

Amazon logo
Buy it in the United States Buy it in Canada Buy it in the United Kingdom
Buy it in Ireland Buy it in Germany Buy it in France
Buy it in Italy Buy it in the PRC
Buy it in Japan
Book sellers worldwide.

Upcoming Events

Other's References