Outsourcing Made Right – Think Big, but Buy Small by Ivar Jacobson

Let’s be realistic.  In a column like this I can only give you a hint of what you as a buyer need to do.  However, it is amazing how many outsourcing agreements would benefit from this basic advice.  But note that basic means that there may be exceptions.

1.       Split the work into smaller, separately defined pieces that potentially can be given to different vendors.

2.       Separate work that is exploratory in nature from work that is mere production.  Production can be calculated at a fixed price, whereas exploratory work can’t reasonably be calculated in advance.  For instance don’t ask for a fixed price until you know the key requirements (say 60-80% of all requirements), and until you know how you want it to be built (you must have an architecture that is implementable). 

3.       It is beyond human ability to specify all requirements for software upfront.  Don’t accept a contractual model where all requirements have to be specified and agreed upon early.  Even worse is to agree on requirements upfront and then pay an unspecified amount for each change.  This is nothing less than horse dealer contracts. 

4.       Outsourcing software development without an architecture is like asking someone to build a house without an architecture.  You would never do that. However, for software, drawings are not enough.  You need to make sure that the architecture can be realized.  All important risks (performance, etc.) must have been eliminated.  That requires you need some executable code – usually 5-10% of the final code must be in place before someone can calculate a fixed price.

5.       As for a house, you need to inspect at certain points to make sure that the work is on track.  Inspection in our case must include executable code to be meaningful.

Now, this is not easy to do.  Still, this is just the basics.  For large outsourcing projects such as building an enterprise wide SOA system, the required competencies are much higher. 

6.       You need to be able to split the work among several subcontractors.  Thus, you need to set a building standard.  Otherwise different vendors will deliver non-compatible software.  It is not enough to specify what platform to use, but you need to specify how to make drawings (UML for example), what design practices to use (use cases for example), when inspection needs to happen and more.

The general advice is to split the work in smaller manageable pieces with fast deliveries.  Think big, but buy small!  Western companies outsourced big M$ projects to India.  Japanese companies are not giving up control that easily.  Their outsourcing contracts to China are in the order of $100k.  Many western companies are now taking back (insourcing) their software to maintain and develop it at home.  The new strategy is to insource the business critical applications, but outsource less critical software.  Reflecting on this, it seems we are going back to where we were before the outsourcing frenzy started.

Again, if you don’t have this competence or you cannot get it, don’t even bother to outsource your software development.  And, competency is not enough.  You need to be smart!

4 Comments
  1. regmigrant | September 20, 2008 at 12:19 pm Reply

    avatar

    - apologies, my three year old felt the need to add to the comment.
    (and on reflection perhaps that wuld be better :)
    …….

    With Use Cases I felt that I had finally found an answer to the perennial gap between Operational Business and IT Development and they do help more than the traditional methodologies. But, as you have said in previous posts, they are not the whole story.

    The outsourcing vs insourcing debate is, I believe, a similar issue – made more complicated by the involvement of mutliple businesses.

    In the standard model the outsources must bid low (in some cases below profit!) to win the business over a term. Within that term it must find ways to modify the deal to its advantage or go out of business.

    I accept that breaking the deal into smaller pieces can help to make sure that no individual element breaks the entire project but then we are back into the situation of integrating those parts and that is always more difficult than the original breakdown.

    Just as it is impossible to know the full requirements of a package before delivery starts it is similiarly impossible to know the full requirements of the outsourcing deal in advance of developing a relationship with the supplier and a term small enough to prevent damage but long enough to ‘get to know each other’ is very difficult to define in advance.

    Insourcing, potentially, can be used to plug this situational gap but only at the expense of employing, traiining and maintaining appropriate staff which, on the surface would be difficult but do-able.

    However the politics of the organisation will then take over and, assuming they are successful, the IT group will want to add elements of the outsourced business to its own portfolio and similarly, if the insourcing group are not so good, the outsource supplier will steadily ground as they are asked to take on more of the insource departments (failed) repsonsibility by an increasingly desperate business operation .

    following the logic of this post we would have to maintain mutliple intenral groups managing small parts of the IT domain to parallel the competitive market place in the outsourced domain. – and at this point we are surely looking at a managment system that is beyond most organisations. The competitive market within the UK NHS and Train Companies come to mind and they are notorously bureaucratic

    To summarise:- the outsourcing model is fundamentally flawed, the insourcing model is discredited because of the high cost of resource (and training) and a combined approach is likely to fail because of people, politics and personalities.

    I believe that the IT industry consistently fails business because it is a creative endeavour attempting to solve the issues of an objective business world (at least in financial accounting terms). Until we get more IT knowledge at board level and more realisit

  2. regmigrant | September 20, 2008 at 11:35 am Reply

    avatar

    Ivar

    We have met briefly when I attended one of your ESSUP introductiry sessions and I have been a fan ever since – especially since I was then working on my first Use Case based project.

    With Use Cases

  3. Jagadeesh Hiremath | September 18, 2008 at 2:52 pm Reply

    avatar

    Dear Mr. Jacobson,

    Firstly let me introduce myself first before I write something. My name is Jagadeesh Hiremath originally from India (Bangalore) but now UK resident. I am looking forward to see you on 22/23 Rational Event.

    Insource is new term to me, however looking at the present market or economical situation. I thought outsourcing as an option would be more realistic option compared to insource. This is because most of the western companies are axing the jobs and I am sure no business would axe their revenue.

    Your advice on outsource is absolutely right for companies who are looking for outsource. I really liked point 3; I see your point because I am working as Business Analyst.

    I just wanted to let you know that, this is my first visit to your blog and I think you can see me regularly in future. Many thanks for all the inputs you are posting on blog.

    Best Regards,
    Jaggi
    (Jagadeesh Hiremath)