OFFSHORE SOFTWARE DEVELOPMENT MANAGEMENT

Transcription

1 Offshore Software Development Management The ABCs of Managing to Success OFFSHORE SOFTWARE DEVELOPMENT MANAGEMENT White Paper November

2 Executive Summary The complex process of offshoring software development activities can have financial benefits to U.S.-based companies if executed properly; however, if poorly managed it can negatively impact an organization s efficiency and profitability. This white paper describes Alvand Solutions experience managing offshoring projects and outlines an approach that will assist CIOs, CTOs, VPs and Development Managers with their offshoring initiatives.

3 Overview A decision that can increase your company s profitability or increase your stress level Ready to find out about a big secret? Ready or not here it is: U.S.-based IT companies are using offshore resources to reduce the overall cost of software development. Okay, maybe that wasn t a secret after all. The hard reality is that a lot of U.S.-based enterprises are using offshore companies to take care of a portion, if not all of their software development. The justification for offshoring development work has shifted from a tactic for reducing the cost of software development to a critical management tool essential to staying in business and having a competitive edge in today s market. The clear message from CIOs and CTOs is make offshoring work. Some organizations have been very successful at offshoring; some have failed miserably; while others are still trying to figure out how to make sense of it all. It is fair to state offshoring development is simple in theory, but very tough in actual execution. Some of the major challenges are problematic project management, lack of internal processes, cultural differences, and most importantly, communication deficiencies. Who should read this article? This article is written for companies that: 1. Have tried and failed at sending projects offshore. 2. Realize they can improve the efficiency of their offshoring projects and processes. 3. Are new to offshoring, but realize its benefits if executed properly. So should U.S.-based companies offshore? The simple answer is yes, but the trick is to treat offshoring as a very complex project and not a simple task. All of the preparation steps required for starting a complex project such as in-depth research and planning, input from qualified resources, and appropriate project management plans and documentation must be considered. The ABCs Partner Selection Notice the title of this section is Partner Selection and not Offshore Company Selection. You need to find an offshore partner who has some experience with offshoring, but is also flexible to listen and learn new ideas for making improvements to outdated business processes. Every business is unique and has a set of requirements that only applies to what they do and how they do it. Your offshoring partner needs to work with you to ensure a successful project completion. The simple attitude of we always do it this way and it s the best method is not appropriate and can lead to significant issues down the road. We recommend selecting an offshore company that is between 150 to 300 resources strong with at least 5 years of proven offshore development experience. It is best to look for companies managed by people who have studied and worked in the U.S. The key point is that you both need to be comfortable and familiar with each other s way of doing business.

4 Internal Changes Required This may surprise some, but in order to send a project offshore, you need to make changes to the way your organization is managed. Offshoring software development projects can quickly remind you of the meaning of garbage in, garbage out and its consequences. Chances are your internal departments will need to improve documentation quality and volume. Unless your requirements are completely defined in writing and discussed by onshore and offshore resources, offshore developers should not even attempt to write a single line of code. Recommended Internal Changes Prior to sending any work offshore, it is extremely important to: 1. Have clear and detailed requirement documents. 2. Have clear and detailed design documents. 3. Have clear test scripts. 4. Have a clear definition and metrics for project success including timelines. 5. Create work order forms for authorizing and controlling project activities. 6. Monitor daily progress. 7. Put checks and balances in place to ensure no one team can cause your project to fail. In a nutshell, you need to make sure all involved communicate properly and frequently and there is an electronic paper trail for all decisions made. Tools such as spreadsheets, online wikis, and can all be used to accomplish this. Resource Selection As described above, offshoring is a major project. In our opinion the best way to resource the project is the following: 1. Have one or more resources in the U.S. responsible for all communication with your offshore partners. The U.S.- based team, the Communicators, will be responsible for accepting projects from all U.S.-based departments and forwarding them offshore. The Communicators will also be responsible for reviewing the requested work and should have the authority to send the work back to the U.S.-based departments for rework or additional required information. The Communicators need to be well-organized and must understand your business and your technology. Most importantly they need to establish strong ties with your offshore partners. 2. Make one offshore resource, the Offshore Distributor, responsible for accepting work from the U.S. This person distributes the work amongst the offshore resources. It is very important for this resource to have strong communication and technical skills. 3. Interview each offshore developer to make sure they satisfy your company s proficiency requirements. Do not accept working with offshore developers that can be categorized as moderately proficient. They need to be as strong as your onshore team and they must pass your technical interview. 4. Assign an offshore resource to test the work performed by offshore developers in accordance with the provided test scripts. At times this responsibility can be assigned to the Offshore Distributor.

5 High Level Procedure Following the process outlined below should assist you with assigning projects successfully offshore: 1. Create an alias for the Communicators and have all U.S.-based resources use it to assign work offshore. 2. Create work order forms and make it policy for everyone to use them. s assigning work to the Communicators should include the following: a. Functional description of the activity to be completed. b. Design outlining which components are to be created or modified. c. Test cases with clearly defined test criteria and success metrics. d. Estimated activity duration. 3. The work order should be reviewed by the Communicators and feedback should be provided to the U.S.-based team. This ensures there is a clear understanding regarding the nature of the work that needs to be done. The Communicators should be free to challenge the activity duration as well as any other work order content. Upon acceptance of the work by the Communicators, the activities are assigned to the offshore team and the progress tracked by the Communicators on a daily basis. Progress can be monitored using tools such as a progress spreadsheet accessible to all parties. 4. All changes or enhancements to the work after the initial acceptance should be considered a new assignment and must be reviewed, reassessed, and accepted by all parties involved. 5. The ONLY point of contact for all offshore resources should be the Communicators. In situations where this method is not feasible, the Communicators should be made aware of all discussions with offshore resources. Furthermore they should be copied on ALL project-related s. 6. The Communicators should produce a status report at least once a week or when 50% of the work is completed, whichever comes first. 7. The Communicators should make arrangements to demonstrate the progress of the project at least once during the development life cycle, typically when 50% of the work is done a. At the end of each demonstration the project owner should send his or her input in writing to the Communicators. 8. Once the activities are completed, the Communicators should unit-test the product and upon approval arrangements should be made to demonstrate the completed work to the project owner. Figure1 Although sharing of information is obviously bidirectional, Figure1 above depicts the flow of information from the U.S based company to the offshore partner. Conclusion Offshoring is here to stay and increasing especially in this current market climate. After all it is the preferred software development solution for many CIOs and CFOs. It is in our best interest as IT professionals to understand and apply a

6 consistent approach to handle these complex projects to realize all the benefits of offshoring. Communication between all team members is of paramount importance and should be stressed throughout the project. Without the key role of the Communicator, the likelihood of the project coming to a successful conclusion is severely hampered. However, by following the simple and elegant process we have described, your chances of success are enhanced. We wish you all the best with your future offshoring initiatives. About Alvand Solutions - At Alvand Solutions, we strive to deliver significant value to organizations through the innovative implementation and support of IT solutions. Our Offshore Development Management, Enterprise Data Protection, Application Development Services, and IT Services offerings will help secure your return on investment. We offer consulting and educational services to equip your team with the skills and knowledge to bring your offshoring projects to a successful conclusion. Our team includes professionals with significant industry and related information technology experience. For more information please visit our website at or phone Alvand Solutions, LLC. All rights reserved. All product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. These materials are subject to change without notice. These materials are provided by Alvand Solutions and its affiliated companies for informational purposes only, without representation or warranty of any kind, and Alvand Solutions shall not be liable for errors or omissions with respect to the materials. The only warranties for Alvand Solutions products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.