Posts from the nest
From Drupal, PHP to the future of SmartTV and gamifying education our blog is on occasions rants of an over active mind….

Choosing a model and an outsourcing partner 101: Tactical software outsourcing – part 1

Red Parachute box 2010 Choosing a model and an outsourcing partner 101: Tactical software outsourcing   part 1You need not be an old hand to know there are several flavors of software development outsourcing, Ok its not exactly Ben & Jerry’s but it isn’t  plain Vanilla either. The key is as common sense dictates to know which flavor to use when and to keep an open mind to change the mix as and when required.

Instead of listing models or a bunch of do’s and don’ts of sourcing a software outsourcing partner let me take you through some of the scenarios I have faced with my clients and for my own company over the past decade.

In part 1 I will tell you of a situation when choosing the right flavor was at the very heart of saving a start up…from…not starting up.

Many years ago an acquaintance from Sweden called me out of the blue; Tor, usually a jovial fella never one for short conversations or getting to the point within the first 10 minutes of any conversation surprised me with ‘Hi Kubair, I am screwed man, need your help, have you got time to talk now?’. Tor ran (he has since exited and relocated to the states) a product based software start up in Stockholm, had investment to launch a new web based product and had decided on an in-house development and support model.  He had a pretty slick operation in Stockholm and was as far as I was aware was doing pretty well..up until that phone call.

Half an hour into the call I found out Tor’s product was months late, way over budget and he had just been told by his investors there was no new money coming and he needed to complete his product in the next eight weeks with the little amount of financing left or else… Tor stood to loose everything. In Tor’s own words ‘I have burnt through most of my cash, I have an incomplete product, I have lost some of my key guys, and I need help to finish off the product, and with the amount of money I have left going offshore seems to be the only option..’

The positives I took out were, he has time (a lot can happen in eight weeks), he has some funding left and I do not need to convince him to go offshore he has come to that conclusion himself, (but I was not convinced myself if his silver bullet was in a distant land). The negative was I had no idea what kind of knowledge his ‘key’ guys had walked away with and how many were left, I knew little about his incomplete product, the technology it was based on or which domain it belonged in; Tor had refused to answer any of these questions over the phone yet was happy to email everything over (in an encrypted files of course. Stress does strange things to people!).

The call ended with Tor agreeing to fly out to London for the weekend to discuss his options and what the ‘parachute’ was going to look like. I had a day to study the documents, code and project plans sent over and to do my homework on putting together a ‘parachute plan’ for Tor and his venture.

I met Tor at my flat and the first thing I noticed was the stack of brochures of offshore software promotion associations from Ukraine to India he stacked up on my coffee table. I looked at the stack and asked, ‘selected a host country already?’ we exchanged smiles and his expression said ‘no’ followed by ‘I don’t know where to go, is that not why I am here Kubair? you are supposed to be good at this offshore stuff! where should I go?’

The question is not which host economy should Tor have gone to! but which model were we to use and since the best flavor to suit the need was tactical outsourcing the question was which off shore companies had local (onshore) operations.

I responded with a question of my own; ‘Tor which offshore operators sit in Stockholm?’ Tor’s response was an amusing ‘I’ave no ideaah?’ I pulled out a page of A4 with a list of offshore software service providers with local offices in Stockholm, the list was not very long but there was a fair mix of companies from Eastern Europe and a few from South Asia. I had already eliminated the tier 1 providers whom Tor could not afford and unbeknown to him at that time had picked three I had spoken to already to confirm they had the skill sets, availability and the hunger for providing a ‘parachute’ service. There were two who had domain specific knowledge Tor was after and one that stood above the other in terms of capacity (they too it turned out were a start-up).

I joined Tor on his way back to Stockholm and spent the next couple of days with the shortlisted suppliers before selecting one (and it was the start-up I had my eyes on from the beginning of this exercise), it was not just Tor’s venture on line but my head too, for Tor had by now pitched me as the silver bullet solution to his investors and left me to face their daily inquisition. I explained to Tor (and it took some convincing) and his investors (who were very hands on now) that the solution was not to make their problem someone else’s but to work with a supplier who could provide Tor’s team with the missing links here and now in Stockholm, and augment their  team with outsourced resources (both onshore and offshore if need be). Their aim was not to go offshore in the medium to long term, so the knowledge had to be retained and transferred in-house, our timelines were so tight we needed a hands on approach where proximity was going to be key and the project manager was going to remain their  in-house resource who could not be supplanted offshore. Having your own in-house project manager to manage the augmented team has its benefits though there are specific challenges that both you and your service provider need to be aware of and have processes in place to mitigate associated risks.  With the chosen supplier we took the decision to augment the in-house team with three of their senior resources onshore and testing was sent to their offshore development centre, the time difference worked in our favor too.

The next few weeks were a blur with early mornings and late nights,  shuttling between Stockholm and London juggling a number of projects I had on the go, time whizzed past, there were ups and downs, times when the it seemed all would come undone only to be followed by a rainbow the next hour! in week 7 a full week ahead of the deadline the product was delivered on spec and below budget: Tor’s investors were ecstatic! I had delivered what I had been hired to deliver, Tor was back on top, the investors were breathing a sigh of relief and everything was back on track, and I was back in London.

I got to send Tor a fat invoice, learned tons while being paid for it and got to see a bit of  Stockholm. I was retained for the next few weeks post launch while we transferred the knowledge in-house, built up the in-house team to replace the missing links we had filled in with an outsourcing partner’s resources and eventually ended up negotiating and putting in place an outsourced testing contract with the outsourcing partner.

Now for lessons learned from this mini adventure and what we all can take away from it…

The question I see most tech entrepreneurs rushing towards is ‘which location or host economy should I be looking at.. Eastern Europe? surely I must go to india!?’ In my opinion this is the wrong question to begin with and at best can lead to a protracted and expensive trial and error process of finding your perfect partner to outsource your software development, maintenance and support to, and at worst can put you off outsourcing completely!

The correct question is what model or flavor of outsourcing best suits your existing and immediate needs? the answer is in your objectives for outsourcing. So why is it that you are thinking about outsourcing? is it to cut costs, is it to bring in a skill set your in-house team does not have, is it to address a short term capacity issue? is it to deliver a project without disrupting your existing schedules? a product? why why why!?

Only when you have a list of your objectives can you start thinking about the models or flavors, and only once you have the models or flavors short listed can you start thinking about location and partners.

Taking Tor’s case the objectives were to complete an incomplete product and do so rapidly, to augment the in-house team where some skills had just walked out of the door, to bring those skills back in house once a safe landing had been achieved and to do it all economically. It was all short term and focused on getting a deliverable (their product) out of the door; and the only flavor in my opinion was tactical onshore outsourcing.

Once we had a model selected we had to start looking at partners and given that we were looking for an onshore and offshore mix the best place to start is at home seeking out outsourcing providers who have an onshore technical base backed up with an offshore HQ. This narrowed down the hunt to a few providers. In such a scenario you have to really engage in your due diligence, you do not want to find out at the 11th hour that your selected provider has only got project managers and analysts onshore (which is perfect for other models but for the tactical model we had chosen this could spell disaster). When it comes to tactical outsourcing proximity matters. Then there are common sense issues you need to address when looking for a software outsourcing partner such as domain expertise and a cultural fit. Of the two domain expertise is easier to understand and identify whilst cultural fit is often misunderstood! I like to think of it as the chemistry between the teams/personnel, it isn’t about possessing the same cultural capital but being able to relate to each other, having shared values and objectives.

Then there is transparency, you need to make your outsourcing partner aware of your objectives, your chosen model so they are not lead on,  in our case the selected partner knew this was a short engagement with clearly stated deliverables and performance indicators, we made it clear that post delivery all the knowledge will be coming back in-house and their hand over plan must cater for a smooth transfer of knowledge to the new recruits who would only be brought in post delivery. This ensured the expectations were clear on both side, outsourcing providers look for long term relationships and if you plan to dump them after a specific project, let them know in advance, it is better that way for both parties. But do not make it sound like it is set in stone, allow for some flexibility… if you are willing to bend a little your provider will match and exceed your demonstrated flexibility by many folds, remember it is about relationships, it is about people… be a little giving and you will get a lot back in return. If you do not intend to outsource support post delivery of your project’s completion make it clear to your service provider.

I am not going to go into the common sense details here like ensure your objectives, performance indicators, length of resourcing, transfer of knowledge, hand over etc is captured in your service agreement with your software service provider, am assuming we all have the common sense to know that!

Once we had made our objectives and model clear to the selected supplier we threw them a carrot of a performance related bonus on before time completion and once they took the bait we negotiated hard on rates (bear in mind we were using onshore resources so the rates weren’t going to be the same as their offshore resource rates but we cam pretty close), but do not drive the provider down too hard for you want to motivate them whilst keeping your purse strings tight. Getting this mix right works both ways, getting it wrong ends up with everyone eating a dog’s dinner. In our case it worked out very well for the provider for they delivered before the deadline and our bluff blew up in our face in the nicest possible way!

The last lesson from Tor’s case is hunger, a hungry service partner will find the capacity and determination to deliver to tight schedules or in this case ahead of schedule, it is also critical that they feel your hunger… passion feeds off passion! As we found our chosen partner did! and getting all of the above right ensured our tactical software outsourcing decision was right, it delivered what was required.

Tactical software outsourcing is pretty popular for software houses, and I have managed numerous such contracts myself and overseen many more via ikonami; within tactical software outsourcing there are a few different models as well. For instance in Tor’s case we went for onshore team augmentation and offshore remained somewhat light touch. In my next example I will site a case where onshore team augmentation was not only not possible but could have been disastrous!  but that is an other blog post on tactical software outsourcing.

Over the years I have seen tactical onshore software outsourcing to follow a pretty basic pattern, here is a neat little chart to wrap your head around it…

Tor Tactical SW outsourcing 1011 Choosing a model and an outsourcing partner 101: Tactical software outsourcing   part 1

Tactical onshore software outsourcing: a typical pattern your project ought to follow

In part 2, I will site another situation where we followed a tactical software outsourcing model but onshore was out of the question… see you in a couple of weeks time. Happy deliveries.


Subscribe to Blog