Outsourcing to the seven "C"'s

Outsourcing software development has become a very effective way to get software projects delivered in the modern fast-paced business environment. Like any approach, it has potential benefits and things to take into consideration.  

Some potential benefits:

  • separation of concerns : separate a development project from BAU activities or other projects. 
  • hit the ground running: potentially access to "ready made" teams of developers.
  • visibility of cost: depending on contract, cost can be tied to outcomes
  • specialisation: outsourced organisations may have core competence in areas that you do not and do not wish to strategically attain. 

Here are a few things I think are worth considering based on my experiences over the last 25 years.

Context

The context of why you are choosing to outsource development is fundamentally important as is the context of what you are trying to develop (in terms of complexity) and how that ties in to your long term strategic objectives. For example if in developing a software application, there are some skills and competences that the business will need later in it's evolution, this would need to be taken into consideration. Unfortunately, one does not always know the answers to this (and other) question(s) apriori.

Contract

I have seen and/or been involved in many outsourced contracts and contract negotiations. It is not possible to get the perfect contract in place (in my opinion), however it is vitally important to get some basic considerations clearly laid out depending on context. No-one wants to use the terms of a contract as a threat (if it comes to that point, things are not going well), however, the contract should clearly define roles, responsibilities, ownership, accountability and other factors that set the project up for success. Ideally, the contract should be balanced, it is unwise to have the balance of power highly in favour of one side or the other, this leads to an inequitable relationship from the outset. In my opinion the most successful outcomes have been when the contract and the relationship reflects a partnership rather than supplier/purchaser type relationship. 

Code

I guess at some point we have to talk about the code itself. Software is made up of many artefacts, code, documentation, data etc. Even working code can have varying degrees of "quality". An organisation should consider the future maintainability, extensibility and reuse of the code. It is very difficult to measure some of these attributes of the code, but it is worthwhile at least trying to have some standards or measure in place to sense check, that overall quality is there. 

On many occasions I have seen the quality sacrificed for time or cost. There is no getting away from the fact that speed, quality, cost are conflicting requirements as they are in most spheres of life. It is important to strike a balance and be conscious of those decisions. On many occasions I have seen for example quality sacrificed for speed, only for quality to resurface at a later time causing dispute and other problems in the organisation. If you were to hire someone to paint your house very quickly with cheap materials you would naturally expect a sloppy finish which would not last very long. There is no difference when it comes to software engineering.

Another ugly-headed-monster often raises it's head when it comes to code. I have seen it so many times that I thought it is worth noting here. Actually, there are two related points. Firstly, in a world of open sourced libraries and frameworks, which we all use. It is important to keep an eye or have some control on which of these components get pulled into our projects. Some open-source code is of poor quality, some are not well maintained, and very recently there have been numerous instances of serious security vulnerabilities found in some of these open-source components.  Secondly, in a number of cases I have seen outsourced companies offer their platforms or components to the project as a way to speed things up. Conceptually this makes sense, however, if not managed cleanly, it can lead to various problems. For example who owns that code, is that code maintained, is it documented, will future updates to that code be available in perpetuity etc etc. Remember the world is moving, especially in software and things become out of date very quickly.  Also as a side bar, ideally you don't want to be sponsoring the outsourced organisation to improve their generic components on your account - it's very hard to manage this cleanly. 

Ideally code should always be hosted on some system or repository owned by the hiring organisation and there must be some checks and balances put in to ensure that every artefact needed to deploy a fully functioning system is there, this should be tested on a regular basis. Far too often, I have seen cases where at some point, someone from HQ tries to deploy the system and finds out that there are missing artefacts. Hopefully, there is still a good relationship with the outsourced team and this can be easily solved, but there in inherent risk here.

Culture

One thing that this very often overlooked, is culture. Both corporate culture and international culture. Depending on how tightly coupled the outsourced team will be with core members of your management, product or development teams, culture should be taken into consideration. I have worked on projects with very capable teams in over 15 countries, the differences in style, approach, communication, accountability, manner etc etc are numerous and have a significant impact on being able to deliver quality software in a timely manner. 

On a number of occasions I have seen organisations either move from an outsourced model to opening up a local office in the region (usually to save on cost amongst other things).  However, on numerous occasions the business then proceeded to treat this remote office differently than an outsourced relationship. This is erroneous in my opinion, the outsourced element still remains irrespective, this is because the balance of power invariably remains within the central HQ. In terms of software development and managing the relationship and projects, one still has to consider the same things as with a "pure" outsourced relationship. 

Communication

Communication is fundamental to any software engineering project. Getting the lines of communication established from the outset is paramount. Organisations often ignore simple things like language skills. For example having maybe multiple development teams in different countries all communicating in English can be a bigger barrier to success than many realise or factor into their decision making.  I was once involved in moving a project from one side of the world to a team on the other side of the world. Aside from the logistic issues, the communication challenges were substantial. 

In software engineering, communication needs to be comprehensive whilst succinct. This is often not easy to achieve. We tend to either over elaborate or under-elaborate. Getting the right balance is a challenge which is exacerbated by language barriers. This is before one considers other issues like timezones, personalities etc.

Co-operation


Fundamental to any successful software engineering project is co-operation. When it comes to outsourced development, what is often overlooked is that the incentives and motivations of the hiring organisation and it's staff may be misaligned with the outsourced organisation.  For example, the senior architects and developers in the hiring organisation may have bonuses or other incentives, whilst the outsourced organisation will invariably have incentives around billable hours (this is unavoidable). Unless this is managed correctly, this can lead to complications in delivery. 

Country (Education)


I have written about culture and communication, but further to these very important considerations, there are other considerations that in my experience can impact more complex software development projects.  I think we would all agree that different education institutions have varying quality of education, some countries have a very high standard school system and higher education, other countries do not have the same standards. This in no way means that there are not highly skilled capable individuals in every country on the planet, it does however mean that finding these people can become more of a challenge in situations where they are likely to be scarce or in high demand.  

There are other factors relating to a country that do come into play, unfortunately, with the global turmoil, conflict and war can have an impact. Infrastructure like electricity, telecommunications and accommodation can also impact and should at least be considered as part of the evaluation. 






Comments

Post a Comment

Please post your comments, I am interested in your views

Popular posts from this blog

The pitfalls of share options in the technology startup

Draft 1 PLEASE NOTE: I  am a simple engineer and this document should not be taken as legal advice in any way whatsoever.  Please feel free to comment or relate your stories here. All feedback is more than welcome Over the last few weeks I have been involved in trying to get a fair outcome for some options that I have in one of the many startups I have worked with over the years. As I continue to push my case forward I thought I would write some thoughts whilst fresh in my mind.  Many of us are attracted to startups due to the promise of shares or share options in the company we are joining. Many people work at reduced rates or no pay in exchange for these contracts, with the hope that one day they will materialise into some value for us. For startup companies, options are a vital currency. Initially cash is tight and using options is a means to attract the right people to help launch the company or take it to the next stage in it's evolution.  In recent weeks, I hav...
Read more

Hire for Engineers not for Frameworks

I have been faced with hiring great engineering teams on a number of occasions, I am constantly amazed at home many hiring managers and recruiters seem to focus on particular technologies and experience in those technologies. My experience has taught me to hire engineers and I have always viewed the technology as a secondary consideration. I always focuses on a grasp of engineering fundamentals and not on information about some current or past technology. In our current world these technologies are out of date by the time the ink on the contract is dry. Recently, I was approached by a leading company for a very senior role. The in-house recruiter laid on his wonderful resume with world leading software companies before affording me the chance to explain my career-to-date. He then proceeded to ask me a number of questions on specific Java libraries and how they were used. This is all information that is readily available on reference sites and in API documentation and does not ...
Read more

Insights & Suggestions For Effective Software development

I decided to note a few observations on software development based on my experiences with a number of clients over a long career, this is work in progress and would appreciate any further input or comments. Topics Data science needs systematic approach Without Specification you are in trouble Interview for excellence Agile does not mean "do nothing" Devops first is not always productive Too many resources is as bad, or worse than too little Design before Develop, before Deploy 1. Data Science needs a `Systematic Approach` We live in a `Data Science` age, it's a buzz word. We have always had data science in some form or another, it's just that the availability, techniques, compute power and volume has exploded over the last few years. Principles are not new, they are standard engineering practises, however, in the new generation of `Data Science` these standard practises are often overlooked. Here are some general rules-of-thumb I have noted down : It makes no sense to...
Read more