Managing Offshore IT

I have been trying to soak up a bit more on Agile Software Processes and challenges in an offshoring context. One of the reasons for this is an intellectual curiosity, and of course a professional need to be prepared to address the issues when discussions come up during interactions with client teams. 

This said, my views on Agile Offshore development haven’t changed much since my last blog on this a few weeks ago Among all these differences my point of view is clear: I'm sitting on the fence!

I continue to seek out opinions on the topic, especially from practitioners at Infosys and outside. A few viewpoints include the following (and interestingly, most quote Martin Fowler’s original essay on the topic) 

Mishkin Berteig, in his blog "Agile Advice" says “For offshore teams, high-speed access to the same work environment as the "onshore" team is critical (for software, this means code base, development environment, test environment, db environment, tools, etc.).” However, he has a strong viewpoint on early stage adoption of Agile projects, stating "If you are early on in adopting agile methods, I strongly recommend that you don't use your offshore resources. If the organization insists on paying for them, then let them sit idle. Yes, that's right: IDLE. Your on-shore team will probably be more productive without them."

David Churchville, in his blog "Are Functional Specs Redundant?" takes a more practical view on adopting Agile Processes in early stages by focusing on Functional Specifications and requirements ….stating “Similarly, if you're using an offshore development team, it's going to be even more important to write down the specifications in detail if you hope to get close to what you want.” 

An interesting blog is the “5 stumbling blocks for new corporate agile projects” from Alex Pukinskis where he is clear about the ground reality, stating “Offshoring and outsourcing are,  for better or for worse, realities for many organizations. An Agile approach can help significantly with offshore / outsourced projects, but be warned” Pukinskis’ view perhaps echoes my outlook of Agile Development initiatives.

For clients that have already embarked on projects leveraging Agile Software Processes, we -- Managers and Consultants -- need to be in a position to advice them on best-practices and “gotchas” of working with offshore teams, leveraging the right tools – for communication, code management and process management – and more importantly ensuring a buy-in from teams.

Agile Software Development requires teams to be working closely on the software life-cycle, given the short lead times behind gathering requirements, developing and testing the code. This also requires teams to work more closely in ensuring the right handoff of requirements-to-design, design-to-code, code-to-test and test-to-production. The processes and tools of communication that are being leveraged successfully by offshore-onsite development teams can extend to agile development paradigm too.  This said, can should be read with a ‘Capital C’ since tools alone will not help in successful offshore execution of an agile projects.

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

Here are my eclectic thoughts on interactions with managers and executives in the Toronto area during my presentation on “Managing Offshore IT Outsourcing Projects”

The organizers, PMI’s  Greater Toronto Information Systems Local Interest Group, brought their  Project Management expertise to the fore in coordinating the logistics and organization. Right from the time my proposal to speak was accepted, Ed Streich did an excellent job of keeping me updated of the event and logistics.

One of the more interesting questions was on "cultural impact" and SLAs: whether the varying business practices and culture in different countries impact the definition and enforcement of Service Level Agreements in offshored IT projects.

I will not claim to be an expert on the legalities of defining SLAs but the significance of having a common understanding of the project tasks and deliverables cannot be undermined. Defining and ensuring adherence to Service Levels is among the more critical aspects of governance that Program Leaders focus on.  The adherence could be looked at from various dimensions including conformance to Master Services Agreements (MSA) and individual Statements of Work (SOW). Project Managers typically don’t work in silos; they leverage the strengths of the subject matter experts and others in the organization and team. This holds true of the activities in defining SLAs, ensuring compliance with the terms and conditions, and in getting a successful sign-off of the work-products delivered.

Typical reasons for negation or renegotiation of SLAs include things that are “assumed.” Case in point: aspects of QoS -- Quality of Service, a.k.a Non Functional Requirements -- are sometimes overlooked because one or the other party (either the offshoring or the service delivery team) “assumes” that the requirements are “standard.” One could argue that good requirement gathering and definition would also address and resolve such ambiguities around functional and non-functional requirements. But what if they are not resolved….and the ambiguity impacts the SLAs of the end deliverable? Needless to say, this is a challenge that many IT project face, and not really specific to offshoring projects alone…. But offshoring can magnify the impact of such “gaps” in requirements, a “gotcha” that Offshore PM’s need to watch out for.

Bottomline: Work done by teams halfway across the globe have a way of exacerbating challenges too…hence the need for better governance and management.

ps: Drop me a note and I will be glad to share a copy of my presentation.

Posted by Mohan Babu K. at 12:34 AM | Permalink | Comments (5) | TrackBacks (0)

Prof Ernie Ferguson recently invited me to speak with Graduate Students of M.S. in Applied Computer Science at Northwest Missouri State University. Given that I am currently in Toronto with other travel and work schedules, we decided to leverage Videoconferencing (VC) for the session on Project Management...for today (15th Nov)

Thanks to VC gurus at both ends, the session went smoothly without glitches.

My presentation was primarily focused on topics on offshoring and managing Globally Distributed Projects from my Book. I tried to keep the session interactive and was pleasantly surprised to see some good questions around Communication, managing across geographies etc.

My only regret? I didn’t realize that there was a technical hard-stop on the hour after the session started. We were delinked after exactly 60 minutes…before I could formally conclude. I guess that’s the way it goes.

It was interesting to note that of the 41 new graduate students entering the M.S. program this fall, 38 are from India. Prof Ferguson indicated that there are about 80 students in the program, and most are from India, a few from Korea and the rest from the U.S.

Indian students, traveling halfway across the globe to an American University, to learn the intricacies of managing and working with global teams, perhaps aspiring to join global companies like Infosys… the world is flat indeed.

Ps: …Tomorrow I will speak on offshoring and globalization at Greater Toronto Information Systems Local Interest Group of PMI.

Posted by Mohan Babu K. at 12:18 AM | Permalink | Comments (0) | TrackBacks (0)

One of the key aspects of offshoring is the need to manage teams across cultural and geographic boundaries. In a recent article “Managing Multicultural Teams” in Harvard Business Review, the authors [Jeanne Brett, Kristin Behfar, and Mary C. Kern] delve into intricacies and challenges of managing multicultural teams.

They begin with a topical case study on Offshoring IT by highlighting “When a major international software developer needed to produce a new product quickly, the project manager assembled a team of employees from India and the United States”

However, as I read through rest of the case that talked about how “from the start the team members could not agree on a delivery date for the product. The Americans thought the work could be done in two to three weeks; the Indians predicted it would take two to three months. As time went on, the Indian team members proved reluctant to report setbacks in the production process, which the American team members would find out about only when work was due to be passed to them.”  In their analysis, the authors agree that “Such conflicts, of course, may affect any team” but conclude that “in this case they arose from cultural differences”

This being a researched case study, the authors obviously know much more about the specifics. However, from my observations in the field, it sounds like a worst-case scenario… as the authors cede “The manager became so bogged down by quotidian issues that the project careened hopelessly off even the most pessimistic schedule–and the team never learned to work together effectively.”

Though I have seen my fare share of offshoring challenges and issues, cases like the one illustrated are exactly what Offshoring Project Managers work hard to mitigate. Experienced offshoring managers  work hard to take steps to mitigate the risk of such cross-cultural challenges leveraging the best practices in the industry and their organizations (Here I am not talking just about Infosys’ practices) 

In addition to the four strategies highlighted by the authors – Adaptation, Structural intervention, Managerial intervention and Exit – I addressed the challenges and approaches as pertinent to IT Projects in the chapter titled “Managing Global Workforce” in my book. The three key dimensions I examined include:

• Cultural Aspects
• Technical Aspects and
• Human Aspects

For that chapter of the book, I also reached out to experts in the industry, including Deena Levine who graciously provided a section on “Common Sense for Offshore-On Site Team Relationships… …but not always practiced!”

While there is no cookie-cutter approach to address the challenges of working with teams across cultures, managers can definitely leverage some of the best practices, tools and techniques available.

Posted by Mohan Babu K. at 09:59 PM | Permalink | Comments (0) | TrackBacks (0)

So is every technology or business endeavour. One need to recognize the risks and learn to mitigate their impact.

It was interesting to see James McGovern’s comment on a recent blog entry of mine, chiding me “Would you be willing to show more integrity by also talking about what are the pitfalls of outsourcing?”

You bet James. Risks and Rewards, as any business and technology leader would agree on, are two sides of the coin.

There are inherent risks in offshoring that few of us can really shy away from. Right from the second chapter --["Planning Offshoring"] of my book on Offshoring, I start addressing aspects of offshoring risk. The way I look at it, organizations need to identify and evaluate offshoring and management risks early to avoid surprises and pitfalls.

In my research, I also quote from analysis by gurus in the industry. Case in point is the analysis by Ralph Kliem, who in his Information Systems Journal paper ["Managing the Risks Of Offshore IT Development Projects"] states

‘Offshore outsourcing of IT development projects does not eliminate risks. Instead, it combines new risks with existing ones often associated with onshore projects. Project managers must recognize that these offshore projects will likely require even greater management of risk due to the unique challenges posed by geographical, cultural, and other differences. Otherwise, the gains attributed to offshore outsourcing of these projects will not be realized, and the chances for failure may be augmented.’

In the “Risks of Offshoring” section of my book, I attempt to address several categories of risks inherent in offshoring. Quote: With offshore development, risk management assumes a renewed focus. Risk in the offshore development model is contributed by three major sources:

• Organizational Risk
• Technical Risk
• External Risks

I invite you to critique the “Risks of Offshoring” section in the section of my book where I address these risks in detail.....and more importantly, I attempt to address some of the mitigation strategies.

Ps: my employer does not shy away from discussing risks of outsourcing and offshoring either. A couple of links published on the Infosys website.
GDM Risk Mitigation
BPO Risks and mitigation
and ….lots more research and case studies available;  if interested drop me a note.

Posted by Mohan Babu K. at 09:58 PM | Permalink | Comments (4) | TrackBacks (1)

I am looking forward to speaking with managers and executives in Toronto next week during the Networking and Workshop Meeting. It is being organized by PMI's  GT ISLIG.

More about the event and my presentation at online at gtislig.org

Posted by Mohan Babu K. at 09:18 PM | Permalink | Comments (0) | TrackBacks (0)

You may be interested in my review of ACM Job Migration Task Force report "Globalization and Offshoring of Software." Review was published in ACM Ubiquity today.

Posted by Mohan Babu K. at 05:41 PM | Permalink | Comments (0) | TrackBacks (0)

Though there is an element of mutual collaboration in identifying the “right” processes and methodologies, clients generally prefer Offshore Project Managers and their teams follow their organization’s development paradigms and processes. No arguments here, since the client is going to own the software and solution, right? Well, what if the client’s preferred process is the Agile Software Process?

You may not be alone in wondering if we are talking about the right paradigm here: As more than a few bloggers have commented in the cyberworld: “Agile Offshore - sounds like an Oxymoron.”

As offshoring practices matures, clients are beginning to ask offshore teams to work with  processes that go beyond the classic waterfall or SDLC. This is especially true for projects with critical time-to-market pressures or in situations involving specialized product development cycles and where requirements are iteratively evolving.

And this is where it is interesting to see Software Gurus take the lead. I have been an admirer of Martin Fowler’s work and thought leadership, and it is interesting to see him succinctly articulate his experiences in “Using an Agile Software Process with Offshore Development.” Fowler’s essay makes for interesting reading and I will not get into all the points he articulates.

Though the points Fowler raises are probably true for most offshoring projects and not just the ones using Agile processes, there are a few that stand out:

• Have Each Site Send Ambassadors to the Other Sites
• Use Contact Visits to build trust
• Use Short Iterations
• Use an Iteration Planning Meeting that's Tailored for Remote Sites

More practitioners are taking a stand on offshoring agile development. No, I am not talking just about Infosys’s viewpoint. Bala’s article on “Agile Offshore Development: 10 Ways to Make it Work for Your Organization” in Agile Journal makes for an interesting read. 

Am I a proponent of using Agile Software Process with Offshore Development? Well, I will just take a leaf from Mr. Fowler’s essay and just state “Among all these differences my point of view is clear: I'm sitting on the fence!” [And no, I did not dwell on Agile processes in my book though I may review the topic for the next edition]

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

IT Project Managers, especially those in the offshoring space need to observe trends shaping up in the industry, especially the ones that impact their clients. [consulting 101: try to stay a step ahead of your clients and you can “wow” them]

One such trend is the evolution of Open Source development paradigms, especially the proliferation of open source tools and technologies. A couple of years ago, in my avatar of a technology columnist, I had written about “Managing open source projects.” I also examined the topic in further detail in my recently published book when I examine aspects of “External landscape and Offshoring Management” that Technology Managers need to watch out for.

Given this landscape, I shouldn’t have been entirely surprised to read the Wall Street Journal report this week that Microsoft will announce a partnership with Novell and will help promote Linux. However, the article and subsequent articles in the media caught my attention for several reasons. For instance Daniel Lyons in Forbes.com article quotes Larry McVoy, former Unix engineer at Sun Microsystems who was deeply involved in the creation of the Linux kernel stating  "But its (Microsoft's ) infrastructure code and its applications are great. I would pay twice as much per seat for a combined Linux-Microsoft operating system as I would for pure Microsoft."

Now, I don’t bring up the topic to debate the merits of Microsoft or Linux operating system but to highlight the dynamics that IT managers will have to face. Especially as CTOs and Technology Leaders are starting to examine the impact of this move.

Project Managers have an opportunity to be ahead of the curve by learning a few basics of Open Source management, licensing in the corporate context and some overview of the popular tools and players in the space.

I could go on….but you get the drift; right?!

Posted by Mohan Babu K. at 11:26 PM | Permalink | Comments (0) | TrackBacks (0)