With today’s globalisation of services come several problems. It is all too easy to perform a web search, select a supplier with a good shop front (web page) and enter into an agreement, while neglecting to perform basic due diligence.
This ‘scattergun’ approach may result in a product requiring further work, not meeting the required outcome, suffering from bugs or just exhibiting poor performance.
Having commissioned software development abroad and learning through mistakes along the way, I was recently approached by a medium-sized organisation that wanted to develop a ‘small’ application. They thought it would add value for existing customers and possibly be sold or given away for some tips and guidance.
My e-mail response was by no means a complete approach on developing an idea with a third-party, as clearly there is no ‘one size fits all’ solution, however it provides a starting point and captures some salient points which are discussed briefly below.
The initial recommendation was to plan, do, check before acting, with each stage addressing scope in terms of cost, time and quality.
The stages are preparation, commissioning, delivery / receipt and maintenance:
Preparation
Prior to entering into an off-shore software development or product commissioning exercise, the following points should be considered:
- Systems conceptualisation: The core concepts of the system need to be documented and validated; factoring the essential and desirable value-adding services you want your system to provide.
- Two sets of documents should be maintained for protection of your intellectual property (IP). The first is a complete system specification encapsulating business processes, target operating model, future features and so on. The second document provides information you are comfortable sharing, and controls your IP by reducing exposure to possible risk, allowing developers to produce the core components.
- Services should be segmented into essential and desirable. These can then be phased into a delivery project plan, allowing you to prepare a budget.
- ‘White boarding’ or mind mapping your software / process flows is a very useful tool to allow you to validate your thought processes.
- Determine the operational context of your system in terms of the business processes executed to support the operational maintenance.
- Specify the landing platform and 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 a detailed functional and non-functional specification of the system. Numerous templates for these documents can be found on the web. This should not be outsourced if you wish to maintain control of the deliverable.
- Break down all tasks into manageable, measureable chunks that can be individually priced if required.
- Suggest a fixed price agreement, to avoid spiralling development costs.
Tasks in essence should align to the systems life cycle:
- analysis;
- design;
- build;
- test;
- deploy.
- Each of the above should be broken down into lower-level detail, facilitating pricing and agreeing what is manageable in terms of milestone payments for delivery.
- A simple web search for ‘freelance developers’ then the name of the country, for example, 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 capabilities. Where possible, always ask for references (non local).
- Implement a communications plan that considers email, Skype, VoIP schedules and controls.
- Prepare a Non-Disclosure Agreement (NDA) enforceable in the local country.The NDA should be signed before you discuss any requirements with the developers.
- As part of the commercial agreement, have an exit strategy or switching strategy.
- Time stamp your activity and set a budget!
Commissioning
Commissioning activities aim to ensure that an effective agreement and associated processes are in place for a successful relationship between yourself and the vendor.
The key considerations are;
- Prior to commissioning the work ensure that you have selected the developer based on their experience, price and history of delivery - if necessary undertake further due diligence.
- The NDA 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, languages, databases you would prefer them to use, or establish their strengths in each domain to reduce time to market.
- If third-party code libraries will be used by the developer, ensure that re-use and licensing agreements are not prohibited; even if open source, you need to establish the associated cost.
- If feasible, inform the developer that all third-party libraries for your project will be sourced by yourself and licenses will be provided for development. This allows you to retain ownership of the development environment components.
- Suggest or ask the developer to use a code profiler - this will give you some guarantee of quality control over the code.
- You may want to set up a ‘code build’ platform depending on the size of the system.
- Propose upfront weekly code drops and maintain a versioning system and weekly backups, allowing you to roll back in the event of a dispute.
- Propose a weekly update call, allowing them to report progress for the week and the proposed deliverable for the following week.
- Create an FTP site and ask for code drops to the site or ask them to grant guest access to their FTP.
- Produce and agree a project plan, including milestones and code drop dates.
Delivery / receipt
The delivery of the interim code drops and final packaged software requires strict quality controls, as well as measurement against both the functional and non-functional requirements.
Some considerations are listed below;
- The output from the code profiler should be used to challenge, if and when required.
- You should take responsibility for the user and performance testing. However, the developer must test units and performance of code.
- When all testing is complete and the development can be frozen, ask for the installable executable file, the source code, any third-party add-ons used and documentation, for example if the development is Java, you may want Javadocs.
Maintenance
Once the project is complete, the developer should be retained as the code will require error / bug fixes or enhancements and the developer will be best placed to rapidly fix these problems. In many cases they will be keen to maintain an ongoing relationship.
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.
- Agree an annual support figure - if you can, include minor fixes.
- Differentiate between minor and major enhancements and instigate a change request system.
The above pointers were used to highlight some key points to an organisation wanting to develop a concept with an offshore software house. The items listed above are not exhaustive and can be extended further, depending on the size and complexity of the system.
