Commissioning software from a 3rd party (onshore/off-shore) ~ some thoughts !

The following blog appeared on my previous blog site - November 2013 
 

Recently I was approached by the owner of a medium sized organisation, who wished to develop a “small” application they felt would both add value to the current customer base and maybe, if sold or given away, would promote other value adding services of the company.

Having commissioned software development by third parties outside of the UK  on several occasions, I was well positioned to respond to a simple request for guidance and did so in the form of an e-mail. I was pleasantly surprised with the information in my response and now ‘repackage’ and share with you…

The response was by no means a complete approach on developing an idea with a 3rd party supplier, as clearly there is no one size fits all solution, however it provides a baseline to start from. However my response captured some salient points and golden nuggets of information which I discuss briefly below.

The initial recommendation was to decompose the overall processes into four key areas with each area addressing scope in terms of Cost, Time & Quality.

When opting to develop software with a 3rd party, who is based in a different country / time zone, it would be prudent to implement a process to control both the quality and the cost of development with a line of sight built  on the outcome at all times.
The four areas Preparation, Commissioning, Delivery/Receipt, Maintenance and Support, are discussed briefly in the following pages:

4modes

Preparation 


As Benjamin Franklin famously quoted, 

“if we fail to prepare, then we prepare to fail”

This is something which is a key investment to undertake prior to commissioning software, products or services independent of the size or complexity.

This investment should come in the form of basic context and outcome planning for the system allowing one to focus on the desired outcome.

The following are pointers to consider prior to entering into an off shore software development or product commissioning exercise:

  • Systems conceptualisation – As part of the design process. The core concepts of the system needs to be documented and validated, factoring the essential and desirable value adding services you wish your system to provide
  • Two sets of documents should be maintained for protection of your Intellectual Property (IP), the first should contain a complete system spec, business processes, target operating model, future features etc. The second set of documents are documents that you feel comfortable passing to a 3rd party and controls your IP by reducing your exposure to possible risk allowing the developer to develop the core  components similar to assembling a small jigsaw puzzle.
  • Segment the services into essential and desirable services which can thus be phased into a delivery project plan and allow you to prepare a budget.
  • ‘White boarding’ or mind mapping your software / process flows is very useful tool to allow you to validate your thought process.
  • Determine the Operational Context of your system in terms of the business process executed to support the operational maintenance.
  • Specify the landing platform & its support mechanisms – Is the platform for delivery the web, a thick client application or a service. In any case each type of development will have different cost, time and quality issues to address.
  • Having thought about the above, it is now necessary to create the Functional and Non-Functional Specifications of the system. Numerous templates for these documents can be downloaded of the web – This should not be outsourced if you wish to maintain control of the deliverable.
  • Break down all tasks into manageable, measureable chunks which can be individually priced if required
  • Suggest a fixed price agreement is pursued at all costs to avoid spiralling development costs.
 
Tasks in essence should align to systems life cycle using a baseline methodology e.g. ;
               
           Analysis -> Design -> Build ->Test – >Deploy ->Measure ->Optimise

  • Each of the above should be broken down a level, facilitating pricing and can allow you to determine and agree what is manageable in terms of milestone payments for delivery , which the developer will request information upfront.
  • A simple web search “Freelance Developers” then the name of the country e.g. India will return you thousands of freelance developers or organisations.
  • It may be prudent to pick three developers and conduct similar due diligence on the services and capability where possible always  ask for reference (non local)
  • Implement a communications plan which factors in  e-mail, Skype, VoIP schedules and controls
  • Prepare a Non-Disclosure Agreement (NDA)- enforceable in the local country.
  • The NDA must be put in place before you discuss any requirements with any developers.
  • As part of the commercials make sure you have an exit strategy or switching strategy before next step
  • Time Stamp your activity and set a budget!

Commissioning

The commissioning activities are all about getting the right agreement and process in place for a successful relationship between yourself and the vendor.


The key considerations are listed below;

  • Prior to commissioning the work ensure that you have selected the developer based on their experienceprice and history of delivery i.e. track record  – if necessary undertake further due diligence.
  • The Non-Disclosure Agreement must now be put in place and again, it must be enforceable in the local country
  • Seek advice and specify your preferred development environment – Integrated Development Environments (IDEs) , tools, language, database  you would prefer them to use or establish their strengths in each domain to reduce time to market
  • If 3rd party code libraries will be used by the developer ensure that the re-use and licensing agreements are not prohibited, even if open source establish the associated cost.
  • If feasible, inform the developer that all 3rd party libraries for your project will be sourced by yourself and licenses will be provide for use during the build cycle. This allows you retain ownership of the dev. environment. components
  • You must suggest or ask the developer to use a code profiler – this will allow you to have some guarantee of Quality Control over the code.
  • Propose a weekly update call – end of week, allow them to tell you of the deliverable for the week and the proposed deliverable for the following week.
  • Propose upfront weekly code drops, and maintain a versioning system and weekly back-ups, allowing you to roll back in the event of a dispute.
  • Create a FTP site and ask for code drops to the FTP site or ask them to have access to their FTP Server as guest
  • Produce and get a project plan agreed by both parties, including milestones and code drop dates.

Delivery/Receipt


How the interim code drops and final packaged software is delivered requires strict quality controls and measurement against both the functional and non-functional requirements.


Some considerations are listed below;

  • Allow the developer to develop the code – but insist on weekly updates as previouslymentioned.
  • While, you will not be checking the actual code it would be prudent to check the deliverable to be parsed through a code profiler, a tool which assess the quality of the code and in many cases free for download from numerous sites.
  • The output from the code profiler should be used to challenge the developers where and if required..
  • You must take responsibility for the user & performance testing. However, the developer must test units and performance of code.
  • When all testing is complete and the work can be frozen, ask for the installable executable file, the source code, any 3rd party add-ons used and documentatione.g. if its Java – you want the Javadocs

Maintenance


Once the project is complete, the developer should be retained and in many cases will be eager to maintain a relationship This retention will be essential as the code is used errors / bugs or enhancements will emerge and the developer will be best place to rapidly fix these problems.


Some considerations are listed below;

  • You will want updates to the system – so make sure the design is such that changes are simple and not complex rebuilds
  • Support – Agree annual support figure – if you can include minor fixes in this then do so.
  • Differentiate between minor and major enhancements and instigate a change request system.


The above pointers were used to highlight some key points to a company wishing to develop a concept with a foreign software house. The items listed above are not endless and can and should be extended further depending on the size of the system and with professional help.

Comments

Popular posts from this blog

Solution Design - Table of Contents

Enterprise Architecture, Digital Transformation and ICT Strategy - Seminar Video Presented at the AUC Egypt

Reflecting on Error Management and listing HTTP Status Codes