Offshore Management Framework: The key to managing outsourced IT projects across time, distance and cultures.

« April 2007 | Main | June 2007 »

May 31, 2007

Offshoring IT Services: Book royalty etc

A few weeks ago I received a royalty check from McGraw-Hill for my book “Offshoring IT Services” which was published a little over a year ago. Just after its publication, I had blogged about my experience in getting a book published, and since then I continue to reflect on the topic, and also muse on some of my observations on this blog.

How successful was the book?  Well, let us put it this way: it did not get on Amazon.com (or any other) “top 10” list. My publisher tells me it is not a ‘bestseller,’ which means it was probably destined to be in the ‘Long Tail’ of technology and management books. The reasons are not hard to fathom:

  • Prior to its publication, I was just another Indian-born techie with a viewpoint on offshoring. Now, Bill Gates and Andy Grove were celebrity technocrats much before their books were written; their books were bound to be a hit; right?
  • The audience for a book on offshoring is globally dispersed and is an extremely small niche. Reaching a niche like this is expensive and time-consuming. Hence the publisher didn’t think it worth the expense to market the book actively. Nothing wrong here, it was a purely business decision.
  • Reaching out to the target audience, skeptics among technocrats and IT professionals is especially when ‘thought leaders’ outside IT offshoring industry – like Alan Blinder  and Lou Dobbs  - continue to challenge the merits of globalization, and also continue to get a lot of air-time in the media. This despite the fact that the practice of offshoring continues to mature, and managers and executives are starting to learn the intricacies of global sourcing. While some technologists and line-managers continue to ponder over the impact of sourcing on their lives and careers, they realize that the practice is here and they need to learn to be a part of the global marketplace.  Bottomline: few prominent IT leaders and technocrats – outside the services sector – are vocal about the need for managers to learn and observe the best practices.

My takeways:

  • The publisher tells me that the first print-run is ‘almost sold out,’ which is great for a first-time author.
  • The book received some good reviews from a few in the media, some academicians and bloggers.
  • Though the book encompassed my personal observations and viewpoints, Infosys’ corporate marketing was gracious enough to promote the book online on the corporate website. Account managers handed complimentary copies to select clients.  

Well, before you ask me, the royalty - in absolute dollar terms: it was in Indian Rupees - was not much to write home about; paraphrasing the famous Mastercard advert:

There are some things (a book-royalty) money can't buy..
… for everything else there's MasterCard".
The sheer
egoboo of seeing one’s thoughts in print, reviewed and commented on? …priceless.

May 27, 2007

Offshoring Consultants who can also sell

Most of us in the software services world - whether in the technology consulting, application development or program management space - are acutely aware that we are also continually selling something: we are selling our skills, solutions and competencies, essentially sending a message to ‘clients’ that we [and our organization] can deliver on the requirements and ideas.

Now, selling has two sides to the equation: the client (or someone) should have a need and be willing to ‘buy’ the services that you offer to sell. Identifying such white-spaces in their requirements and helping them fill the gaps with your offerings for a win-win relationship; well, this is business 101, right? However, selling and buying software services is not always as explicit as the marketplace for fungible products. Sometimes, the ‘selling’ also involves helping the client’s stakeholders articulate the demand to her stakeholders [not sure if I would call this ‘upselling’]

On similar lines, Michael Cage blogs “Clients choose the cheapest price option because you haven't given them a compelling reason why it makes sense to pay more.”

Why am I musing about this? Recently a colleague - let’s call her Jane - was working documenting effort estimate for project for a client onsite. In her current role, Jane was also filling-in for the client’s project-manager who was away on vacation and during a meeting the (client’s) IT director she was reporting to asked her to help with budgeting ‘burn rate’ for a few projects for the next quarter.

Now, most Project Managers are comfortable in such projections and cost-budget analysis but here the situation was a bit unique. Jane was comfortable in budgeting ‘revenue’ for proposals and RFPs that her Infosys teams regularly respond to and realized that the client’s ‘burn rate’ is the other side of the equation.

Jane also realized that with this request, her perception of stakeholders was getting enlarged and had to work hard to mitigate any conflict-of-interest. In case you are wondering why there would be a “conflict-of-interest?” Well, Infosys, like all other companies in the world, is a business: which essentially means that it needs to generate revenues with positive margin on business transactions, in this case services we render, and projects we execute. Clients accept that as a matter of fact but with a caveat: the dance of ensuring lower margins for the services vendor (Infosys), essentially translates to a higher cost saving for them. Interestingly, Mike McLaughlin blogs about a related challenge when he advices consultants to "Take a Deep Breath before You Answer These Questions"

This is not a really unique situation. Many of us who work with clients on a long-term basis get embedded within the organizational eco-system and begin to ‘think’ for them, with the implicit understanding that the consultant will build a mental ‘Chinese wall’ 

Are Jane and her ilk valuable to Infosys…and our clients? Absolutely!

Case in point: at a recent business forum, I was talking with an executive from a service firm (a competitor that will go unnamed). His firm seems to have challenge in grooming folks like Jane: technology consultants who are articulate and can speak technical and business language with equal ease, and can help with quick turnaround of proposals and showcase the organization’s credentials at all times.

He rhetorically asked if I knew folks who would be interested in joining his company. Well, if I knew of such folks in local markets where we operate, I would be hiring them myself, wouldn’t I?

May 25, 2007

The business of offshoring and the "Long Tail of labor"

My earlier post on IT-Business/Domain Knowledge in an offshoring context generated a fair number of insightful comments. Chetan and Michael debate the nexus of IT-Business/Domain Knowledge and business agility. As I was reading these comments, I began reflecting on the other similar debate on the business of offshoring itself, more specifically in the context of Chris Anderson's bestseller “The Long Tail” that I got around to read recently. Taking off from Anderson's popular Wired Magazine article, the book expounds the idea that “some businesses, like Amazon and Google, can make money not just on big hits, but by eating the Long Tail. They can live like a blue whale, growing fat by eating millions of tiny shrimp.” [Tim Wu: The Wrong Tail How to turn a powerful idea into a dubious theory of everything.]

While the idea of finding a Long Tail patterns resonates with most intuitive thinking, Anderson perhaps stretches the argument when calling offshoring the "Long Tail of labor." My thoughts resonate with that of Theodore Kinni who wrote how “Anderson can stretch his long tail too far, declaring that offshoring is the long tail of labor, terrorists the long tail of warfare, and microbrews the long tail of beer--without expanding on those claims. But if you're selling anything that can be aggregated, such as books, music, film, software, and digital products that don't need distribution centers, The Long Tail could be your guide to becoming the next big dog.”

However, not everybody finds this idea of extending “Long tail” to offshoring a bit cursory. For instance Justin Brister blogs “One obvious solution is the use of Offshore organisations; by acheiving labour cost reductions, it is possible to do more with less budget. This makes it possible to develop solutions for markets that before-hand would have been uneconomic to service.”

Though I don’t really buy into the idea of offshoring as the "Long Tail of labor" there are Long Tail patterns in the business of offshoring itself, specifically Long Tail of large clients. Large companies (read fortune 500 or global firms) typically engage with large software service firms to source key projects. After engaging, however, a pattern of long-tail begins to emerge. For instance, if the company engaged with Infosys (or other large service firms) for a large SAP rollout, they typically realize that they can leverage our services for the System Integration or SOA definition….and while doing that, also realize that we have pockets of expertise in esoteric technologies, say tuning Google Mini for enterprise search. 

Now, you can probably argue that this illustration is not really about the “long tail” of offshoring but more to do with up-selling or cross-selling . well, this is similar to Anderson trying to force-fit offshoring to the "Long Tail of labor," right?

May 21, 2007

Offshoring and Delegation

I came across a blog titled “Is Offshoring the Same as Delegation?” where Ron suggested that  outsourcing and offshoring is just another step on the delegation path. Ron goes on to quote Professor Stephen Gillers of NYU Law, a co-panelist and recognized ethics expert who explains that "with appropriate supervision and disclosure, outsourcing and offshoring are ethically permissible”

This is a very interesting notion since outsourcing is all about extending an organization’s capabilities by reaching out externally, and increasingly globally.

In the presentation, Ron makes an argument for delegation by highlighting how delegation is

  • Common once a firm has more than a few lawyers
  • Delegation of legal and non legal tasks.

Though the presentation and Ron’s views focus on outsourcing and offshoring of legal work, it could be other work tasks that can be decoupled and be done ‘offline.’  This is also the argument that Prof. Murugesan and I made in our Cutter IT Journal paper focused on “The IT Innovation Process: Necessity or Oxymoron?”  Cutter has a Special Offer (I guess it is for a limited time) making the issue available online.

I look forward to comments and review of the writeup, and will be glad to continue the debate on this blog.

May 16, 2007

Grief, celebration and the human face… of offshoring

When I read the Cutter Advisory (reprinted  below) by Dwayne Phillips titled "Celebrations," I began to reflect on the softest underbelly of software services: its people; and also on the ‘human’ interactions that touch us ........ even hardened technologists and managers.

Phillips says how we should not -- must not -- ignore events in our lives. . . . Stop work. Grieve.

In an offshoring context there are moments where “Stop work. Grieve” alone does not suffice. 

A few weeks ago, I was talking with a colleague of mine who had just rolled off from a project for a client in California where his team had to come to grips with some human grief. News came one evening that a colleague’s father in India had passed away. Unlike a regular bereavement situation, his manager couldn’t stop at sharing the grief and signing off on the requisite leave. He had to ensure that the well oiled ‘organizational emergency’ machinery kicked in: calls to travel desk, emergency flight bookings to Delhi etc etc. Smoothening the logistical challenges and ensuring an early flight for the colleague was a part of the grief sharing process. Other colleagues helped pack the bags and drove him to the airport.

 

And only after that the other part of the logistical ‘challenge’ was addressed: informing the client and account stakeholders that a key member of the team would be unavailable due to Force majeure (not really sure if the term applies in this context?), ensuring business continuity etc.

 

Though the example quoted above is rare, other ‘human’ challenges, unique to offshoring do surface occasionally. Most service firms have developed policies and guidelines to ease the pains of expatriate/international staff but even an excellent policy and flawless execution is meaningless without the ‘personal touch.’ As Phillips puts it succinctly “He survived his wounds and grief to celebrate. I urge managers to do the same at work. Grieve with your coworker. Grieve personal tragedies and professional setbacks. … And celebrate as well.”

 

********************  "Celebrations" by Dwayne Phillips ********************

I attended my son's graduation from college yesterday. That should be an unqualified joyous celebration, except my son graduated in engineering from Virginia Tech University, in Blacksburg, Virginia, USA. Twenty-five days earlier, a student killed 32 people on campus and then killed himself (see http://en.wikipedia.org/wiki/Virginia_Tech_massacre).

There was joy and celebration at the graduation ceremony, but there were many tears as well. I cried; my wife cried; all the people sitting around us cried. As one commencement speaker put it, "You are the most famous class in the history of Virginia Tech. You didn't seek this fame, but it came upon you."

Sadly, I wrote about something similar some five years ago when the "DC Sniper" was shooting people in the Washington, DC, USA, area (see " Working During a Community Crisis," 20 November 2002). Many of this weekend's graduates lived through that while in high school.

Virginia Tech awarded degrees posthumously to those students who died. Honors were given to the faculty and staff who died. The most emotional moment for me was a presentation to a widow of a young faculty member.

Terrible events happen sometimes in our lives and the lives of our coworkers. As managers, we try to keep the workplace working even though work is the last thing on anyone's mind. How do we do that? How do we keep our unit productive without being an insensitive monster?

The answer is: we don't.

We should not -- must not -- ignore events in our lives. As one colleague told me years ago, "We will not leave any bodies on the floor. We will delay things so that we first attend to what has happened." When he said that, he was speaking of addressing strong emotions in the workplace, not physical bodies, but his advice applies here.

Stop work. Grieve.

Celebration is a part of grieving. The vast majority of Virginia Tech students and faculty were not harmed physically on 16 April. They continue to live. They celebrated during part of this past weekend. The celebrations send them into the rest of their lives instead of leaving them stranded in the sadness and horror of the tragedy.

Most of us ensure that we celebrate at work to mark our accomplishments. We deliver a product early -- we celebrate. We solve a difficult technical problem -- we celebrate.

More of us should celebrate at work when things don't go so well. A project is canceled because of continuous schedule delays -- let's celebrate because we are no longer saddled by it. A project is canceled because current technology provides no method of building the product -- let's celebrate because we no longer beat our heads against the wall in vain. Celebrations during those events can help us to move forward instead of lamenting what might have been for years.

At the engineering commencement at Virginia Tech, one student climbed the stairs, walked across the stage, received his diploma, and walked back to his seat. His graduation above all others brought thunderous applause, a standing ovation, and tears. What was different was that he needed a crutch to make his walk. He was shot on 16 April but survived his wounds to graduate.

The thousands attending learned of this the same way I did, through a flood of whispers swarming the building, "He's a survivor."

He survived his wounds and grief to celebrate. I urge managers to do the same at work. Grieve with your coworker. Grieve personal tragedies and professional setbacks.

And celebrate as well.

-- Dwayne Phillips

This excerpt is reprinted with permission from Cutter Consortium. It appeared in the May 16, 2007 Cutter IT E-Mail Advisor. All rights reserved. Copyright 2007.

May 11, 2007

Is IT-Business/Domain Knowledge [While Offshoring] overrated? ... Continued

Among my recent blog posts, the one asking ‘Is IT-Business/Domain Knowledge overrated?” generated a fair number of comments, as is to be expected. After all, “Business IT Alignment” is the holy grail of management thinking with even academic and business media spending reams of newsprint to the topic.

My question was rhetorical as I was trying to draw on my observations and past experiences in the field. Vikas Ohri comments “Knowing domain helps to break communication barriers, appreciate the business need, relate to impact of your system in the overall scenario even when it is not explicitly stated….. Analysis of failed IT programs does provide some insights... ”

Similarly, Robert Rojas comments “It sounds like you're saying that a shortage of domain expertise means it should not be sought after. … Just because the expertise is not there does not diminish its importance.”

Ram posted a comment asking if I might want to take up "common" domains like Banking or Retail, argue the same case and see how much sense the article makes in that context. Therefore, let me illustrate my thinking with another example.

In my past life (before joining Infosys to begin my offshoring odyssey) I spent a few years working with a large Telecommunications giant in the American mid-west. The systems my group was focused on was to do with managing “Access Service Requests” (ASRs) which are industry standard ‘forms’ used by Telcos to communicate network access details with each other. ASRs are complex forms defined by the Ordering and Billing Forum (OBF), used by long-distance carriers to communicate requests with Local Exchange Carriers (LEC). In the broader business context, my company had to pay the LEC for each network request and would get paid by billing customers.

The “IT” part of the world involved managing complex databases, UI, business rules, workflow and systems to enable network engineers and operators to request access for customers and to ensure that the ‘end to end’ connectivity of customers, switching, networking etc would be transparent to everyone involved. The systems had taken years to design and develop and had to be dynamic enough to provide for periodic changes coming from OBF : The representatives met every six months to define new set of interchange standards, which would require modification to the ‘forms,’ in turn the systems - workflow, business rules and 'logic' - at different ends (our Telco, LECs etc). A process of continual change, if you will.

Even after spending years at the Telco, I will not claim to be an expert on ASRs or OBF or even the systems that fascilitate the interchange between the Telcos. The point I was trying to make in my earlier blog post was this: It took me about 5-6 months at the Telco to understand the jargon -- the three and four letter acronyms -- and figure out the different pockets of knowledge. The ‘business’ folks in the team were either folks who had risen from the ranks of call-center or were network-engineers from the field. The ‘years’ of business knowledge many of them brought to the table was primarily with regards to the fluency with which they could utter the jargon, especially as the OBF standards were also constantly changing. For instance, this was the time DSL technologies were going mainstream and standards for DSL interchange were being incorporated into ASRs. The marketing folks at the Telco were really wired-up (pun intended) on ensuring that we lead the pack in providing DSL packages to our customers. The ‘business’ folks - the technicians and network engineers in the field, call center folks and others – were also learning about DSL, just as we were coming to grips with intricacies involved in providing for access to it.

Now, let us switch gears and extrapolate this as an offshoring scenario. Following thoughts/queries come to mind, based on the comments my earlier post generated:
a) The focus of the IT team was on re-engineering the ‘system’ (UI, Databases, middleware, interfaces etc) to accommodate the new business channel, in this case DSL.
b) The same ASOG guidelines (300/400 page reference manual) that the business was studying, was available to IT. The ‘business rules’ and intricacies also were documented in it.
c) In this scenario, given that both the ‘IT’ and ‘Business’ folks were learning to come to grips with implications of DSL technology, could the IT component -- re-architecture, design, development and testing -- not be done offshore?
d) The Telco's team was already geographically distributed. Business was located in Virginia, IT in Colorado and Texas with users all over US....so I am guessing that having another IT team a 'few more' time-zones away would not be a real challenge
e) For the argument, assume that 'normal' interaction and communication between business and IT folks continue, using tools and techniques used in managing globally distributed teams.

This argument is by no means rigorous or conclusive, so let the debate continue.

May 8, 2007

Random musings on Legacy Modernization: Part 2

In my previous blog I was musing on modernization. Here are two scenarios of 'legacy modernization' I got involved in recently:

Scenario 1: A 50 year old manufacturing company with IT systems dating back over three decades. After the company embarked on a roadmap to migrate some of their homegrown, mainframe based MRP (Manufacturing Resource Planning) systems to a commercial package, they got bought out. ...And surprise? A renewed focus from Head Office on cost cutting and offshoring, and that’s where my consulting team got involved.

Scenario 2: XYZ.com, the online aggregator of hi-tech books and research data that I blogged about a few days ago. The need here is to ‘modernize’ the homegrown systems developed in the dot.com heyday, about eight years ago.

The examples span industry verticals and in scenario 2, the technology is not even truely 'legacy' but both are cases of “legacy modernization” nevertheless. And this is where one finds that discussions on the topic get nebulous, involving multiple dimensions: 

  • Why: Why ‘modernize’? Is it the cost of maintenance, is it the lack of skills to maintain systems? Is it performance or deprecation of support by systems vendor? …or any other reason? [Ref: Who are you calling 'legacy'? by Jason Stamper and SOA – Same Old Architecture]
  • Source Platform: Assuming you have decided to modernize. Is it a monolithic system you are migrating from or is it a portfolio of disparate technologies.
  • Target Platform: Do you intend to build or buy? if so how?
  • What is your budget? What are the timelines?
  • Who is going to do it? Will you leverage all of your IT staff or do you also intend to seek external experts to help?

No, this is not a bullet-point list that you can use for your roadmap but just a few eclectic ideas you must be thinking about. And in case you are wondering about my advice to clients in Scenario 1 and Scenario 2…well, you just will have to ping me, wont you?

A few interesting writeups on the toic:

May 6, 2007

Random musings on Legacy Modernization: Part 1

Utter the term ‘legacy modernization’ in any technology forum and eyes will light up. The topic is bound to generate animated discussion among techies, architects and IT managers alike. Of course such discussions among IT managers and consultants have a tendency to get polarized: consultants will probably have dollar signs gleaming in their eyes while IT managers try hard to defend their portfolio, arguing “why fix what’s not broken”

Services companies thrive on providing innovative modernization solutions, while software companies try equally hard to pitch upgrades to their own legacy platforms. And then there is the whole mainframe-to-(whatever) discussion that periodically erupts.

In a sense, legacy modernization decisions are like Americans and their cars. Folks get tired of their cars periodically and like to trade-in for something jazzier, new models with better features etc etc. The need is greater after a ‘life changing’ event: graduation, marriage, addition to a family etc. Car dealers have two goals when dealing with customers: depressing the price of their trade-in as much as possible while inflating markup/MSRP on new cars. The analogy between trading-in an automobile and legacy modernization projects is uncanny. Organizations also go through ‘life changing’ events periodically, growth in the vertical, Merger & Acquisition etc. Like auto dealers, consultants may have a vested interest in proposing lower salvage (read code/logic reuse) of the legacy system while prescribing jazzier new technology solutions. In both cases, the Car buyer (IT Manager) and auto-dealer (consultant) try to strike a balance between their diverging goals.

Where the trade-in automobiles anology diverges from legacy modernization is that the Information Asymmetry is skewed towards the buyer. The manager knows her IT portfolio better than most consultants would…so one is bound to wonder who is the buyer and seller here? And more importantly, how many IT leaders leverage the Information Asymmetry to their advantage?

Why am I musing on legacy modernization? Because many of the recent offshoring initiatives I have been involved in have a strong 'modernization' component. More about it in my next blog

Subscribe to this blog's feed

Infosys on Twitter