Introduction


My initial involvement with the project was to perform a technical review on both the code, and the processes in use within the software department of the company. This was produced and was deemed to be of great use to the business. On the strength of this I was asked back to manage the project into the deployment phase.

A potted history


The company had a working software product that had been developed for them. They needed additional functionality to deal with their expanding business. Their suppliers had decided to make a more generic version to offer as a product to the sector, however, due to a refocusing, this never got beyond the development phase and so the company were able to buy the functional and technical specifications and source code as a basis for their upgrade.

To complete the development of this project, UK suppliers were approached to tender. The quotes received were unacceptably high, and so outsourcing was considered and an Indian team won the contract.

Development commenced working from those original specifications - no review was made to check the functionality specified and so the team continued to build a generic product rather than one specific to the company's needs. The requirements of the user community were also not considered at this stage. During the lifetime of the project 3 different Indian development companies were used - the first company was taken over and the new company started to use this project as a training ground. This was not acceptable and a new company was created and were awarded the contract.

Implementation and Deployment


My remit was to work on site for 2 days per week, and to manage the development remotely from our head office in Brighton as much as necessary for the rest of the week. At times during the project I found myself booking a 35 hour week as I communicated more and more with the development team. In addition to the Indian team, I had 2 part time resources based in the UK although they were rarely available to me as often as I would have liked due to support issues.

During my technical review I had found that there was no user documentation, no user testing, out of date unit tests and little in the way of training documentation. So, among my first tasks was getting some test scripts written, and get some testing started so we could evaluate the current state of the system. Unfortunately, due to a lack of requirements documentation, the tests had to be based on the expected behaviour of the system, rather than functional requirements. Whilst the test specifications were being written, bugs were identified, prioritised and sent over to India for fixing.

The communication methods used between the UK and India weren't great - there was no shared server or shared workspace. All documents were emailed from place to place. There was no central bug database. Instead bug documentation was emailed leading to out-of-step bug logs and confusion as to the status of some issues. Day to day communication was through email and yahoo instant messenger. I was always careful to back up any instructions which took place through Yahoo messenger with an email, to make sure there was a lasting record of it. The use of a messenging system was highly valuable as it allowed clarification of issues, as well as real time walkthroughs of processes and bugs.

From the business side I introduced weekly strategy meetings with the key users to raise the project's awareness in the user community. These were well attended and issues were raised and reacted to on a very timely basis. A deployment strategy was produced, and priorities were assigned to the different aspects of the system. The development team worked within these prioritisations to ensure that deployment of the system could be phased, starting with the most important elements.

The user community had mixed feelings on the system, partially because it had been promised for so long that they had lost all faith, and all enthusiasm, but also because few of them had had much involvement with the project, and so they had no buy in to it. This could have been remedied by a) reviewing the original technical specifications and producing requirements specifications in accordance with a user group, and b) communicating the status of the project in a more upbeat manner.

User testing commenced in January, and no major bugs were raised. Some elements of the system were found to not work very efficiently with the business processes and so these were analysed and specifications were drawn up. These were found to not be essential to the deployment of parts of the system, and so the deployment process started and my involvement with the project came to an end.

Conclusion


So, does outsourcing development work? Yes, undoubtedly so. It might cost you less than using UK developers, but this should not be the driving factor as your management and communication has to be better than where your developers to be co-located with you. Outsourcing is not an excuse to throw a specification over the wall and expect your product/project to come back - that isn't how it works when your team are next door, so why should it happen when they're further away? Communication is the key, and recording that communication in a way where it is accessible to all the members of your virtual team is imperative.

Further Reading


Loren Siebert's article for Javaworld.
Neil McAllister's article for New Architect magazine.