βTechnology Consulting Group Logica Australia

This post is a compilation of the email discussion within the group about insourcing, outsourcing and the dangers of the latter.

Kelley Johnston:  The article in this link http://www.guardian.co.uk/feedarticle?id=7372581 mentions how Logica won significant business in the UK against an Indian outsourcing firm, and was used as an example of how the UK in general appears to be drifting away from the off-shore model. 

Personally I think off-shoring is ok where indicated, due to a belief that good brains come in all sorts of packages. But it’s a see-saw balance — if you offshore development, you need to invest in local B/A skills to ensure your requirements are top-notch. If you offshore a call centre, you need to ensure commonality of culture with regard to how you represent your firm to the clients. If you in-shore everything, you have a hard time competing on price. 

And price is definitely important, the best plans fail if you can’t sell them. But price seems to play only part of the picture, as the off-shore firms have matured to the point where they’re experiencing the same talent shortages their counterparts in the west have been suffering. Communications is suffering the tyranny of the time zone, and this makes using agile methodologies, so useful for improving customer satisfaction, a little hard (or quite expensive) to implement. Price models are under pressure from time-shrinking tool sets like Sparx and Iron Speed so cost of coding is becoming less of a factor. On the other hand, India has new graduates who have studied legacy coding skills, and it’s hard to attract grads in the west with the promise of a career in COBOL or RPG and there are a lot of dusty decks out there.

It’s a difficult mix of factors to juggle, and I’m sure that if anyone had a foolproof method for measuring the risks they’d be featured on the cover of TIME magazine.

So I’m curious — in our collective opinion, what are all the factors that belong in a decision-maker’s Bayesian model for determining the correct metrics to balance off-shore vs. on-shoring?

Vincent Dermody: Kelley, Be careful of the can of worms you open J To give context to my following comments, I spent 3 years in Intel bringing up an Agile Outsource capacity run out of Russia, and prior to that I did a lot of work with Orygen near shoring from London City to Ireland and on sourcing to Bangalore.

As I see it the biggest mistake in outsourcing is bagging it all as one. There’s sensitivities all around, but there is huge differences in what you’ll get out of different cultures. If you want a button down  ITIL operation then Bangalore is your place. However if you want innovation and agility then St Petersburg or Nizny Novograd is your place. 

Another mistake is the play on the cost parts of a projects. The old premise was that the key cost are is development, we’ve all seen the parabolic graphs that skew between design and deliver.

The fact being ignored is that flaws in planning and design come out in the delivery, so the actual key failure area is nearly always upstream from the delivery. An analogy, a good outsource agency is like a good driver, drives at the legal speed limit and takes no unnecessary risks. The fact that the driver has incorrect directions means that they will get to the wrong place safe and sound and without a speeding ticket.

The original purpose for outsourcing was cost per capacity. Now that there is a point of inflection approaching, i.e. cost equalisation is happening, then the cultural aspect kicks in. Why is Indian development better? Why is Russian Delivery better? This was obvious in the Congress I referred to last week. There was two presentations from Indian outsourcers trying to reposition themselves in areas outside their traditional area. One presenter tried to demonstrate how he planned to use ITIL techniques to instil innovation in organisations. It was like something out of Orwell, totally focused on throughput of innovation points (i.e. ability driven innovation as opposed to need driven).

The second one was a pitch to outsource the Project management function. Consider this, the key point of a PM is to add the soft skills to the logic of a project. The bits that don’t need on site soft skills are better off automated in a collaboration tool than flung to some distant shore as outsource. 

My money is on India getting challenged and Russia and eastern Europe making grounds in the innovation space (remember these guys tick tacked the US during the cold war, they know how to innovate. TRIZ is a USSR product and is the book on innovation in my view).

There are general points to consider , in all aspects of globalisation, especially considering the possible reversals that carbon and oil economy constraints may bring. Is a company at risk by degrading its own specific skill set due to outsourcing, when in 3 years Bangalore may say ” Skill XYZ is no longer feasible, sorry go elsewhere” .  A context example, the tailoring and cloth manufacturing industry in Europe has lost two generations of apprentices to Chinese globalisation. Now the EU couldn’t stop the import of Chinese clothing as there is no longer an internal capacity.  What’s Barclays gonna do when Cobol is a premium skill alongside Java and SAP? Its back to our old friend Supply and Demand.

To me success and failure is all done and dusted in the upstream, i.e. the planning and architecture area, whether the delivery is via outsource, code gen tools, or local coders. The play is in high quality portfolio and architectural management, delivered on collaboration technologies which can be extended to any delivery vehicle. (Ok that last line was me pitching.. awh well might as well get with the competition).

In summary, ignoring cultural strengths and weaknesses is a mistake, and to deplete internal skill sets for the quick cost win of outsourcing is extremely risky.

Kelley Johnston: I agree completely, and I’d like to add that what you described points out the problems inherent in the development of silos of risk.  The Board is responsible for managing risk at the corporate level, but not always at the broader economic level where it impacts the health of the economy of the country or region itself.  This may be because boards in the west need to report short term success or they face a reshuffle of the executive team until the numbers look better.  Strictly business.

So this describes two silos of risk, i.e. corporate and government.  Perhaps they should be seen as a continuous risk landscape, but they’re treated as individual and independent because, well, the governance of both can only be concerned with their own spheres of influence.

What other silos of risk can be identified?  We can think of global concerns such as threats to stability of a region or the global ecosphere, and down below the corporate level where architects define risk mitigation tactics for customers.  Ultimately it’s all one continuous risk matrix, but it’s human nature to deal only with what you can deal with.

However, one company’s risk is another company’s business opportunity, so it’s worth exploring this a little further.

Risk silos tend to develop around generally-perceived areas of threat.  Most of the news we read in the business trades ultimately concerns threat of shareholder dissatisfaction, and the response to that is directed at the executive team.   For a sales exec they respond to the risk of not getting their numbers in.  A delivery team manages the risk of contract fulfilment and milestone payments,  building facilities manage the risk of not meeting OH&S requirments, and so on it goes from top to bottom of the food chain.

I see from your English textiles example that there appears to be another risk silo to manage, that of managing the risk of future revenue streams by ensuring we do not undermine our future capabilities.  Globalisation is supposed to bring specialisation, but by abandoning all areas of low return today we do risk missing out on the next technological pendulum swing.  Bill Gates recently covered this in an apperance before a US Congressional committee (http://www.microsoft.com/presspass/press/2008/mar08/03-12MSUSInnovationLeadPR.mspx) where he voices some very real concerns about borrowing from the future to fuel today’s progress.

We have to develop tactics to ensure we have a revenue stream today, that’s certain, and that’s good management.  But for a true strategic risk management, that is ensuring we have a revenue stream well into the future, we do need to add the factor of preserving our capability for the long term into the spreadsheet.   Anything less is like planning your retirement by investing heavily in Tattslotto.  It might work, but the risk picture is imbecilic.

Now, how can we turn that risk into a business case?  And by extension, is there an opportunity there to identify that risk to our customers, along with a plan to manage it for great justice and revenue for all?  If we can identify it, we might be able to market a solution, and part of that marketing may need to be simply bringing the problem to the attention of our customers.

As a thought experiment, can anyone think up a fake press release that would present a Logica response to this risk from the future?  How would such a thing read?

Alexander Rivkin: Gee, this is really a can of worms. Just my couple of cents into the discussion which though takes it a bit sideways. All below is IMHO:

A quote from Terry Pratchett: “If you are not geography, then you are history!”

The thing with the skills outsourcing is that it complies with the “comparative advantage” rule of the modern economics which roughly states that one should engage only in the activities he can do better than anyone else and should not deplete resources for the activities that can be done cheaper and more efficiently somewhere else. <..>

Please note that while Bill Gates addresses three points on which the Congress should act to support innovation he still mentions immigration, as the US needs to borrow/steal outside talent, which does mean that America really starts losing its competitive advantage if it is forced to stay self-sufficient. This and other points indicate that the States may not have internal capacities for growing their own innovation talent. And this is what may be the problem with skills outsourcing in IT (I hope that I am not stretching the logic here) – by outsourcing lower level activities the West (here: those who outsource, they just happen to be in the West) deprives itself from the environment from which future designers and architects/innovators will come from. <..>

Bangalore trying to go up the food chain is normal – it is normal for systems/societies/business at some point to evolve and grow both in capacity and capabilities. Sooner or later the West will have to compete with Bangalore/Eastern Europe in the design and architecture space, because if there is not enough people with programming/development experience around today, where the future designers/architects/innovators will come from? The IT is a knowledge industry and the knowledge is learned by doing something and growing with the scope of the things done. There are definitely cultural differences between countries involved, quality, distance, security and time zone issues and I absolutely agree that they negatively impact Bangalore’s competitive advantage, but I guess people tend to learn… Remember the opinion about the quality of the Chinese made goods 10-15 years ago? Which leads to the question: should the West preserve the current skills in the name of the future development and competitiveness?

I think trying to preserve specific skills can be dangerous as the skills may never be needed while resources will be spent for maintaining them (like mothballing old weapons hoping to use them in future wars). <..> Since one can not have unused capacity for the name of the future as it goes against the business principles as highlighted by Kelley, <..> I think what one can do meanwhile is to preserve the knowledge. Note, I am talking about the knowledge, not the skill which to me means preserving actual people and capacities. And preserve the knowledge in a such way that it can be retrieved and relearned quickly and easily. <..> So the technologies/skills do not get lost – they may not be used, but the knowledge about them is there and to store it costs much less than employing someone just because of their old and rare skill which may not be used. <..> I guess that knowledge preservation is more applicable to the IT, rather to others, more machinery/manual skills extensive industries, but… (and I know that this is an old idea, but with a slightly different twist, so it is slightly more than just “knowledge management”).

<…>

Vincent Dermody: Alex, I agree totally …. I think

I did warn of the can of worms….

My opinions are based upon looking at Ireland as a  micro model of India, and look at the outcome. In the mid 80’s Ireland ramped up huge a IT profile acting as the outsource capacity for UK and Europe, usually under Guise of American Multis. Long story short, everyone got wealthy, cost of living soared, skill shortages etc etc. Now we have an overpriced economy servicing US and UK business being services by eastern European outfits. The fear is that US will realise that Ireland is just a middle man and go direct to Czech or Polish companies. In twenty years in Ireland Intel sprung no new products from Ireland, all innovation came out of Portland and Israel, neither outsource centres. So outside of the employment, net benefit to Ireland is zero, actually the downside is that cultural education took a back seat in the last 20 years while we produced a nation of IT workers. It’s no coincidence that the last Ireland Noble Literature was Heaney in early 90’s just before the boom.  This is from a country who produced 7 winners in Lit in the previous 40 years.

Another twist on this rollercoaster of global economics, the youngest age economy in 2025-2035??? US. Oldest ?? China. Reversal of one of the key drivers of growth in an economy.

Back to the day job,  our strongest pitch is going to be as the enablers of strategy, i.e. run the architecture and portfolio aspects, the “brain thrust”, leaving the back office stuff to the best case provider, where ever. Stay in the middle and out of the fringes!

Kelley Johnston: What a lovely can of worms!  Best thing to use for fishing.

At one major bank I noticed an interesting trend – there was a strong internal desire to have any development they could stuffed into Excel as “Macro development” (i.e. huge amounts of VBA).  Why?  Because they (line management, not IT) could contract someone locally rather than jump through the /definition/design/->Mangalore loop.  Their IT group had a policy of having software developed offshore due to the very real cost differential of paying programmers in Rupees, but the line managers really preferred being able to talk to programmers directly, and went around behind IT.   Although they had some successes with offshoring, for anything other than very large projects the overall C/B was razor thin and the waterfall workflow was, to be blunt, painful.  This led to some ah, interestingly bulky spreadsheet collections. 

They were highly portable environments though, and that didn’t hurt.  How else can you quickly port an application to another company outside your influence? Toss them a spreadsheet.  There’s a lot of precedent for going this way instead of SaaS (which is still new and not entirely trusted, mostly because it doesn’t look like a spreadsheet) and an awful lot of momentum for doing it that way.  As in “billions of dollars” of momentum. I may have mentioned this before, but there’s a disturbingly large amount of the world’s money living entirely on the humble spreadsheet.  There’s no question that a bespoke development would have been better for some of those apps, but their success criteria did not include technical elegance.

I think the working difference in the above case can be traced back to the evolution of titles and skill categories as evolved over time – they needed an on-site Programmer / Analyst, and a remote coding capability wouldn’t have done the job.  The VBA developers we had, had advertised themselves as “Excel macro programmers”.  Upper management thought of them as spreadsheet analysts, but in actuality they were old-school Programmer/Analysts and both they and line management knew it.  They combined the two skills — they didn’t just code, they provided detailed requirements analysis that required them to interact with the business people, in particular to parse the very detailed financial formulae into program requirements, and to test the results with them quickly.  It’s kind of like the old university footpath problem — there are paved footpaths between buildings, but watch the worn bits in the lawns to find the paths that are truly the most efficient.  If you can hire a programmer/analyst only by calling it something else, well, look for some interesting job title interpretations.  Be flexible or die.

Every initiative in IT will be faced with the /time/quality/cost/ triangle (pick any two).  The decision whether to offshore a project or not will impact all three to some extent, but time tends to suffer the most.  When putting together a bid, you’re often blind as to what the cultural preferences are (perhaps not surprisingly, banking tends to put quality, then time at the top of the tree) but that’s what the salesmen are paid to know.  It might be IT 101, but it’s probably good to get the customer’s preferences wrt. that triangle before settling on an approach.  The success rate should be higher when our approach vs. their preferences match, but sometimes it’s hard to dig that out before you draw up a solution.

But all those spreadsheets out there scare me.  That’s way too much VBA to be healthy, and I think this falls into the category of one of those “silos of risk” I mentioned before.

Lovely market, though.  <…>

Vincent Dermody: Kelley,

A Presentation I gave to the PMI breakfast meeting in Feb may interest you. I spoke about the exact issues your raising, I call these the grey apps and the Ghost Enterprise Architecture.

I believe the decision is not whether to offshore but to regiment or not! i.e. do you run a prototype production (a la google solutions) paradigm, as a rapid response, and then migrate to a permanent ITIL level footing in time. The old tag “you can have it fast or you can have it right” no longer is enough. The reality is that business may be willing to wear more volatility for greater speed to deliver. This is also the target area of App generators and Model driven Enterprise applications.

The charm of it all, as your pointing out, is that in the current M&A, and divestment loaded market, the IT struggle will be as much about bringing together the Grey Apps of two organisations as it is about combining the SAP installations. This is why should open out our definition of applications. Excel is not an application, it’s a technology which enables applications, these being the different spreadsheets, each being as different as SAP and Maximo.

For reference, The Intel Fabrication which opened in Kirya Gat, Israel in 2005 was speced, designed, built, financed etc, using ~50,000 spreadsheets. The number one risk to the program delivery office through the 3 years of commissioning was …. ????

Excel 2003 upgrade!

Kelley Johnston: Nice one, Vince.  I like your Grey Apps portrayal, and thought that slide pair that showed the cogs slipping past Architecture was a hoot.  . (BTW What in the heck were you using for presentation development?  That did *so* not look like Powerpoint or Visio.  Caught my attention, it did, thought it looked pretty good.)

I think the question of “whether to offshore or not” vs. “whether to regiment or not” is difficult, because I see them as somewhat conformant.  Offshoring tends to be highly regimented for one reason — the need for unambiguous and accurate written requirements goes up as the communications differences increase, i.e. any environment that does not facilitate face-to-face communication well. 

Or so it’s perceived.  However I once inherited the architecture of an offshored development (Telstra/NetCracker) where the offshore devs were in the same time zone, but still rather remote geographically — Moscow and Vladiovostok.  We ended up dragging most of the team on-site in rotation because of the need for face-to-face meetings, which damaged the budget somewhat.  This was primarily due to a cultural development attitude difference that far exceeded the time zone factor.  They were bright, they were competent, they knew the product, they spoke English, but they did not relate well to written documentation. 

I learned from one of them that it was simply not the way they did engineering back home; they talked, they had meetings, and writing things down could get you into trouble.  Different approach, but then it’s pretty clear that it works for them.  Took us a fair bit of time to leap over that gap.  <…>

But sometimes you just want someone who knows VBA…  Only 50,000 spreadsheets?  I think the bank I worked for can beat that…