Managing Offshore IT

A few weeks ago, I got on a conference call with some of my peers across time-zones. After the meeting was called to order, one could hear the distinct wailing of a baby in the background. The manager chairing the call couldn’t stop himself from grumbling “Can the person with the baby crying in the background please get on mute?”

In an era where many of us work extended hours from home and stay awake at odd hours to take calls from peers and colleagues across the globe, the occasional ‘background notice’ be it the brawling baby or honking of irate drivers in a traffic jam are perhaps inevitable. Going on mute, unless one has to contribute to the discussion is an option but not always practical, especially in cases of animated discussions where one forgets to un-mute before making an important point or argument. The person at the other end of the line may be taken aback by the silence from this end unless we quickly figure out that we are on mute!   

Well, juggling distractions of commute and/or domestic life while also productively participating in conference calls is more of an art than a precise science… experience is sometimes a good teacher.

On a similar topic, calls with international teams leads to phonetic spectacle that is not always amusing. The reasons are not hard to see: the accents and pronunciations we grew up with are hard to mask. The Southern Drawl, Scottish accent or the Distinctive South-Indian accents are hard to suppress and becomes a big challenge when trying to spell crucial details (say, an email-address) over a teleconference; for example try spelling my last name Krishnamoorthy, which is a mouthful even for many (North) Indians.

Now, try to get the average Joe (or Raj) to do a phonetic description and he will either begin with K for Kansas or K for Kite depending on whether he is from the mid-west or she is from India….and by the time you get to ‘N’ there will be a couple of iterations over whether it is eMm or Nnn.. Well, why not stick with N for November? So, theoretically, one could start with K as in Kilo, R as in Romeo, I as in India, A as in Alpha (not A as in Apple as most kids are taught in school)…For those curious, check out the Wikipedia entry on “NATO phonetic alphabet” The Phonetics are a tried-and-tested list used by militaries, and those in the business of international communication. This is a tool that requires a a bit of practice, and is not rocket science.

Posted by Mohan Babu K. at 03:16 PM | Permalink | Comments (3) | TrackBacks (0)

James McGovern writes a very interesting blog entry titled “Outsourcing and the Emancipation of the Enterprise Architect” He begins with an anecdotal straw-poll of six enterprise architects about outsourcing stating “I asked each of these individuals whether their employer was currently outsourcing work to India.... My last question to these individuals was once outsourcing to India fails, would you within your own mind, smile?” for rest of the discussion, I read with the assumption that James uses offshoring interchangeably with outsourcing.  In the blog, he goes on to add:

“Let's pretend that Martin Fowler, Kent Beck, Brenda Michelson, Grady Booch, Joel Spolsky, James Robertson, James Tarbell, Robert McIlree and other top talent in the blogosphere were all offshore working in Bangladesh. I believe folks would not only be more participatory in terms of making outsourcing a success, they would actually volunteer to make it happen so as to work with these individuals. If there is a way to eliminate all the lower-talent folks in India (approx 97.4% of the IT population) then outsourcing would not only have a better chance of success but enterprise architects would be emancipated...”

Let us switch gears to another blog by Business Week writer Steve Hamm who blogs
“The Indians have been doing classic systems integration work for years—mostly installing big complex software packages from the likes of Oracle and SAP. But, to gain the kind of sway with customers that the best of the Western tech services outfits enjoy, they have to build up their consulting capabilities and handle more transformational engagements.
When it comes to business or solutions consulting, Infosys seems to be the farthest along . . . .
Steve quotes Infosys’ new chief executive, Kris Gopalakrishnan “Offshore outsourcing is only one part of the puzzle,” he said. “If you want to take full advantage of outsourcing and take advantage of globalization, you have to help organizations make the transition.”

The contrast between the viewpoints of bloggers is marked, and perhaps goes to the heart of argument, can ‘high end services be offshored?’ …. if yes, by whom and where to? Having participated in a fair share of ‘strategic consulting’ and ‘Enterprise Architecture’ (EA) engagements for clients ranging from Fortune 500 to smaller/mid-size organizations in the recent past, here are my two cents:

• Contrary to what James and his peers believe, sourcing of EA, Centers of Excellence and architecture definition is already happening, and in many cases extremely successfully. This is a topic we looked at earlier in this blog [and referenced in my recent Cutter IT Journal paper: “The IT Innovation Process: Necessity or Oxymoron?”]
• James talks about ‘pretending’ how offshoring would succeed (only) if industry gurus like Martin Fowler et al were offshore. Well, we don’t have to go too far: Fowler’s ThoughtWorks is already offshoring Agile Software Process with Offshore Development; eating one’s cooking?
• Though I don’t completely agree with James’s viewpoint on “a way to eliminate all the lower-talent folks in India” one has to agree that the large number of people hired and trained from Engineering schools in recent times by service firms offshore will take time to cut their teeth [Ref: Vinnie Mirchandani’s hilarious blog on The "Day Care" Model] Agreed, these are not the people who will compete for global EA work

Bottomline: High-end ‘technology consulting and Enterprise Architecture definition also involves Organizational Dynamics 101: A dimension of ‘high end’ work being sourced (and offshored) that most people ignore is the Not Invented Here (NIH) syndrome  which I have seen surfacing in many engagements. There is a reason for this: techies, designers and architects, especially Enterprise Architects are an extremely proud lot. Now, I could stir a debate by stating that many EAs don’t openly seek ideas and ‘best practices’ from other ‘silos’ in their own Enterprise. In large organizations, getting ‘Enterprise Architects’ talking to ‘Portfolio Architects’ and ‘Application Architects’ requires a very savvy technology governance council and an assertive CxO.

Getting the Enterprise Architecture community to seek outside council, especially from an outsourcing vendor is not really a debate about offshoring.....it is an internal (organizational) debate about seeking outside council; you either need consultants to help you or you don't! [And let's not mix this debate with where your consultants are going to come from]

Posted by Mohan Babu K. at 08:12 PM | Permalink | Comments (2) | TrackBacks (0)

A while ago, I blogged about “Open Source and Offshoring: Two Disruptive Forces Begin to Converge?” Extending the thinking, there was an interesting article “Social networking Joined-up thinking” in a recent issue of Economist magazine that talks about the trends in social networking and how it is impacting the corporate world. The author begins by examining “consumer adoption of social networking has grabbed most attention since then. But interest in the business uses of the technology is rising. . . .Many companies are attracted by the marketing opportunities offered by community sites.” This blog is an example of social networking that I attempt to participate in.

There is another example of a client’s business I came across that made me reflect on how Open Source, Offshoring and Web 2.0 are beginning to converge.  A case-in-point:

The company, let's call it XYZ.com, was founded during the heyday of dot.com with the focus to be an online aggregator of hi-tech books and research data. The idea was to digitize content from multiple publishers to be served on its electronic publishing platform. The business model is ‘simple’ yet innovative: digitize books (with IP) and then ‘sell’ subscription to a collection of books to groups (research institutions, universities etc). And given that they are a hi-tech company, it is not surprising to see a proliferation of Open Source tools and technologies – ranging from the IDE to core content and search engines -- being adopted in the IT shop. A classic mashup of Open Source and Web 2.0! The interesting aspect of companies like XYZ is 

• Changing the traditional paradigms: XYZ’s business model is challenging the traditional publishing model [I should know: I recall working with all the traditional publishing tools : printed notes, manuscripts etc while my book went through the different stages of publishing life cycle]
• While innovating and applying Web 2.0 techniques to their busisinesses, companies like XYZ are also embracing Open Source software, and in some cases partnering with Offshore service providers
• This is a good example of business that exists because of the Internet.. and will probably morph into 'Web 2.0' business in time, perhaps without much hoopla

And no, you will not really read about such ‘innovations’ in a whitepaper or textbook … until perhaps the Web 2.0 entrepreneurs shake up a few traditional goliaths. .... And who knows, John Hagel may have a slightly different perspective, next time he attends NASSCOM's Leadership Forum. [He blogs 'emerging from the discussions at the conference involved the increasing need for innovation in the offshoring business.']

Posted by Mohan Babu K. at 07:56 PM | Permalink | Comments (3) | TrackBacks (0)

Technology sourcing is more about managing people and teams than with any other aspect, and unlike most other businesses, the people being ‘managed’ are highly skilled, educated and articulate.

Dr. Tushar Hazra’s Cutter advisory that came to me a few days ago made for an interesting read. The advisory, titled “Making Teamwork and Collaboration Happen in a Dysfunctional Work Environment”  begins by talking about  dysfunctional teams, asking “can teamwork and collaboration happen in their work environments? How difficult is it to make teamwork and collaboration happen there?”

Most of us in the offshoring space have seen our fair share of challenges, including those of team dynamics, teams beginning to get dysfunctional. For this discussion, it would be appropriate to look at the case Hazra articulates: “In a recent large IT sourcing engagement, the client's senior leadership team encountered this dilemma. This client has employed multiple sourcing vendors for the past ten years, and it has reorganized its own IT organizations a few times. During this process of transformational change, it lost a number of key employees. To complicate things further, over a period of three years, this company has acquired five small companies with niche expertise -- two of them augmenting business functions and the other three being small IT firms specializing in infrastructure and information systems support services. In addition, three years ago, senior management decided to outsource all of its application development to an offshore vendor, formalizing a relationship that treated the vendor as a primary IT partner. These ongoing changes in the IT organization have had a tremendous impact on its ability to deliver tangible results to its business counterparts. It has also had a negative impact on the culture of the IT organization: employees and consultants have a tense relationship with the prime vendor (the offshore partner). There have been several incidents of miscommunication and noncooperation among various teams, as well as a lack of trust among various teams and individual team members. A set of political impediments is also evident at the senior management level. Overall, this company can be considered a dysfunctional work environment.”

I think this case is a great example of “Dysfunctional Work Environment,” for which Hazra provides seven steps for managers and executives to consider. I will not repeat Hazra's analysis in the blog though I like the way he summarizes, stating “The problem does not go away by ignoring it. To resolve a problem, we need a positive attitude -- and we need a lot of it to make teamwork and collaboration happen in a dysfunctional work environment.”

The seven steps Hazra talks about in the research note cover most dimensions; however, there is an additional ‘softer side.’ One could also argue that software teams become dysfunctional because managers fail to recognize the potential of leveraging the “software culture” [This is a topic I had also examined further in my book] My research takes off from Prof. Erran Carmel's viewpoint “Software professionals worldwide belong to the computer subculture…Software guru Larry Constantine argues that the computer subculture is stronger than national culture and that the programmer in Moscow is more similar to his American programming peer than to other Russians…. Engineers, like software professionals, place high value of on work and on achievement and relatively low value on social relationships.”

Footnote: though challenges of managing globally distributed teams are inherent in the ‘flattening world;’ the practices you and I adopt in the field will determine the success of our initiatives.

Posted by Mohan Babu K. at 06:21 PM | Permalink | Comments (1) | TrackBacks (0)

Most of us have come to realize that Offshoring requires additional skills in planning and scheduling across time zones and geographies. What about Culture and Mother Nature? 

Planners of an American client faced a unique challenge when they scheduled a field-trip to India last week, omitting to account for a regional holiday due to the ‘New Year’ in the Indian calendar. The American client managers were amused and decided to take the extra day off to visit the local sites and get over their jet-lag.

Well, if it is not the local culture and customs, trust Mother Nature to throw the occasional spanner in the works.  A colleague, Ajay, and I were hoping to kick-start an engagement with a client in the North East (of US) this week and he had flown in from India over the weekend. On checking the weather over the weekend I realized that a snowstorm was scheduled to engulf the area and decided to hold-off on my hour-long travel; just as well.

Monday morning Ajay called me from his hotel room saying he had ventured to the client’s office that was just down the road from the hotel where he was staying and found that the doors were locked, with a notice stating ‘closed due to snow’

Though the two unrelated anecdotes are the different sides of the same coin, “risk mitigation and management” as our Project Manager friends call it, the unintended consequences are not always the same; unlike the American clients who were able to make hay while the sun was shining, Ajay is content to be stuck in a hotel-room, in Anytown USA

Posted by Mohan Babu K. at 06:52 PM | Permalink | Comments (2) | TrackBacks (0)

There are frequent articles in the IT and business press on merits of certification; about how certification helps candidates set themselves apart from their peers in the market, a differentiation strategy if you will. My musing is not about certifications per se but about another dimension: recertification.

To set the context for this discussion I am a certified Project Management Professional (PMP) from the PMI, and Open Group, TOGAF, certified Enterprise Architect. The certifications are in addition to my educational qualifications in management and computers. Now, every so often my peers and colleagues begin to muse about the impending expiry of their PMP or TOGAF or other certifications. There are endless debates in chat forums and discussion groups on ‘why should I pay to re-certify’ or ‘should I re-certify’ etc… my two cents:

Argument for re-certification: 

• Professions-skills-upgrade argument: The real argument for re-certification is that newer topics, techniques and technologies continue to emerge in the field and ‘professionals’ should continually demonstrate their competence. This argument probably holds true of ‘professions’ like teachers and doctors [‘profession’ in quotes since one could debate if Computer Programming and Software development is really ‘Engineering or Art’ and if one subscribes to Donald Knuth’s argument, do artists need to be certified or recertifed to ‘prove’ their skills?]
• Club-dues argument: Just as many elite (social) clubs have an entry/admissions criteria and a means of enforcing a hefty club dues from those eligible and willing, re-certification is a ‘price’ to pay to remain a part of the club.
  Note: this is just my personal interpretation; no certifying institution would make such an argument officially; though if one looks from an operational angle, club dues are necessary to keep the certification organizations going (unless they have a large corporate sponsorship or ‘grant’)

Argument against re-certification:

A brilliant student gets into MIT or Harvard and graduates; and for the rest of her/his life, carries the ‘Harvard graduate’ or MIT tag. She does not have to get ‘re’certified every so often. Years or even decades later, nobody questions the spark of brilliance that got him into the elite institution and expects the brilliance to manifest itself as he builds on other life experiences. [Even in this argument, one would see a ‘club dues’ angle: If you are from an elite institution; there will be an equally elite alumni association, that is bound to be after you for the alumni fee etc; right?]

At the end of the day it probably doesn’t even matter which side of the argument you and I subscribe to because … as with most things in life if you got to have it, you got to have it; and if there is a price to pay …
 

Posted by Mohan Babu K. at 12:04 PM | Permalink | Comments (1) | TrackBacks (0)

I was working with a client (shall go unnamed) recently, helping the IT Director define a strategy and roadmap that his (and our) team could take forward. His vision and mandate was crisp and refreshing. Having recently taken over a portfolio of applications, he was looking to make incremental changes to the underlying systems, architecture and framework components in an ˜agile” fashion. This was the tactical part. His strategy was to get business sponsor the ‘low hanging fruit’ (more functionality) while he would also overhaul the underlying architecture.

Given this scenario, consultants would typically take a boilerplate and start calling out the ˜steps” [a.k.a. a typical IT strategy /roadmap definition exercise]:

• Analyze Current State: What does the application portfolio look like? (business functionality, technology landscape, SLAs etc etc)
• Define End-State: Would the portfolio look like (after the re-architecture)
• Define the steps to take, processes to follow etc

And herein lay the challenge: we have discussed agile development paradigm, and even agile development using global teams. [Further to my earlier blog, CIO magazine also ran an interesting feature: ABC: An Introduction to Agile Programming] However, the question that came up: we all talk about agile programming/development: What about defining and executing an “agile strategy”? Which is what Mr. Director was working towards.

The ˜agile” challenge here, was that Mr. Director, who himself was highly technical, had mapped out the end-state at a “20 thousand foot” level and was willing to proceed with the steps to get there, betting that with a ˜few mistakes” along the way, one would get there.
 
What made this engagement interesting?
a) The need to call out the “steps” that would lead to the end state at least at a high level
b) Need to develop and actionizing a plan for quick-win projects that our team to could immediately take forward and execute, while the roadmap [big-picture] was evolving.
c) Change management: buy-in from the globally distributed team (including getting the internal Infosys team on board)

I will blog about this experience further but I would also like to hear from the gurus in the field: how would you approach this scenario?

Posted by Mohan Babu K. at 10:55 AM | Permalink | Comments (2) | TrackBacks (0)

The topic of talent management, resource management is perhaps as old as that of the software services industry; after all services – architecture, design and development of systems, and managing the processes - are rendered by people. So, what’s new about the debate over ‘shortage’ of skilled software professionals in the offshoring space?

Not much really. However, if you read the business press or even commentary by bloggers and analysts, you may get the impression that there is a ‘new’ crisis brewing in the services sector.

For instance, Vinnie Mirchandani blogs So, I am reading Consulting Magazine and I see TCS, the largest Indian vendor, plans to hire 30,000 associates a year, most straight from universities. The other larger Indian firms have similar models. . . . Indeed with India having one of the youngest work forces in the world, the opportunity is even greater.  But high Indian staff turnover is also the result of that model.

It is amusing to read his blog, equating the hiring and mentoring fresh recruits at services firms to a "Day Care" model; to which, Sadagopan responds and argues that the investments in training that Indian firms are making are impressive. (I will not highlight Infosys’ world-class training and internship programs here as the point is moot.)

However, a point that both Vinnie and Sadagopan seem to agree on is the need for service firms to build a “middle layer” more aggressively, a topic that my colleague Richa also blogged about a while ago.

Another theme that surfaces in such discussions of skill shortage is about location: Will India continue to retain its edge in Offshoring [eg: a recent article in Computerworld: IT Execs Look Beyond India for Possible Offshore Sites].  Though it is a perennially interesting topic that generates animated response (for and against) in the media and among consultants, the real answer would require a crystal ball, which most of us don’t possess.

In my mind, there are two dimensions to the challenge: challenge faced by service delivery firms and challenges of enterprises that contract with such service delivery firms, many in the offshoring space.

Hiring and retaining talented professionals is an edge that every software service company aspires to. Managers and executives at service firms live with the challenge of talent shortage, hiring, training, mentoring and retaining technologists.

But what do the talent management challenges of software service firms translate to for offshoring enterprises? Not much; or at least it should not really matter much…. Why? Because the clients who sign on service delivery firms expect that they will have access to talented professionals when they need them, where they need them….and that’s why they have sourced to their vendors/partners in the first place.

Case in point, you sign up with Infosys, the Program Managers, Project managers and leaders will work with you to ensure that you get the right technology solutions to your business problems. Where they go for talent that will ‘work’ on your projects can, and should probably be transparent to you; right?

Posted by Mohan Babu K. at 12:55 PM | Permalink | Comments (4) | TrackBacks (0)

A recent Economist Intelligence Unit survey talks about how Outsourcing and offshoring of innovation are set to increase despite concerns about loss of control. A recent article quotes the report stating “Increased competition, the cost and complexity of innovation and a surplus of ideas are encouraging many companies to restructure their approach to research and development,” says Rob Mitchell, editor of the report. “Our survey shows a considerable shift towards greater outsourcing and offshoring of R&D in what we term a global innovation network model, despite concerns about loss of control over a function that is often considered core to a company’s identity.”

It was interesting to read about Ann’s views on this report stating “The EIU expects the number of companies with at least some R&D activity occurring overseas to increase from the current 65 percent to 84 percent by 2010. The number of companies outsourcing R&D to third parties is also expected to grow from 64 percent to 75 percent.”

Agreed, Organizations and executives are certainly looking to leverage external skills and talents when it comes to innovation; and the idea here is not very radical. Even a couple of years ago, the business press had begun talking up “Outsourcing Innovation” For instance Business Week ran an interesting article stating “First came manufacturing. Now companies are farming out R&D to cut costs and get new products to market faster. Are they going too far?” Even further back, James Quinn wrote about “Outsourcing Innovation: The New Engine of Growth” in MIT’s Sloan Management Review

What has changed in recent times is the greater confidence of corporate leaders [in sourcing nations] in the ability of offshore partners to deliver projects and work from halfway across toe globe.

Researchers are certainly looking at different aspects of outsourcing Innovation. For instance, Prof Kevin Desouza blogs "Most organizations have realized that they cannot reach business goals by conducting all activities internally. Cooperating with business partners and leveraging the know-how found in an organization's midst is a salient determinant of competitive successes. Many organizations struggle to increase the intensity and success of partnerships."

During my interactions with technology executives and leaders, I find that they are looking beyond such publications touting Innovation Outsourcing. Essentially asking “what does this mean to me and my organization?” or “how do I ensure my team also leverages such practices and applies them in our context?

And this was the topic of my previous blog, talking about my Cutter IT Journal paper where I also illustrate a case study on ‘IT Innovation’ by establishing a Globalized Center of Excellence (CoE). The case study I wrote about was based on an engagement with a large client where our (Infosys’) globally-collocated team collaborated with the client’s team to establish a CoE. The goal was to foster and manage a culture of ‘technology innovation’ while leveraging a globally distributed team. For specifics of this case-study you could refer to the Cutter article and of course buzz me.

Posted by Mohan Babu K. at 08:54 PM | Permalink | Comments (6) | TrackBacks (0)