Embed Size (px)
DESCRIPTION
How do companies manage distributed software development in outsourcing situations?
Citation preview
Editors: Slinger Jansen and Sjaak Brinkkemper
Distributed Product Software Development
U t r e c h t U n i v e r s i t y P O B o x 8 0 . 0 8 9 3 5 0 8 T B U t r e c h t T h e N e t h e r l a n d s
1 Table of Contents
2 INTRODUCTION TO DISTRIBUTED PRODUCT SOFTWARE DEVELOPMENT ... 7
3 COOPERATING ORGANIZATIONS ................................................................ 8 3.1 NETROM ....................................................................................................................... 8 3.2 SERVOY ........................................................................................................................ 8 3.3 NOKIA SIEMENS NETWORKS ........................................................................................ 9 3.4 UNICONNECT ............................................................................................................. 10 3.5 NAPOCA ..................................................................................................................... 10 3.6 ACISION ..................................................................................................................... 11 3.7 INSIDE ........................................................................................................................ 12 3.8 LEVI9 ......................................................................................................................... 12 3.9 UNIT4AGRESSO .......................................................................................................... 12 3.10 OCÉ .......................................................................................................................... 14
4 OUTSOURCING GOVERNANCE MODELS AND CONTRACTS ........................ 15 4.1 PARTNERSHIPS IN OUTSOURCING ............................................................................... 16 4.2 OUTSOURCING GOVERNANCE .................................................................................... 18
4.2.1 Governance models ......................................................................................................... 18 4.2.2 Buy ............................................................................................................................... 21 4.2.3 Joint Venture ................................................................................................................. 21 4.2.4 Alliance ......................................................................................................................... 22 4.2.5 Development center ......................................................................................................... 22 4.2.6 Build-Operate-Transfer ................................................................................................... 23 4.2.7 Build ............................................................................................................................. 23 4.2.8 Staff Augmentation ........................................................................................................ 23 4.2.9 Outsourcing Governance Model ....................................................................................... 24
4.3 TRANSACTION COST THEORY...................................................................................... 24 4.3.1 Asset Specificity .............................................................................................................. 25 4.3.2 Uncertainty ................................................................................................................... 25 4.3.3 Recurrence ..................................................................................................................... 26
4.4 EVOLVING THE BUSINESS MODEL AND GOVERNANCE ALIGNMENT ............................. 27 4.5 CONTRACTS ............................................................................................................... 28 4.6 CONTENTS OF A CONTRACT ........................................................................................ 29
4.6.1 Pricing .......................................................................................................................... 29 4.6.2 Incentives....................................................................................................................... 30 4.6.3 Administration control .................................................................................................... 30 4.6.4 Contract duration ........................................................................................................... 30 4.6.5 Early termination ........................................................................................................... 30 4.6.6 Rights to dispute charges ................................................................................................. 31 4.6.7 Ownership of intellectual property rights ........................................................................... 31 4.6.8 Information security and confidentiality ........................................................................... 31 4.6.9 Excuse doctrine, warranty and liability ............................................................................ 31 4.6.10 Renegotiation ............................................................................................................... 31
4.7 CONTRACT MODELS AND CONTRACT FLEXIBILITY ...................................................... 32 4.7.1 Fixed Price .................................................................................................................... 32 4.7.2 Time-and-Materials ....................................................................................................... 32 4.7.3 Progressive ..................................................................................................................... 33 4.7.4 Target Cost .................................................................................................................... 33 4.7.5 Profit Sharing ................................................................................................................ 35
4.8 RELATED WORK AND FURTHER READING ................................................................... 36 4.9 CASE STUDY - UNICONNECT ....................................................................................... 36
4.10 GENERAL REMARKS AND LESSONS LEARNED ........................................................... 37 4.11 REFERENCES ............................................................................................................ 38
5 EVALUATION AND SELECTION OF OUTSOURCING PARTNERS ................... 40 5.1 CRITERIA .................................................................................................................... 40
5.1.1 Partner-related criteria .................................................................................................... 41 5.1.2 Task-related criteria ........................................................................................................ 41 5.1.3 Searching for potential partners ....................................................................................... 42
5.2 PRELIMINARY SELECTION........................................................................................... 43 5.3 PARTNER ASSESSMENT ............................................................................................... 45 5.4 PARTNER NEGOTIATION ............................................................................................. 46 5.5 SIGNING CONTRACTS ................................................................................................. 46 5.6 CONCLUSION .............................................................................................................. 48 5.7 LITERATURE ............................................................................................................... 48
6 MANAGING TRANSITION TO A NEARSHORE LOCATION ............................ 49 6.1 BACKGROUND ............................................................................................................ 49 6.2 KNOWLEDGE TRANSFER ............................................................................................. 50 6.3 CHANGE MANAGEMENT ............................................................................................. 50
6.3.1 Governance .................................................................................................................... 50 6.3.2 Another perspective ......................................................................................................... 51
6.4 THE TRANSITION PROCESS ........................................................................................ 51 6.4.1 Initiation ....................................................................................................................... 51 6.4.2 Ramp-up ....................................................................................................................... 52 6.4.3 Main transition .............................................................................................................. 52 6.4.4 Wrap-up ....................................................................................................................... 52
6.5 TRANSITION MODEL ................................................................................................... 52 6.5.1 The best way to do the main transition ............................................................................. 53
6.6 CASE STUDIES ............................................................................................................ 54 6.6.1 Case study Company A .................................................................................................. 54 6.6.2 Case study Levi9 ........................................................................................................... 54
6.7 A GENERIC PROCESS ................................................................................................... 55 6.8 LESSONS LEARNED ..................................................................................................... 55 6.9 REFERENCES .............................................................................................................. 56
7 OUTSOURCE PLANNING AND COST EVALUATION METRICS FOR PRODUCT SOFTWARE VENDORS .................................................................................... 57
7.1 OUTSOURCE PROJECT PLANNING ............................................................................... 58 7.2 COMMUNICATION ...................................................................................................... 59 7.3 DESIGN SPECIFICATION .............................................................................................. 59
7.3.1 Reporting ...................................................................................................................... 59 7.3.2 Monitoring .................................................................................................................... 59 7.3.3 Escalation management .................................................................................................. 60
7.4 OUTSOURCE PROJECT COST ESTIMATION ................................................................... 60 7.5 COST ESTIMATION IN A NEARSHORING CONTEXT ....................................................... 61
7.5.1 Measuring processes ........................................................................................................ 61 7.5.2 Measuring outputs .......................................................................................................... 62 7.5.3 Key Performance Indicators ............................................................................................. 62 7.5.4 Service Quality ............................................................................................................... 63 7.5.5 Financial ....................................................................................................................... 63 7.5.6 Relationship .................................................................................................................. 64 7.5.7 Strategic Metrics ............................................................................................................ 64
7.6 OUTSOURCE SERVICE LEVEL AGREEMENTS ............................................................... 64 7.7 SOME LESSONS LEARNED ............................................................................................ 65 7.8 REFERENCES .............................................................................................................. 66 7.9 APPENDIX .................................................................................................................. 67
8 REQUIREMENTS ENGINEERING AND RELEASE PLANNING ........................ 70 8.1 REFERENCE FRAMEWORK .......................................................................................... 70 8.2 REQUIREMENTS .......................................................................................................... 72
8.2.1 Requirements management ............................................................................................. 73 8.2.2 Requirements engineering ............................................................................................... 74 8.2.3 Requirements communication ......................................................................................... 75
8.3 REQUIREMENTS MODELING ........................................................................................ 76 8.3.1 Requirements analysis .................................................................................................... 79
8.4 RELEASE PLANNING ................................................................................................... 79 8.5 BUSINESS CASE ........................................................................................................... 82 8.6 CONCLUSION .............................................................................................................. 84 8.7 REFERENCES .............................................................................................................. 84
9 DISTRIBUTED SOFTWARE DEVELOPMENT ................................................ 86 9.1 THE IMPORTANCE OF COMMUNICATION ..................................................................... 90 9.2 DISTRIBUTED VERSION AND RELEASE MANAGEMENT ..................................................................... 90 9.3 DISTRIBUTED COMPONENT BASED SOFTWARE ENGINEERING (DBSE) .............................................. 91 9.4 DELIVERABLE MANAGEMENT .................................................................................................. 91 9.5 PRODUCT DOCUMENTATION .................................................................................................... 91 9.6 SOFTWARE ENGINEERING METHODS ......................................................................................... 92
9.6.1 Waterfall ....................................................................................................................... 92 9.6.2 Agile Development Methods ............................................................................................ 93
9.7 USING A DEVELOPMENT METHOD IN A NEARSHORED CONTEXT ................................. 93 9.8 CODING MANAGEMENT .............................................................................................. 94
9.8.1 Code standards ............................................................................................................... 94 9.8.2 Code reviewing ............................................................................................................... 94
9.9 TOOLING .................................................................................................................... 94 9.9.1 Instant Messaging ......................................................................................................... 94
9.10 CALLING .................................................................................................................. 95 9.10.1 Emailing ..................................................................................................................... 95 9.10.2 Remote Desktop Applications ........................................................................................ 95 9.10.3 Project management systems .......................................................................................... 95 9.10.4 Integrated Developing Environments .............................................................................. 96 9.10.5 Code Respositories/ Version Control Systems ................................................................. 96
9.11 CASE STUDY ............................................................................................................. 96 9.12 LITERATURE ............................................................................................................. 97
10 SOFTWARE QUALITY ASSURANCE IN A DISTRIBUTED DEVELOPMENT ENVIRONMENT .............................................................................................. 98
10.1 DEFINING QUALITY ................................................................................................. 99 10.2 PLANNING SOFTWARE QUALITY ASSURANCE ........................................................ 101 10.3 QUALITY ASSURANCE AND THE SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) .. 103
10.3.1 Documentation .......................................................................................................... 106 10.4 SOFTWARE QUALITY STANDARDS .......................................................................... 107
10.4.1 External Quality Standards and Models ....................................................................... 108 10.5 THE PRACTICAL IMPLEMENTATION – CASE STUDY ................................................. 110 10.6 CONCLUSION .......................................................................................................... 115 10.7 REFERENCES .......................................................................................................... 116
11 DISTRIBUTED SOFTWARE TESTING IN PRACTICE ................................... 118 11.1 SOFTWARE TESTING INFRASTRUCTURE ...................................................... 119 11.2 MANAGING TESTING PROCESS IN PRACTICE .............................................. 120 11.3 COMMON TESTING TECHNIQUES .................................................................. 121 11.4 TECHNIQUES AND TOOLS ................................................................................ 123 11.5 CASE STUDY ........................................................................................................... 126
11.5.1 Netrom ...................................................................................................................... 126
11.5.2 Acision ...................................................................................................................... 127 11.5.3 Levi9 ......................................................................................................................... 130
11.6 CONCLUSION AND LESSON LEARNED .......................................................... 138 11.7 REFERENCES ...................................................................................................... 139
12 SOFTWARE MAINTENANCE IN OUTSOURCED PROJECTS ........................ 141 12.1 OUTSOURCED SOFTWARE MAINTENANCE OVERVIEW ............................................. 142
12.1.1 Definitions ................................................................................................................. 142 12.1.2 Categories .................................................................................................................. 142 12.1.3 Software maintenance approaches ................................................................................ 143 12.1.4 Software Maintenance processes ................................................................................... 144
12.2 ROADMAP FOR IMPLEMENTING SOFTWARE MAINTENANCE .................................... 146 12.3 TRANSITION MANAGEMENT ................................................................................... 149 12.4 LEVI 9 (OUTSOURCED COMPANY) CASE STUDY: ..................................................... 149
12.4.1 Transition plan stages ................................................................................................. 149 12.4.2 Transition processes .................................................................................................... 150 12.4.3 Proposed Transition Team .......................................................................................... 152
12.5 ACISION (OUTSOURCER COMPANY) CASE STUDY: .................................................. 154 12.6 MAINTENANCE MANAGEMENT .............................................................................. 155 12.7 SUPPORT AND MAINTENANCE MANAGEMENT TECHNIQUES ................................... 159
12.7.1 Event Management .................................................................................................... 159 12.7.2 Incident Management ................................................................................................. 160 12.7.3 Problem Management ................................................................................................. 160 12.7.4 Request Fulfillment .................................................................................................... 161
12.8 RELEASE MANAGEMENT ........................................................................................ 161 12.9 GEC CASE STUDY .................................................................................................. 163 12.10 CONCLUSION AND LESSONS LEARNED .................................................................. 164 12.11 REFERENCES ........................................................................................................ 165
13 KNOWLEDGE MANAGEMENT FOR DISTRIBUTED PRODUCT SOFTWARE DEVELOPMENT ............................................................................................ 167
13.1 KNOWLEDGE MANAGEMENT IN DISTRIBUTED SOFTWARE PRODUCT DEVELOPMENT 167
13.1.1 Tacit Vs Explicit knowledge ........................................................................................ 168 13.1.2 Personalization Vs Codification of the knowledge .......................................................... 168
13.2 KNOWLEDGE TRANSFER ........................................................................................ 169 13.3 KNOWLEDGE MANAGEMENT IN THE SOFTWARE DEVELOPMENT PROCESS ............. 170
13.3.1 Domain Knowledge .................................................................................................... 170 13.3.2 Requirements ............................................................................................................. 171 13.3.3 Design ....................................................................................................................... 171 13.3.4 Implementation .......................................................................................................... 171 13.3.5 Testing ...................................................................................................................... 171 13.3.6 Deployment ............................................................................................................... 172 13.3.7 Maintenance .............................................................................................................. 172
13.4 HOW TO SUCCESSFULLY TRANSFER KNOWLEDGE TO AN OFFSHORE LOCATION ...... 172 13.5 HOW CULTURE AND TRUST MATTERS IN KNOWLEDGE TRANSFER .......................... 174 13.6 KM TOOLS ............................................................................................................. 175
13.6.1 Document and content management ............................................................................ 176 13.6.2 Collaboration services ................................................................................................. 176 13.6.3 Expert Networks ......................................................................................................... 176 13.6.4 Knowledge Portals ...................................................................................................... 177 13.6.5 Customer Relationship Management Tools................................................................... 177 13.6.6 Competence management ............................................................................................ 177 13.6.7 Product Management ................................................................................................. 178 13.6.8 Source code repository ................................................................................................. 178
13.7 CASE STUDY: E-SYNERGY AT EXACT SOFTWARE – STATE OF THE ART OF A SOFTWARE KNOWLEDGE BASE (SKB) ................................................................................................. 178 13.8 CASE STUDY: ACISION EXPERIENCE WITH A TROUBLESOME PROJECT TRANSFER. ... 180 13.9 CONCLUSION .......................................................................................................... 181 13.10 LITERATURE ......................................................................................................... 182
14 MANAGING PEOPLE IN A DISTRIBUTED DEVELOPMENT......................... 184 14.1 LAYING THE FOUNDATION ..................................................................................... 184 14.2 CHANGE MANAGEMENT ......................................................................................... 186 14.3 GOVERNANCE ........................................................................................................ 187 14.4 THE OFFSHORE TRANSITION .................................................................................. 188 14.5 PEOPLE MANAGEMENT .......................................................................................... 188 14.6 ORGANIZATION BEHAVIOUR ................................................................................... 189
14.6.1 Selecting the right person for the job ............................................................................. 189 14.6.2 The recruitment process ............................................................................................... 190
14.7 RECRUITMENT PROCESS CASE STUDY 1 ................................................................... 190 14.7.1 Instruction and members introduction best practices ...................................................... 192
14.8 CULTURE ................................................................................................................ 192 14.9 MOTIVATION AND REWARD ................................................................................... 193 14.10 INDIVIDUAL MOTIVATION: CASE STUDY 2 ............................................................ 194
14.10.1 Methods of improving motivation .............................................................................. 195 14.10.2 Managing groups in an offshore project ...................................................................... 195 14.10.3 Becoming a team ...................................................................................................... 195 14.10.4 Group composition ................................................................................................... 196
14.11 GROUP COMPOSITION: CASE STUDY 3 ................................................................... 196 14.11.1 Communication within an offshore project group ......................................................... 197
14.12 PEOPLE EVALUATION ........................................................................................... 199 14.13 SKILL IMPROVEMENT ............................................................................................ 201 14.14 CONCLUSION ........................................................................................................ 202 14.15 REFERENCES ........................................................................................................ 203
15 GLOSSARY ............................................................................................. 206
2 Introduction to Distributed Product Software Development Thank you for picking up this copy of the distributed product software development book. This book is the result of a summer school trip in 2008, when 11 students and two professors went on a journey to Eastern Europe to discover the ins and outs of distributed product software development.
The copy you are holding now is unique in that it is not finished. At present it is a collection of different chapters that handle several hot topics in distributed software development. You might find small inconsistencies in the lay-out or topics being discussed twice. These inconsistencies will be eliminated from the book in its next version. Please feel free to mail us all your comments and problems before the book goes into press, early 2009.
This book has been created with the financial support of Utrecht University and of several sponsors (see logos). Once again, we are greatly thankful for their support. Finally, the book could not have been created without the products of our brilliant students.
We hope you find the material in this book insightful,
Slinger Jansen and Sjaak Brinkkemper
Utrecht University
Copyright 2008
3 Cooperating Organizations For the course Business informatics Summer school (INFOBISS), a group of students with their lecturers took a trip to a number of companies and universities in Eastern Europe. Those companies were carefully chosen because of the kind of business they do which corresponds to the subjects these students were researching. This document gives you a view inside those visited companies. Most of the information in these descriptions comes from the companies’ websites or from information students collected while visiting those companies.
3.1 Netrom NetRom is a software company based in Romania. They build software for Dutch and Belgian clients, mainly small to medium-sized software houses or IT departments of large companies. Their main focus is on offshore software development. Or rather: nearshore, because NetRom is located nearby in Continental
Europe. This has important advantages when it comes to bridge the geographical distance and cultural gap. The name NetRom is comes from Net(herlands) and Rom(ania). As a Dutch software developer, NetRom has a Dutch office near Breda, while the Romanian operations are in Craiova, in southwest Romania.
NetRom has a Dutch Managing Director in Romania. The corporate culture is also mainly Dutch, but English speaking employees facilitate also the communication with clients. NetRom understands the needs and requirements of its clients and can provide them with effective solutions. NetRom works with a team of 70 highly qualified programmers, graduates from the two universities in Craiova. Each programmer is specialized in a particular area. By working together in project teams.
The strength of NetRom is a combination of three elements: Building software in Romania is very competitive and is characterized by a low cost
price. NetRom programmers are highly professional and experts in their fields. The software
meets therefore the highest standards. Good communication, knowledge transfer and implementation of the development
process are supported at NetRom by their framework for Offshore Software Development: ODF.
3.2 Servoy Servoy is a privately-held company established to develop, sell and support the Servoy suite of products. Servoy markets an application development and deployment environment used to create and deploy user
interface applications.
The idea for Servoy started in 1998 by the four co-founders of the company; being frustrated with the limitations of desktop database tools on one hand; and the complexity of web-based development tools, the steep learning curve, and the long development time on the other, The co-founders decided to build an enterprise- ready development and
deployment environment based on industry standards that would enable developers to build solutions even faster than with desktop database tools.
By 2002, the first beta version was ready; and by April 2003, the first commercial bundle of Servoy was shipped. Servoy Developer and Servoy Smart Client are compatible with virtually all computer platforms; and can connect to multiple and/or different SQL databases at the same time.
In addition to the rich Servoy Smart Client that first shipped in 2003, a new Servoy Headless Client has been introduced to facilitate browser-based applications. Today over 1500 companies and more than 10,000 developers are working with the Servoy product suite. Companies like Symantec; Stanford University; Verizon; and UCLA hospital rely on Servoy for managing and presenting data to their customers and employees through rich applications over the LAN, WAN and Internet connections. The Servoy worldwide headquarters is located in The Netherlands (Amersfoort) where all research and development; as well as international sales and marketing activities are centralized and coordinated.
3.3 Nokia Siemens Networks Nokia Siemens Systems is one of the world’s largest network communications companies with 60,000 employees and a leading position in all key markets across the world. With continuous innovation, precise insight and in-depth expertise, the company helps their customers unlock the potential of a connected world
and also to unite communities.
Nokia and Siemens were competitors but decided to start a joint-venture called “Nokia Siemens Systems”. The Budapest office is the outsource location for the Helsinki headquarters. Budapest has been around for almost 10 years. The Helsinki office contains about 80 people in R&D and some in Project Management (PM) and Architecture. The work is split in logical parts so nothing is really done “Together”.
The customers of Nokia Siemens Systems require end-to-end solutions; and the pace of their requirements will accelerate in the future. Nokia Siemens Systems can help change the way they do business and capture value. They listen to their customers, innovate together and solve their customers’ most pressing business challenges. Nokia Siemens Systems bring the benefits of scale and global reach, plus a deep understanding of operator business, an industry-leading research and development organization, and a wide range of services, products and solutions to our customers. But, to succeed in a rapidly evolving communications industry, scale is not enough. Therefore, they are building an organization and culture that constantly evolves to address the customers’ key challenges and lead industry change.
The explosive growth of network and Internet traffic, both in terms of bandwidth and subscribers, represents a great opportunity for operators and equipment providers. However, the legacy of the traditional telecoms business has resulted in complex and partly overlapping network layering and architecture. The complexity of network architecture is not just a technical issue. It is a highly prominent business challenge for most of their customers. Therefore, Nokia Siemens Systems drive the transition towards
simplified network architecture enabled through innovative, environmentally sustainable solutions that enable rapid growth.
3.4 UniConnect
Based on the growing need for assistance for Dutch investments on the West Romanian market, the Dutch-Romanian company "SC Uniconnect SRL" was established in 2003. In order to reduce uncertainty in starting or expanding entrepreneurial activities and to use the attractive opportunities to invest in West Romania, Uniconnect informs, supports and guides Dutch investors to
establish their business and to help them grow towards a successful enterprise.
The continuously growth of the Romanian economy and the accession in the European Union open a lot of opportunities for Dutch investors to start activities on the Romanian market and to start business partnerships. Therefore the Netherlands has represented for many years a top position in the capital invested in Romania. Romania offered a lot of opportunities if you know the way on the market.
Uniconnect’s network covers more than 500 people and organizations in West Romania. Besides that, they are working together with main institutions like local Chambers of Commerce, financial institutions, business clubs and trustworthy accountants and lawyers, real estate agents and other important organizations in the field of trade promotion in Romania. But Uniconnect does not only link Dutch and Romanian businesses with each other, it offers a wide range of business solutions.
Owing to their firsthand experience with the Romanian market and corporate culture, UNICONNECT can furnish well-advised management support or refer you to local specialists and organizations to provide the solutions you need. For your present and future business initiatives to transform into viable projects with a high succeeding potential, UNICONNECT offers full services, from the making of a viable business plan, continuing with the company's foundation and going through all the steps necessary to its functioning (legally wise, accountancy, human resources, marketing)
The values of UNICONNECT are clear communication, trustworthiness, honesty and integrity. Their activities are focused on investing in long-lasting relationships in order to develop sustainable Dutch-Romanian partnerships. They want to form a bridge between the Dutch and Romanian culture, using each other’s strong points to strive for the maximum success.
3.5 Napoca Napoca Software is a privately owned Romanian company established in 2003 in Cluj-Napoca, Romania, by a group of young, enthusiastic engineers, both graduates of Technical
University as well as graduates of Babes-Bolyai University, people that gained more than 7 years of experience in the software industry, as they have been working in both Romanian and joint capital companies. In the summer of 2004, Napoca Software acquired MediaSoft Cluj-Napoca and its portfolio of clients, establishing Napoca Software House.
In the summer of 2004, Napoca Software joined the Microsoft Empower Program and became a Microsoft Partner, with the declared purpose of growing to be a Microsoft Certified Partner. In 2005 Napoca Software joined ANIS (Employer’s association of the software industry and services).
The vision NAPOCA Software consists of The way they perceive a market’s specific information, its implication and evolution, the way they understand its nature and principles, their wisdom and ability to interpret it, all these can affect whether we enter a market or not and whether we survive on that market. To cope with the continuously increasing quantity of information, the permanently changing market environment, they require powerful and reliable software solutions.
By means of their products and services they aim to be recognized as a company that provides intelligent software solutions, a trustful partner that always offers its clients the support they need to be efficient and competitive. (software, 2008)
3.6 Acision
Acision is the world’s leading messaging company, providing communication solutions for over 300 network operators and service providers globally. As the messaging partner of choice, their proven products
and services, experienced people and leading service innovation allow organisations to meet the challenges in today’s converging telecommunications market. Acision is at the heart of their customers’ strategic business services, working together to enable them to achieve profitable and sustainable growth.
Acision recognised innovation and expertise in both messaging and charging extends across a portfolio of propositions, products and services. It is based upon a global track record, unique business insight and leading edge technology platforms.
Acision enables more than 300 customers to serve over 1.5 billion consumers in 135 countries across six continents. They deliver more than half of the world's text and multimedia messages and serve three quarters of all videomail users. They were the first to enable management decision making based on real time analysis of subscriber behaviour. Their mobile payment systems have enabled their global customers to secure more than US $100 billion of revenues. Acision enabled the TV show American Idol to interact with a record breaking 60 million voters, generating additional revenues and content sales. Building on this proud heritage of assuring innovation, Acision continues to invent, evolve and deliver solutions that empower their customers to seize new opportunities and success.
Acision is the partner of choice in high volume mobile data services for the world’s leading network operators and service providers, with over 50 per cent of global messaging traffic generated through our platforms. For over 15 years Acision has been driving mobile messaging revenue growth, giving them a unique understanding of what it takes to bring innovative and differentiated services to full mass market adoption.
3.7 Inside Inside Software is a Romanian Software Company, founded in February 2004, providing innovative IT services for businesses in a wide range of industries. At Inside, the human element is highly
esteemed; they truly value and respect their team members. They strive to create and sustain a stimulating and collegial working environment that is both engaging and challenging to our developers. The people at Inside are encouraged to be creative and explore without preconceptions new perspectives of thought. Innovation is priced and accordingly rewarded.
The respect for the individual is one of their most valued principles. Inside embrace diversity and advocate positive attitudes such as openness, sharing, trust, teamwork and involvement. Inside take pride in fostering courage, creativity and discipline, assets that help them lead change and shape the future. However they do understand that life should never be all work and no play. That is why they have searched for, and found a healthy balance between hard work and enjoyable interludes. Inside has created a collaborative working environment, which gives their team members the opportunity to relax and bond as people as well as work colleagues.
3.8 Levi9
Levi9 Global Sourcing was founded in 2001 and has grown to a full blown IT group with development centres in Serbia, the Ukraine, Turkey and Romania and sales offices in Belgium, Germany, United Kingdom and the Netherlands The founders of Levi9 are Menno de Jong, Paul Mol and Bernhard van Oranje. After graduating from
Groningen they have founded several companies of which one was Clockwork that was acquired by Ordina in 2003.
The management team of Levi9 is Gijs de Rooy, Peter Sminia, Menno de Jong en Bernhard van Oranje. Levi9 Global Sourcing's Board of Advisors is comprised of industry and academic leaders whose broad knowledge and experience help the Company achieve continued success in the fast growing market of offshore IT services. The Board includes Roel Pieper, Adrie Reinders and Willem Vermeend.
3.9 Unit4Agresso
Unit 4 Agresso develops, sells, implements and supports business software for the management, support and optimization of business operations and for the optimization of the operational
management. Unit 4 Agresso has leading international market positions in the public sector and in the professional and business services sectors. In the Benelux Unit 4
Agresso also have strong market positions in the wholesale trade and distribution sectors and in the market for accountancy firms.
Unit 4 Agresso is a leading international producer of business software for public and private sector organizations. The group has 3,500 staff in 19 countries across Europe, North America and Asia-Pacific and sales activities in other countries around the world. With 2007 sales of €321 million, Unit 4 Agresso is headquartered in Sliedrecht, the Netherlands and publicly traded on Euronext Amsterdam (Symbol: U4AGR).
Unit 4 Agresso develops sells implements and supports business software for the management, support and optimization of business operations and for the optimization of the operational management. With its leading international product Agresso Business World, Unit 4 Agresso directs itself primarily at the market which it defines as BLINC: Businesses Living IN Change. These are people-oriented companies and institutions where frequent changes in internal and external factors are inherent in the strategy. The competitive advantages of Agresso Business World are:
• Specialization per business sector, which largely eliminates the need for customization
• Permanent flexibility following implementation, which ensures quick modifications in case of changes within the organization and enables direct management of change processes
• Short implementation time, which makes Agresso Business World quickly available
• Extensive and flexible reporting facilities
• Low total cost of ownership
With Unit 4 AccountAnalyser Unit 4 Agresso has an international product for accountancy firms and end users. The internationalization of Agresso Wholesale, for the wholesale and distribution sector, is under development.
In the Benelux and on a smaller scale in a number of other countries, Unit 4 Agresso offers business software for small and medium-sized enterprises (SME) and various sectors, such as the wholesale trade and distribution, health care and accountancy. In addition, a range of functionalities is offered for personnel information and salary management. All applications have extensive facilities for reporting and management information. In the Netherlands this offer is complemented by ICT-services and internet activities. Unit 4 Agresso offers its clients the following total range of services:
• Professional services: projects and implementations
• Secondment: for network or system management
• Outsourcing: complete outsourcing of the IT network management
• Products and licences: advice, registration, administration and/or complete contracts management in the area of products and licences
Unit 4 Agresso develops websites and advises its clients with regard to the design and implementation of websites. The range of services was expanded in 2006 with concept
development, so we can also advise our clients at a strategic level on the deployment of the internet as a communication medium.
3.10 Océ Océ is a multi-national corporation with a tradition of more than 125 years, having its headquarters in the Netherlands. Océ has officially established a software R&D competence centre in Timisoara, Romania on February 3, 2005, as part of a long term commitment. Océ is one of the important players on the local software market, with currently (spring 2007) 70 employees, in a constant growth process.
Océ Application Software Research and Development activities at are distributed over six sites: Venlo (NL), Poing (DE), Namur (BE), Créteil (FR), Phoenix (US), and Timisoara (RO). The mission as a Competence Centre is:
• Development and implementation of exciting software projects in the professional printing environment.
• Close collaboration with the colleagues in the international Océ R&D community Responsibility for the complete product life cycle from definition phase to product maintenance
• Special focus on quality of products by rigorous test and validation during the entire development process
4 Outsourcing governance models and contracts By Wilco van Duinkerken
Outsourcing governance is the longitudinal process of growing a blind date into a happy marriage. -- Wilco van Duinkerken
Most western-european companies visited during this book’s research stated that the driver behind their outsourcing decision was the unavailability of IT professionals in their “home” country. Interesting to note is that the interviewed companies are not referring to an unavailability of affordable IT professionals but IT professionals in general. Surely, by means of extreme wages, product software companies will attract western-european developers and IT professionals but the equilibrium of interested personnel, wages and personnel productivity in Central Europe is favorable over Western Europe. Companies reported that, with a bit of luck, up to 5 suitable candidates will be found for a senior developer position using ads, recruitment offices and headhunters, while in Eastern Europe companies will find up to 50 equally suited respondents.
Freelancers or temporary employment of external developers will solve the scarcity of personnel problems in short term but will not provide companies with the benefits of long term relationships being, among others, in depth knowledge of the product, the team and the organization in general. Furthermore a long term relationship degrades the transaction costs. If a company hires a freelancer s/he will need the first couple of weeks to familiarize himself with the product in general, source codes and the organizational processes while an employee or long-term contractor can immediately takeoff.
Companies grow long-term relationships with outsourcing partners in order to gain benefits one would normally get from working with employees. Talks and emails, and the outsourcing of small tasks and short projects, provide the outsourcer with an impression of a relationships’ potential. Once the company is convinced of a partner’s future value, the relationship tightens up. The outsourcer increases the rate of outsourcing from one time assignments to larger projects, increasing its dependability on the outsourcing supplier. With the increased dependability the need for a governance structure rises. The governance structure provides a (legal) backing for all tasks and activities and helps to ensure continuation and supports an honest and fair treatment of both partners.
While the partnership evolves the requirements of the governance structure change and different options arise. On one extreme you can have a one time, temporary contract backing the development and support of a small software component. On the other extreme you might decide to marry your outsourcing provider and buy (part of) the company or even have kids and start a joint venture. Based upon various factors like the uncertainty, task specificity and the recurrence of the work different governance models are favored above others.
This chapter will provide a general introduction to the most common governance models as well as an introduction into outsourcing contracts. Furthermore the “Outsourcing Governance Model” is presented. The outsourcing governance model provides a way to structure thoughts about governance and partnerships in outsourcing and provides guidance in choosing a governance model. After reading this chapter you
will have an overview of the governance opportunities in outsourcing as well as a backing in choosing the right strategy for yourself.
4.1 Partnerships in outsourcing As with any sourcing decision, wether it’s an internal distribution of work or a division of tasks geographically spanning the globe, outsourcing includes two or more people collaborating together to achieve a goal. Studies show (Ertel, D. et. al, 2001) that over 50% of the failure stories in outsourcing have to do with flaws in the collaboration between people. Miscommunication, unclear responsibilities, no communication of the expectations and high-and-mighty or high handed behavior of managers are common reasons for a torn and damaged collaboration. Although not all of these problems can be solved by means of legal entities and contracts a governance model holds part of the key to successful outsourcing.
Before deciding on a governance structure the outsourcer has to consider what kind of outsourcing partnership it demands. Every off-shoring provider suggest to be “a partner in business” but the “level” of the partnership differs. IBM (Gerwald, H. & Helbig, K., 2006) distinguishes four different levels of IT partnerships in outsourcing: commodity, providers, partners and advisor relationships. Each of these levels has its own characteristics, governance and responsibility structures. In this chapter the idea of partnership levels is “translated” for use in a product software outsourcing context. Figure 1 depicts the four levels of partnership distinguished by IBM adapted to product software outsourcing. Each level indicates a type of partner where commodity partners occupy the low level partnerships and advisors take the high ranks.
Figure 1 Levels of outsourcing partnerships or provider types
In order to provide a feel for the levels of provider partnerships a job title is provided after the level description. The job title should be seen as a metaphor and not as a quality classification of the outsourcing partner. Commodity partners will deliver top quality work and will have seniors and tech leads on their payroll, but in general their focus is simple tasks, cost reduction and speed.
Commodity (junior)
Commodities involve tasks that are easy to explain, do not need a lot of guidance and of which the quality is easy to check. The focusses of commodity outsourcing are cost and speed. In a non-outsourced situation commodity tasks are delegated to junior developers or interns. The outsourcer itself has to maintain the “senior” or “management” role in the outsourcing relationship. An example of commodity outsourcing work is the conversion of photoshop website designs into valid HTML and CSS.
Provider (senior)
Providers function as an extension of the outsourcers work force. More and more (western-european) companies have difficulties finding enough qualified developers to do the job and need “manpower” to get the job done. Cost saving remains an issue but are seen as a “lucky extra”. The abstraction level of the tasks and requirements is higher compared to commodity work but the outsourcer will still need to provide overall management and guidance. Outsourcing partners at provider level are suited to co-develop components of the outsourcers product and extend the internal development teams with external developers.
Partner (lead)
Partners function on par with the outsourcers R&D department. They will independently work on more abstract tasks. In order to work as an extension of the internal R&D department the partner will need access to “high level” information and needs to be involved in the overall decision making. Outsourcing providers at partner level are able to solely develop a complete component of your software, they need less guidance and will actively contribute to the overall architecture of the product.
Advisor (innovator)
Advisors take the lead, provide you with new insights and match R&D with the overall company strategy. They need access to high level information and the communication with between advisor level partners and your company will be frequent and intense. Advisors function on par with product managers and possibly the CTO or CIO of the outsourcer. An example of an advisor level partnership encountered during the research for this book was a USA based medical image processing company developing a proprietary piece of hard- and software to conduct human body scans. The USA base of the company consisted of medical specialists and scientists but contained no IT specialists or software developers. The scientists and specialists came up with an innovative way of conducting the scans and processing the results but didn’t have the ability to translate their ideas into a software product. The imaging company fully relied on their outsourcing provider to create the software and consult them on IT matters.
In order to decide upon the optimal partnership level one could ask itself the basic question: “Which people / jobs will feel the work reduction once I outsource the tasks?”. When a company outsources user interface implementation tasks, well specified and documented, the reduction of work is most probably felt by junior developers. Outsourcing junior development tasks requires a commodity based partnership. However if the outsourcer decide to outsource a software component a whole development team will notice a reduction in the workload. When the outsourced activity affects a large part of a team, the outsourcing partner should match the level of the most senior function in the team which is going to be replaced or re-allocated.
Chapter 4 on the “Selection and evaluation of outsourcing partners” will provide in depth information on how to select a partner. This chapter will elaborate on the decisions the outsourcer has to make once it selected a partner level.
4.2 Outsourcing Governance Visions on governance differ. The definitions used by scholars and management book authors range from strategic all the way down to operational levels. Some definitions require a governance model to contain the “what to do”, “how to do it”, “who should do it” and “how should it be measured” for all business activities while others only specify the legal structure of the external and internal relationships of the company. In this book governance is defined as the way the outsourcer and its partner arrange the outsourcing relationship by the means of legal entities and contracts.
A sound governance model is vital to the success of an outsourcing relationship. The model provides a foundation for the amount of risk each party allocates, the amount of flexibility in the project and the amount of influence the outsourcer has on its provider. A governance model which is too tight stresses both parties, while a governance model with many open endings might cause the project to fail because of a lack of interest and clarity.
Furthermore the governance model is a tool to manage costs. Three types of costs arise in outsourcing relationships (Vining A. & Globerman, S., 1999): production, bargaining and opportunism costs. Production costs are the main and most concrete cost driver in the outsourcing relationships. The outsourcer asks the provider to conduct a certain activity and gets billed by the provider for the resources used to complete the activity.
Bargaining costs can be split into four different categories: (1) contract negotiation costs, (2) negotiations about changes in e.g. the contract or the software requirements, (3) the costs of monitoring the performance of the outsourcing provider and (4) the cost of disputes. These bargaining costs not only exist in outsourcing situations. When a company if fully “insourced” these costs exists in the form of, for example, employee contracts, budgeting, forecasts, bonuses and penalties.
Next to the bargaining and production costs there’s a third category of costs: opportunism. Opportunism is any behavior of a partner which is in its self-interest and in bad faith. Contrary to bargaining costs, where both parties try to negotiate in best interest of the relationship, opportunistic behavior intents self interest and the weakening of the other party. The relationship between opportunism and governance models is explained in the section about Transaction Cost Theory later in this chapter.
Different governance models are available to provide a way of minimizing bargaining costs and avoiding opportunism. The next sections will introduce the most common governance models and the way they relate to outsourced activities and projects. After the presentation of the “Outsourcing Governance Model” more explanation is provided on the most common outsourcing governance model: contracts.
4.2.1 Governance models
Once the outsourcer decided upon a partnership level it has to formalize the partnership. There’s a spectrum of options to consider when deciding upon a governance structure. The governance spectrum ranges from the classic “pure” model of “Build”, buying or starting a company, up to the “Buy” model, where you, to put it blankly, throw an
assignment over the fence, pay and get a product in return. In between the pure buy and build approaches the “hybrid” forms like staff augmentation and alliances arise.
Traditionally only larger companies walked down the path of setting up their own businesses or buying (part of) a company, but over the years these options also became available for small and mid-size firms. In most Eastern European IT hotspots you will find service companies that will help you with the overall process of setting up your own captive center from the ground up. This includes legal, administrative and human resource support. Problems like bribing and top-notch bureaucracy are less of a problem now than a couple of years ago. To a certain extent bureaucracy and bribing are still happening but as is proven in the case study of this chapter, you are not obliged to participate in these activities.
Figure 2 Outsourcing Governance Models
The most common forms of pure and hybrid governance as presented by Carmel and Tjia (2005) will be presented here and are depicted in figure 2. The dark rectangles in figure 2 represent the company which is outsourcing one or more if its activities: the provider. The slightly lighter rectangle with an arrow shaped side, depicts the outsourcing partner. The labels next to the line illustrating the relationship between both parties might contain two or more “P.” or “€” labels. These labels respectively represent a
product/service/knowledge (P) and a money (€) flow. Dashed lines around a company/unit depict that although the unit or team is not owned by the partner, it is fully dedicated to the firm of interest.
4.2.2 Buy
In the “buy” model (figure 2a) the outsourcer (the company of interest) pays a certain amount of money to the outsourcing provider (depicted by the “€” label) and the provider provides the outsourcer with a finished product (depicted by the “P. x” label). The “buy” model provides little to no control over the processes at the provider and is used for commodity activities, small projects of which the requirements are clear and which need little or no support over time.
Buy models normally exist in a strong market situation. In a strong market situation the specificity of the task the outsourcer is outsourcing is low and there are a lot of providers who are both willing to take the assignment and have the capacities to fulfill the requirements. Most often the reasons behind outsourcing via the buy governance model are costs and time.
4.2.3 Joint Venture
In a Joint Venture (figure 2a) two or more partners create a separate legal entity in which all partners have equity and both partners participate with knowledge and (financial) resources, getting products or knowledge in return. Examples of the knowledge gained in a joint venture are new architectural ideas, access to the experience of the partners developers or insight into complex algorithms. Products gained out of a joint venture might be “complete”, but could just as well include software libraries and components. In outsourcing the joint venture is often a partnership between a local company and the company that is outsourcing part of its activities.
The joined owning of a product in a joint venture construction can have several benefits. First of all joint ventures protect both parties from opportunistic actions and knowledge management risks, as will be explained in the sections about transaction cost theory and the evolution of the partnership and governance model. Second, joint ventures might provide the initial outsourcer with easy access to the providers “home market”. It tends to be easier to enter a software market in a country or region where you actually have an office present, including people that speak the language. Part of the joint venture deal, in the latter case, might be that the provider takes care of the internationalization of the software. The major disadvantage of joint ventures is that both partners have different objectives and organizational cultures, which might lead to conflicts of interest.
Most literature about (outsourcing) governance models presents the Joint Venture option as an intermediary model between captive centers and BOT models. However, practice seems to point into a different direction. Setting up a joint venture means that the outsourcer will relate both financially and legally with its partner. The inter-relationship makes that the outsourcer is related to illegal or borderline activities, window dressing in the administration and other malpractices of the partner company. This could result in a PR and financial scandal if actual malpractices are detected.
Most of the companies that were interviewed in the preparation of this book state that setting up a joint venture theoretically sounds like a nice idea but that a lack of trust in the partner company prevents them for doing so. Instead of using the joint-venture as an
intermediate step between the BOT and the build model, most managers consider joint ventures as a business option which extends the joint ownership of a product once the outsourcing provider reaches up to the “partner” or “advisory level”.
4.2.4 Alliance
In an alliance both partners provide resources: money and knowledge, to the alliance mostly gaining knowledge or a product out of it. The resources are not allocated to a separate legal entity but remain within the organization, often booked in a separate ledger within the distinct administrations. The financial bonds are often not specified or unclear. Larger companies tend to have a lot of “alliances” in place, some strategic, some hardly noticed and fuzzy. Once the partnership between the outsourcer and the service provider raises up to the “partner” or “advisory level” the involvement and body of knowledge of the service provider can become a critical factor in the development of the overall product.
In the relationships with the outsourcing provider becomes critical to the outsourcers’ operations the outsourcer should, in order to hedge itself against possible losses and gain the most out of the current relationship, tighten the bonds. If the provider doesn’t want external participation or when the outsourcer is not (financially) capable of participating in the service provider, alliances are an option. An alliance can, for example, consist of revenue sharing deals or the internationalization of the product in such a way that the service partner becomes a “reseller” party in Eastern Europe. This way both companies expand their product portfolio and join forces for the better.
An example of an alliance is the porting of the software of a large CRM provider onto the DB2 database platform of IBM (Gurp et al. 2005). Because of common interest both parties agreed that an alliance would be useful to extend the CRM providers’ current architecture and start supporting IBM’s DB2 platform next to currently available database options. Both IBM and the CRM provider provided resources for the adaption. IBM provided the developers while the CRM provided office space and knowledge about their own product. In good collaboration and alliance, with shared resources but no legal entity present the CRM systems was adapted for DB2.
4.2.5 Development center
When the service provider provides a dedicated “business unit” or a physical floor to the outsourcer the business unit becomes a “Development Center” (figure 2d). The outsourcer has its “own” team of people working at the remote location but is not bothered with the hiring, administration and overall business performance. A development center approach implicates that possible slack resources may be taken up by the outsourcer instead of the service provider. The flip side however is that the recurring costs of the development center are inflexible.
In the more flexible “buy” model clients have no control over the assignment of specific developers to their project or the priority the project has amongst the other projects running at the service provider. In a development center model these problems are mostly solved. Another benefit of the development center and BOT models is that, when working with a dedicated set of developers, the effort the outsourcer spends in training, increasing the developers’ knowledge of your processes and products will not go to waste once the developers are re-allocated to other projects. Furthermore, the risk that a
developer uses your brilliant algorithms or innovative designs in another project is decreased.
4.2.6 Build-Operate-Transfer
The Build-Operate-Transfer (BOT) construction (figure 3e) is the logical next step to the “Development Center” model. The client asks the service provider to set up a development center of which the client is gradually taking full ownership. The transfer process might take 3 years or more. The BOT construction has the same advantages as the development center and build strategies but tackles the start-up problems of the build model. BOTs provide a fast and relative safe way to start with high volume outsourced development, while being able to control priorities and processes, and secure the body of knowledge in the long term.
4.2.7 Build
When a company executes a “Build” strategy they start their own legal entity at an offshore location in order to gain the benefits of this particular geographic location. A second option is to buy a majority of shares in an already existing company. The “Build” strategy (figure 2f) is all about control. The moment the outsourcer fully owns a legal entity, either buy starting the development center from scratch or by acquiring an already existing company, the outsourcer is ideally in control of the people and processes. A venture that is fully controlled and managed by the “outsourcer” is called a captive center.
The increased control of a captive center also has its downsides. The strategy represents a large upfront investment and the benefits are slower compared to other governance structures. As with any start-up or new business unit, it is likely that the outsourcer will encompass startup problems. For smaller companies finding and hiring the right developers will be a challenge and when the developers are recruited and trained the risk of attrition is high. All too often developers will head off towards a larger firm once they are finished with their training.
4.2.8 Staff Augmentation
Staff augmentation can be seen as using a long distance temporary employment agency. The provider supplies labor and manages the human resource issues of recruiting, training and contracting. Augmented staff flies over to the clients’ site on a temporary work visa, although when both the client and the supplier are both from countries within the EU the visa’s probably not needed.
Staff augmentation might lead to political resistance within the company and the companies environment. It’s the most direct form of replacing local staff with “cheap labour”, causing “locals” to loose their jobs to “foreigners”. Although to a certain extent staff augmentation is executed because of cost benefits there are other reasons. Western european companies increasingly have trouble finding people with the right IT skills. This sometimes forces companies to hire people from outside their own country.
With a range of governance models present the question “How to select a governance model?” rises. Most companies which were asked about their reasoning behind their governance model answered that selecting a governance model was purely opportunity driven and that common sense shaped the relationship over time. This does not mean however that thinking about a governance model up front makes no sense. The outsource
pioneering age is ending and the market matures as does the management of outsourcing relationships. The outsourcing governance model described in the next sections will provide a guideline to choose a governance structure.
4.2.9 Outsourcing Governance Model
In classic IT literature outsourcing starts with a “make-or-buy” decision. In most articles and books the activity to outsource is seen as a distinct part of the company’s activities which could be separated as a whole e.g. network maintenance or server administration. In general product software companies outsource activities that are strongly intertwined with the rest of the R&D activities and can be seen as a core competency. The situation of product software companies therefore requires more structure and thoughts on how to choose a governance model.
4.3 Transaction cost theory Transaction costs are seen as the costs involved in setting up and maintaining a relationship or business deal. The basics of transaction cost theory (TCT) consists of the idea that companies, based upon transaction costs, choose either a market based governance solution or one of vertical integration. In this chapter vertical integration is referred to as hierarchical governance, which corresponds with the “amount of control” used in the description of the governance models in the previous section. The higher the need for hierarchical governance, the more control is demanded from the governance relationship. In outsourcing deciding between market based governance and hierarchical governance corresponds to the choice between the “Buy” and “Build” models.
The godfather of TCT, Williamson (1985, 2005), argues that a market-based governance structure, the “Buy” model, is preferable because the incentives necessary to minimize the overall costs are not possible within more hierarchical models. The basic idea behind choosing the buy model is that if there are enough suppliers who can help you the market reaction will be to offer their services to the lowest available overall costs. Mind that the overall costs in market situations do not only include the production costs, but also the costs of (re-)negotiation and maintaining the relationship by e.g. regular quality checks.
Once a company seals a deal in a buy method the rules of the market change and the outsourcer becomes vulnerable to so called opportunistic behavior and opportunity costs. Opportunism is self-interested behavior in order to gain an advantage in a relationship while the partner loses strength. Think of opportunism as signing a long term contract which was too good to be true and after signing the contract all kinds of “unforeseen” costs pop up. Although there is still a huge market of outsourcers out there, you’re bound up with the long term deal and are obliged to either live with the contract or take juridical actions.
The problem of being tied up to a partner while other potential partners can provide a better deal is also known as the “Hold-up” problem. One way to overcome the hold up problem is to search for more hierarchical governance structures like the “Build” model. The more hierarchical structures are seen as “vertical integration” of two or more companies. The more hierarchical the relationship between the customer and its provider the more the customer can control the provider after closing the deal.
The TCT provides a basic advise to outsourcers on how to shape their governance model. The theory is based on three axis: Uncertainty, Asset Specificity and Recurrence.
Using these scales the outsourcing governance model provides a guideline in choosing a governance structure.
4.3.1 Asset Specificity
Asset Specificity describes how specific the assets needed to develop the product or provide the service actually are. The more specific the assets are, e.g. highly trained database experts, the more specific the product or service to be outsourced is. A convenient way to determine the specificity is to look at the “contestability” and “complexity” of the product. In general one could state that the more contestable the market of a required service or product is, the lower is the specificity of the product (Vining, A. & Globerman, S., 1999). The same holds for a products complexity. The lower the complexity, the lower the overall specificity.
A contestable market is a market where only a few firms or trained professionals are immediately available to provide the required services but a lot of companies would want to do the job once the price exceeds a certain limit. Take for example the development of a CRM database. Only a relative small amount of companies are specialized in CRM databases, however, once the price is set to the right level, any company with enough database skills will enter the market as a CRM system developer. The second factor in the contestability of the market is determined by the the ability of the outsourcer to actually start in-sourcing again. If the outsourcer can easily find and contract employees with the right skills to regain and continue working on the outsourced component the market for the required service is highly contestable.
The complexity of the to be outsourced product or activity is mainly defined by the degree of difficulty in specifying and monitoring the requirements and the results. Vening & Globerman (1999) split products and services into three categories: Search, Experience and Post-Experience Goods. Search goods are goods of which you know the quality and specifications up front. In IT outsourcing one rarely knows the quality and the specifications upfront since most of the times the software still has to be developed. Experience goods are goods of which the quality is known almost immediately after final delivery. The quality of post-experience goods is not measurable for a considerate amount of time if ever.
Most if not all IT outsourcing projects will fall in the experience or post-experience categories. The speed and certainty of the quality tests not only relies on the product outsourced but also on the testing processes and structures present within both your own organization as well as the provider’s offices. The better the test and quality systems the sooner a product will move from a post-experience to an experience good.
In general one can state that the more specific the product to be outsourced is, the more specific the assets are that both parties have to commit to the product. The commitment of these specific assets increases the overall risk of the project at both sides as well as stimulates the “hold-up” problem. Because of the increased risk the TCT states that the more specific the assets to be allocated are, the more the outsourcing relationships requires hierarchical coordination.
4.3.2 Uncertainty
The uncertainty involved in the outsourcing process mainly depends on the: ability to specify the requirements and quality measurements, the possible external influences on
both the outsourcer and the provider and uncertainties surrounding the contract and legal structure. The more complex the product is, the harder is gets to extensively specify the requirements and quality measurements. Uncertainty therefore in a way relates to asset specificity. The less certain the outsourcer is about the quality specifications and measurements as well as the software requirements the more uncertainty is involved in the process.
The second factor in the amount of uncertainty is the amount of uncertainty concerning the contract and a possible legal structure. When relating to business in unfamiliar countries and with different a culture companies tend not to feel sure about the legal procedures in place, nor the total honesty of business partners. The lack of trust is translated into a higher amount of uncertainty surrounding the contract and legal structures.
A third factor of uncertainty is the potential external influence on both parties. The external influence on the customers’ side might be the risk of top management stopping the project or part of the activities, the risk of decreasing budgets or strongly increasing or declining sales, changing the importance of the activity being outsourced. If the customer is likely to be affected by external influences overall uncertainty increases and the outsourcer is wise to consider a more hierarchical form of outsourcing, in order to be able to change the usage of the outsourcing relationship when external influences require change.
An external influences on the partners’ side is their vulnerability to (hostile) takeovers, other clients requesting their services, the whole termination of the company or the economic and political stability of the country and region. The higher the suspicion that an external influence affects the workings and quality of an outsourcing partner the more the outsourcing relationship would benefit from a hierarchical structure.
4.3.3 Recurrence
Recurrence refers to the amount of times the outsourcer is going to do business with its partner. Each time a new project or activity is outsourced a certain amount of costs are involved in negotiating a business deal. The negotiation costs are not problematic with single or little recurring activities but get more important with recurrent deals. Once the amount of assignments, the recurrence, increases the government model scales to more hierarchical levels. Specific notion should be taken of maintenance assignments and the maintenance of software products or components developed earlier by the outsourcing provider. A maintenance activity easily evolves into a recurring task.
By connecting the demand for hierarchical governance of the TCT with the amount of control of the governance models as described in the previous section it is possible to plot the governance models on the three axes of TCT: asset specificity, uncertainty and recurrence. Combining the governance models with TCT the outsourcing governance model is created. Figure 3 visualizes the outsourcing governance model. It displays the three axes of TCT: uncertainty, asset specificity and recurrence and the type of governance needed in order to minimize transaction costs.
As can be seen in the outsourcing governance model in figure 3 outsourcing relationships with a relatively low amount of uncertainty can be governed using flexible contracts. The next section will therefore elaborate on outsourcing contracts and more specifically on the amount of flexibility within these contracts.
Figure 3 Outsourcing Governance Model
4.4 Evolving the business model and governance alignment Most companies studied saw their level of partnership increase over time. Relationships which were started at the level of “provider” over the years grew into real partnerships or went up to advisory level. The governance structure however, was lagging behind, dating from the start of the relationship. This lag could potentially lead to uncomfortable and business threatening situations. Over time the trust between the outsourcing partners increases, the shared body of knowledge expands and processes and activities of the outsourcer and its partner align. Although this provides more comfort in the relationship it also implies the rise of contestability and switching costs. Because of the rise of constestability and switching costs it seems natural to upgrade to more hierarchical governance structures and increased partnership levels over time.
The perceived and actual relationship between a outsourcer and its partner is often not aligned with the actual governance structure. During the research conducted for this book we came across several situations where a mid-size to large outsourcer provided far over 50% up to 80% of the suppliers turnover while at the same time the outsourcing provider was the main or only contributer to the outsourcers’ product under development. When asked about the “relationship” the people working on the project often state “That the people in the Netherlands feel and act like colleagues” and “It feels like the product is ‘our baby’”. The latter statement was in general supported by the fact that most of the technical knowledge of the system was known only to the providers’ developers. The governance structure in place however didn’t exceed the “simple contracts” of a market coordinated governance model. A new contract was signed for every new project that started.
In a situation as described above a couple of things are worth noticing. First, the overall knowledge management seems to lacks a decent transfer of technical knowledge from the provider to the outsourcer, resulting in possible contestability costs, stimulating opportunism at the providers side. On the other hand, the provider is almost 100% dependent on the outsourcer business wise. When 80% of turnover and profits are generated by a single customer the economic ties make the outsourcing partner vulnerable for every R&D expense cut at the outsourcers side. A small decrease in R&D
costs at the outsourcers’ side significantly cuts down the providers’ turnover. This could result in valuable people losing their jobs, even more so because the lack of proper knowledge management drastically improves the value of the providers’ employees. As much as this is a risk for the provider, the dependency of the provider on the outsourcer also decreases the flexibility of decreasing R&D costs at the outsourcers’ side, eliminating one of the advantages of R&D outsourcing.
Another “what if” scenario that arises is a hostile takeover of the provider by one of the outsourcers main competitors. A takeover would be a devastating blow to the outsourcer. Not only would the outsourcer loose a lot of technical knowledge about its own software product, the knowledge would actually be handed over to the competitor. Furthermore, if the relationship is still governed by project based contracts, the new owner of the outsourcing partner, being a competitor or not, might decide to not accept some of the projects and transfer resources to other projects more closely related to the owners own IT portfolio.
Although not all of the problem described above can or have to be solved by a governance structure, it would be wise to align the governance structure with the actual situation. In a situation where the outsourcer strongly depends on it’s provider one could align the governance structure by, for example, implementing a long term framework contract, combined with a development center approach and a exchange of shares between the companies. Most of the mis-alignment between the governance model and the actual state of the outsourcing relationship can be bridged by using more specific contracts, a decent knowledge management strategy and/or by using multiple outsourcing providers. A governance model is not merely there to govern the start of a relationship, the model supports the relationship while it grows and to provides a legal back-up during times of conflict.
4.5 Contracts Please note that this section is for reference purposes only. it is not a comprehensive treatment of all laws and regulations nor a legal advise. The reader should consult his or her own legal counsel in all cases.
Most of the hybrid governance models described in the previous section are backed up by contracts. Contracts are the foundation of buy model governance and they also provide the legal glue in alliances. Some literature suggest that a tight contract is the only mechanism to ensure that expectations of the outsourcing customer are met (Lee, 1996). The experience gained in conversation with and research of central-european outsourcing partners and their clients however indicates the opposite. An often made comment by the IT managers on both sides is: “Let the lawyers deal with the paperwork, we’re here to develop a good piece of software.” The inter-personal relationship, passion for the product and feeling of “ownership” seems to drive the outsourcing partners more than the contract. The contract is there to set up the relationship, define the boundaries but it certainly does not seem to be the critical success factor, according to the people at the work floor.
The purpose of a contract is to align the best interests of all parties in order to get to the optimal result of the project or activity which the contract is backing. The contract should not only contain high level legal obligations, but should also function as a ground level document on responsibilities, processes and work to be done. Contracts should aid the people working under the contract instead of holding them back in their daily activities.
Furthermore the contract, especially the agreements on price, time and scope changes should reflect the trust between the outsourcer and the supplier as well as be aligned with the actual product under development. Contracts which are strongly skewed towards one of both parties will inevitably lead to problems.
This section provides an overview of the most common categories of agreement as well as some contract types you could use to backup your contractual governance in the situations concerning the development of core competence products or products with a high specificity and/or high uncertainty.
4.6 Contents of a contract Contracts contain a certain amount of flexibility. The main rationale behind contract flexibility is that certain external factors are not under control of the parties negotiating the contract. Ulset (1994) defines three “levels” of contracts: market, hybrid and hierarchy. The different levels differ in the amount of flexibility allowed in the contract. Based upon various references (Harris, A. et. al, 1998; Ulset, S., 1996; Lee, M.K.O., 1996; Carmel, E. & Tjia, P., 2005) there seems to be a general understanding that IT outsourcing contracts should contain the following clauses :
4.6.1 Pricing
The three main options in pricing are: fixed price, flex price and cost-plus.
A fixed price construction is suitable for market transactions and the “buy” governance model. Fixed price contracts transfer most of the financial risks to the outsourcing provider and therefore limit overall project flexibility. Most likely the provider will resist mid project changes and will try to limit changes where possible.
A flex price structure is more suitable for projects with a lot of uncertainty or technical innovation. Flexing a project’s price provides a lot of flexibility throughout the whole project but also transfers a lot of the financial risk back to the client.
A third pricing option is the “cost-plus” method, in which the client pays the actual costs made by the outsourcing provider plus a certain percentage of the costs as the outsourcers’ margin. The cost-plus method is a suitable model for long term contracts and relationships. Although a lot of the financial risk of a project is in the hands of the client, in long term projects the cost-plus method is often far less expensive than billing by the hour or setting a fixed price.
In order to bridge the gap between the pricing models one could include a price adjustment clause. in the contract. This clause describes what to do when the provider comes across unexpected difficulties or when the client changes project priorities or requirements.
With the current trend of agile development the pricing clause in the contract can be a real burden. Agile development makes a lot of sense to developers but can also put a strain on managers. Agile development embraces change and flexibility. Agile development by definition values customer collaboration over contracts and responding to change over following a plan, as can be read in the The agile manifesto1.
1 Agile Manifesto: http://agilemanifesto.org/, checked on september 19, 2008
In practice a lot of outsourcing providers use an agile development method internally but in agreements with the customer they pretend to work using a structured design method like waterfall. By pretending not to be agile they satisfy the customer with terminology and contracts known to managers and lawyers, avoiding discussions about agile development. This agile-covered-by-waterfall approach is definitely a suboptimal solution. The real benefits of the agile development are hidden from the customer while the risks of agile development are still there. The outsourced activities will be covered by a waterfall contract and therefore fines and lawsuits might control the financial damages in case the agile risks summon but in general it is better to prevent spending time on lawsuits and not tear a relationship apart with fines. One solution to the agile-covered-by-waterfall approach might be to partially flex the contract via a “target-cost” approach. Different contract approaches including target-cost will be discussed in the next section.
4.6.2 Incentives
Part of the “payment” of the outsourcing partner can consist of, for example, revenue and profit sharing, shared bonuses or a partial return of the cost savings that were enabled by the provider. Especially in the case of of “alliances” the description of incentives requires extra attention. In the next section on contract models and flexibility different incentives structures will be explained, among these the profit sharing contract.
4.6.3 Administration control
Administration control defines the amount of control the outsourcer has over the processes and employees of the provider and vice versa. Administration control correlates mainly to the financial risks a party commits to during the project. In a fixed price project the financial risks are at the side of the provider, leaving the provider in control of most if not all procedures. When using more flexible contracts administration control is shared between both parties. Two common things arranged in the administration control section are the rights to approve personnel and the right to approve subcontractors.
4.6.4 Contract duration
One way to achieve flexible contracts is to shorten the contract period. For many ICT technologies shortening the contract means that a contract is tied up to part of the software development life-cycle running between 2 to 5 years.
4.6.5 Early termination
Situations might occur where one of the parties involved in the relationship gets in a position where prematurely ending the contract is considered a wise decision. Legal advisers recommend the use of a so called “mutual agreement” clause for these situations. It might be better to talk of these situations up front instead of at the height of a conflict. Early termination tied up with the renegotiation clause provides a way for the outsourcer to redefine, continue or terminate the project based on the status reports and intermediate results of the supplier.
4.6.6 Rights to dispute charges
An outsourcing client should negotiate the rights to dispute charges of the provider and withhold payment. This of course is not a favorable situation for the outsourcing provider. However, most of the times an agreement can be reached where the process of the disputes is formalized, possibly supported by securing a certain amount of the payments under escrow protection of a third party. The formalized procedure makes sure that the supplier doesn’t have to wait endlessly for its money or that payments are held back over unfair reasons, while maintaining the possibility of the client to argue the charges.
4.6.7 Ownership of intellectual property rights
The laws protecting intellectual property rights (IPR) vary from country to country. The unavailability of unified IPR laws hardens the process of protecting your IPR when outsourcing. The specific possibilities of securing IPR strongly depend on the country of the outsourcing provider and outsourcer. When both companies are located within the EU IPR definitions get a little easier but international law remains a spaghetti or rules. It is advised to consult a legal counselor.
4.6.8 Information security and confidentiality
Since the outsourcing provider in most cases will have access to confidential and/or commercially sensitive information, like customer records, both partners should agree upon confidentiality and information security up front. The information security and confidentiality agreement should not only include the sharing and treatment of information but also the availability of IT security infrastructure elements like firewalls, user access policies and virus detection software.
4.6.9 Excuse doctrine, warranty and liability
With the outsourcing of R&D activities a lot of innovation and uncertainty is involved. To bridge the gap between the legal consequences of a mistake by the internal R&D department and a failure at the side of the service provider outsourcing contracts have an “excuse doctrine” or “liability clause”. The liability clause states that claims for refunding or remaking the whole project are only warranted in cases of severe malpractice. This being difficult to prove, cases of malpractice are almost never brought to court. One more reasons to think of early termination and renegotiation clauses.
4.6.10 Renegotiation
Renegotiation procedures allow parties to act quickly using readily available information without having to spend too much time on future problems. Some contracts contain fixed dates or events for renegotiation of (part of) the contract. Although neglecting renegotiation, avoiding the discussion, can save both parties a lot of time up front, renegotiations might end up being a time consuming and administratively costly in the long term. Breaking open a contract and bargain about the contract items is a resource intense activity.
It has often been said, “Write the contract, archive it, and when you need it you’re in big trouble.” The challenge of making a contract is in the interplay between trust, security and flexibility. According to Davis and Speckman (2004) “Contracts are used to codify the
nature of the relationship and become useful in instances where partners have little past experience with one another. The contract reduces uncertainty by formally designating behavior and by adding predictability to the outcome of the exchange.” The contact provides both partners with a start, guidance through the relationship and a formal end, both the good and less pleasant ones.
4.7 Contract models and contract flexibility In order to meet the requirements that arise out of the different levels of specificity, recurrence and uncertainty of the transaction several contract models are used today. Each of these models has a different solution of specifying flexibility of the three main pillars of an IT contract: price, time and scope. These pillars form the tripod of each project, if one of the pods is wobbly, the tripod in will stand solid. However, cut one totally short, and it’ll definitely fall over. A solid contract will define the amount of flexibility on all three access and the way the flexibility is achieved.
The more flexibility is defined in the contract the more the risk of the project is transferred from the provider to the outsourcer. A project which has a fixed price, a solid deadline and fixed functionality places most, if not all, of the risk at the providers side. A project with a flexible deadline, based on hourly wages and without a descent understanding of the functionality under development places all risk at the outsourcer. The main challenge of contract flexibility is to find a model in which all parties share a part of the risks in such a way that opportunism is minimal and the amount of flexibility is aligned with the uncertainty in the development process.
The types of contract discussed here are: Fixed-price, Time-and-Materials, Progressive, Target Cost and Profit Sharing. Each of these models tries to solve a different kind of problem. Not one of of them fits every situation.
4.7.1 Fixed Price
As the name implies, a fixed price contract fixates the price, as well as the functionality. In general all three pillars: time, functionality and price are set. This allocates most if not all of the risk at the suppliers side. Fixed price contracts fit products or services that are relatively small and of which the requirements specification is complete and easy to comprehend. Fixed price contracts are suitable for market like transactions as specified by the governance model presented earlier in this chapter. The more the outsourcing objective needs hierarchical structures the less suitable a fixed price contract is.
4.7.2 Time-and-Materials
In a time and materials contract the amount of time spend on the product as well as the resource allocation of the supplier is fixed. The agreement in short states: “The provider will provide the customer with x developers spending y hours a week for a period of z months.” As the price can logically be derived from x,y and z it is most probably fixed. Although a time-and-materials contract might seem odd at first sight, it actually makes sense in the light of staff augmentation and offshore development centers. The customer basically buys resources and will determine how to use these resources by itself. A time-and-materials contract is useful in more hierarchical outsourcing situations where uncertainty and specificity are high.
4.7.3 Progressive
In a progressive contract situation you start of with a framework contract or master service agreement (MSA). The MSA covers all non-project specific contractual and governance issues and standard procedures. Along with the standard procedures on problem escalation and the definition of the formal communications the MSA might also include hourly wages and profit margins.
When there’s no MSA present the overhead costs of creating multiple contracts for small project pieces is generally too high. However, with the MSA in place the project(s) under development can be split into smaller chunks each with a separate contract. In general, chunks developed at the beginning of the project will have fixed price sub-projects and the parts of the product developed later might be build under for example a target-cost contract.
The main advantage of the progressive method is that once you have the MSA in place, the MSA speeds up the agreements on future projects, while keeping flexibility. The main disadvantage is that the customer is at risk if the supplier starts with a project but doesn’t agree to continue with forthcoming projects.
4.7.4 Target Cost
A target-cost (TC) contract is suitable for projects which contain a descent amount of uncertainty, a need for flexibility as well as a tight budget. In a TC contract an initial target of functionality is set. Based on exploratory meetings a target is set for the amount of resources and time needed to implement the initial specifications. Based on the target functionality an initial cost price is set, increased by a contingency buffer and a profit margin.
The initial scope of the project, the requirements, can be set based on user stories, story cards or any other system used for requirements specifications. The initial scope setting does not have to be extensive since the contract allows additions and changes, however, those requirement that are specified should be complete in order to avoid difficult discussions later on in the project. When the customer increases the scope during the project or when new requirements pop-up during the development phase the additions can be grouped into three groups (Horowitz 2005): fixes, clarifications and enhancements.
Fixes are changes to the requirements set in the initial scope of the project or extra requirements needed to actually implement functionality which was defined in the initial scope. Take for example an initial requirement for a website which states that the visitors of the website should receive “personalized e-mails” containing their name. However, in the initial design the designer failed to notice that in order to implement the feature the subscription form on the website should contain not only an e-mail address, but also a first, middle and last name field. During development the developer will notice the need for the extra name fields and a “fix” is added to the requirement list. Normally fixes are added as additional hours to the original requirement: sending personalized e-mails. Fixes are normally billed at cost without a revenue margin. This to some extent feels like a “punishment” of the outsourcing provider since it will not make any profit on the fix, but at least the provider gets paid for its actual costs.
Clarifications are requirements that couldn’t have been foreseen at the time of the initial scoping but definitely need to be implemented in order to have a correctly working product. Most of the clarifications come forth out of the advanced understanding of the project of both the outsourcer and the supplier. As with fixes clarifications are billed onto the requirement originally specified, often with a certain profit margin.
Enhancements are additions which are out of scope and can actually be implemented as a separate user story. The non-existents of the enhancement effectively does not diminish the correct working of the product under development. Enhancements are seen as a clear increase in scope and therefore are billed as extra functionalities.
When the scope of the project changes it depends on the kind of change what to do with the budget. With fixes and clarifications the amount of time needed to implement the change is added to the requirement out of which the clarification or fix originated. In case the addition of fixes and clarifications results in an overshoot of the initially planned hours of work the extra hours are billed at cost. You might want to decide to treat fixes as a 0% profit addition, only billing the actual costs, and clarifications as a 50% profit case. By defining different revenue models for different kind of requirement changes a revenue and penalty system is created in which:
A fix is paid for at cost price, not increasing the profit of the supplier. The supplier should’ve foreseen the requirement in the initial process.
A clarification is paid for at cost price + 50% of the agreed profit margin. Both the supplier and the outsourcer were not able to specify or think of the requirement.
A enhancement is paid for at cost price + 100% of the profit margin. The outsourcer thought of something new and extended the scope beyond the original functionalities.
TC contracts allow for a descent amount of flexibility in the specifications, price and provide enough information to set an initial deadline and to extend the deadline once scope increases. Both parties share part of the risk of the uncertainty in the product and the possibility of controlling the scope and therefore the price of the project. The provider is eager to make a solid estimation at the start of the project since an understated prediction will not increase the providers profit. The initial estimation therefore provides the outsourcer with a good idea of the costs of the project. The TC method provides a decent amount of certainty to both parties concerning resources, scope and time. Table 1 depicts a TC contract budget and final financial overview, clarifying the fixes, clarification and enhancements made during the project.
Project target actual (inc.
fixes)
clarifications enhancements final
Development Days 36 40 5 5
Initial scope definition and setup 4 4 1
Subtotal 40 44 5 6
Contingency buffer (20%) 8 1,2
Total project days 48 44 5 7,2 58
Cost (developer/day) € 600 € 600 € 600 € 600
Project costs € 28,800 € 26,400 € 3,000 € 5,400 €34,800.00
Profit (25% for target and enhancements,
12.5% for clarifications)
€ 7,200 € 6,600 € 375 € 1,350 € 8,325
Project price €36,000.00 €43,125.00
(Table 1. Target-Cost model)
4.7.5 Profit Sharing
The main idea behind a profit sharing contract is that the customer funds (part of) the development of the software product at cost and the supplier gets a lot of freedom on how to develop the system. By the time the product is ready to hit the market both companies share the profits made with the product. Depending on how much the customer funded at the first place and the transparency of the “extra” costs of selling the product like marketing and sales, administration and maintenance a devision is made in the profits. Both companies will start making profit as soon as the product starts shipping.
The profit sharing approach requires a lot of trust and openness of both parties and is especially useful in joint venture and alliance situations. The customer has to trust the supplier in its technical capabilities, putting the supplier up to the “partner” or “advisory” level and the supplier has to trust and somehow agree on the strategy and the costs involved in pushing the product out into the market.
The main advantage of the profit sharing approach is that both partners will prosper together on the effort they put into the product. The mutual prosperity increases the motivation of employees on both sides and open communication between the partners is stimulated. On the counter counter side the major advantages are also the major treats. Because the partners respectively have to put a lot of trust in the marketing strategy of the outsourcer and the technical capabilities of the supplier conflicts will arise when one of both lags behind on the prognoses. During prosperous times the partnership will be strong, in more difficult times the conflicts that arise most probably have to do a lack of trust. These conflicts are hard to manage and hard to overcome.
4.8 Related work and further reading In order to gain more insight in the topics discussed in the chapters one could check the literature list at the end of the chapter. Some general works of interest however are not cited in the text but do provide interesting reads. First of all the website of the IT Governance Institute (www.itgi.org) contains a lot about out IT governance in general. The institute mainly focusses on classical outsourcing of whole IT departments of non-IT related companies but also contains interesting information for product software companies. A recommended read is the “Board Briefing on IT governance” which can be found in the “Resource Center” at the ITGI website.
An interesting article and a good starting point if you’re interested in alliances and more specifically in R&D alliances is an article by Rajnees Narula titled “ Innovating through strategic alliances: moving towards international partnerships and contractual agreements”.
More information about growing partnerships in outsourcing can be found in works covering the “Outsourcing Maturity Model”, a recommended read is the article “Maturity Model for IT Outsourcing Relationships” by Petter Gottschalk and Hans Solli-Sæter.
Last but certainly not least, check out the work of Mary and Tom Poppendieck (www.poppendieck.com). This chapters’ section on contracts was partially inspired by M. Poppendieck “Agile Contracts” presentation in a Agile 2005 workshop. A lot of papers, presentation and information can be found at their website.
4.9 Case study - Uniconnect “Bribing is not necessary when you know the rules”
Anca Vlad, Partner Uniconnect
Uniconnect is a service company which main focus is to serve as a catalyst between Rumanian and Dutch businesses. The company is located in Timişoara, one of the IT hot spots in Rumania. It’s located near the west border with Hungaria and Servia and as can be seen from the overall condition of the town, the roads and it’s surroundings the helping arms of the European Union stretch out over the area. Under the reign of a liberal mayor, together with a progressive rector of the Polytechnic Universit,y Timişoara is rapidly becoming a hotbed for IT servicing companies. There’s a large pool of well educated scholars finishing their bachelor and/or master degrees every year and the university is making an effort to adapt the education system to business needs.
The main mission of Uniconnect is to enable entrepreneurs and investors outside Rumania to do business in Rumania. Uniconnect’s approach is twofold. On the one hand they provide legal and administrative support and on the other hand they have a strong and widespread network of business contacts. The twofold approach is a result of the founding partners of Uniconnect, a Rumanian lawyer and an amiable Dutch, but longtime inhabitant of Rumania, business man and professional networker.
Although Uniconnect boldly states that they have never used “bribing” to get things done, the use of their network and connections with the university helps. According to Anca Vlad, partner at uniconnect, “Bribing is not necessary when you know the rules.” The system is still overly complicated in order to drive people into bribing, but if you
know what to do and where to get the right forms, the process is smooth and fast. The formalities of starting a business could be taken care of in a matter of days.
Besides helping out with starting your own company in Eastern Europe, companies like Uniconnect also provide a way to “check” your potential business partners in the area. In a everybody-knows-everybody culture the business contact network of a company like Uniconnect can provide you with a general indication about the quality and trustworthiness of your partner, as well as formal checkups on their financials.
Knowing your way around, mastering the formalities and procedures and having a strong network is the key to a good start. Companies like Uniconnect provide you with “local” knowledge and an invaluable network. It is advisable to find yourself an “Advisor” if you’re new to the central and eastern European region.
4.10 General remarks and lessons learned In the process of doing research for this chapter some questions and remarks frequently popped up at the outsourcers and outsourcing providers. These remarks were considered slightly out of scope of this chapter but are worth noticing.
Multiple providers versus provider partnership
The question of wether or not to use multiple providers for the same activity is not easy to answer. The answer strongly differs based on the product under development and the overall organization structure. It seems reasonable to use different partners in the case of a more market oriented governance model. If your partners know that you’re also outsourcing to their competitors, they might try harder, be more competitive and offer you a lower price. However, once you found a partner with the optimal price and performance, what would be your incentive of going trough another partner selection and contracting process, except for the fact that it might keep your partner of choice “sharp” and “competitive”?
In case of more specific activities it doesn’t seem to be wise to use multiple partners. Most of the times the partners are forced to work together since more specific assignments require tighter collaborations. One should not forget however that in general the outsourcing partners that are forced to collaborate are actually competitors and will be reluctant to work together, disintegrating the needed collaboration.
People management and trust
Outsourcing is people business, based on trust, respect and social interaction. Although contract negotiations and setting up governance models require discussion, in the end both companies involved are looking for a long-term or short-term partnership. Most of the companies outsourcing noticed that the overall quality improved and the “fun and pleasure” of the work increased when a “people-manager” was managing the outsourcing. Somebody who understood the cultural differences, had respect for the people working at the provider and treated them as equals. Stricter “line-managers” didn’t have the desired effect and were spending a lot of time doing conflict-resolution instead of supporting both parties in making the best product available. A good interpersonal relationships between the employees of the customer and the people working at the providers side will increase the quality of the product, the speed of delivery and the joy of working more than any contract or governance model will ever do.
Driven by opportunity
Most companies interviewed during the research process of this book stated that their “start in outsourcing” was merely opportunity driven. Somehow they came in contact with an outsourcing provider and decided to explore the opportunity. Over the years trial and error thought them how to cope with outsourcing in general and their specific partner. No reasoning about the governance model or partnership level took place. Neglecting governance models and partnership levels didn’t prevent the companies from having successful outsourcing relationships. This chapter summarizes some of the lessons learned by the trial-and-error approach of the companies interviewed, as well as taps into taps into knowledge gained by more general outsourcing projects. Thinking about your governance model and partnership level will gain you a head start and save you some trial-and-error learning.
To conclude the chapter we summarize the main lessons learned in this chapter on how to set up the right governance model in your outsourcing relationship:
Know what skills and capabilities are expected from the outsourcing partner and determine the partner level. Selecting a partner at the right level helps to gain trust, since the probability of the partner disappointing you because of your high expectations decreases. Selecting the right partner also helps the outsourcing provider. If the partners’ level aligns with the outsourcers’ requests and expectations the outsourcer becomes an “interesting” and “challenging” customer for the outsourcing partner.
If an opportunity to outsource arises, choose a governance model that fits the situation, possibly backed up by a contract with the right flexibility. The alignment of the governance model with the uncertainty, specificity of the assets involved and the recurrence of the activities minimizes the transaction costs and gives you a descent amount of insurance.
Grow the relationship over time and establish trust. Make sure that the governance model and contacts keep on reflecting the actual situation. Selecting a governance model is not a one time activity but an ongoing process.
4.11 References Arnold, U. (2000) “New Dimensions of Outsourcing: A Combination of Transaction Cost Economics and the Core Competencies Concept”. European Journal of Purchasing & Supply Management, 6, p. 23-29
Carmel, E. & Tjia, P. (2005) “Offshoring Information Technology: Sourcing and Outsourcing to a Global Workforce”. Cambridge University Press, United Kingdom
Davis, E.W. & Spekman, R.E. (2004) “Extended Enterprise: Gaining Competitive Advantage through Collaborative Supply Chains”, Financial Times Prentice Hall, USA
Eckfeldt, B. & Madden, R. & Horowitz, J. (2005) “Selling Agile: Target-Cost Contracts”. Proceedings of the Agile Development Conference, 2005
Ertel, D & Weiss, J. & L.J. Visioni. (2001) “Managing Alliance Relationship - Ten Key Corporate Capabilities: A Cross-Industry Study of How to Build and Manage Successful Alliances”. Vantage Partners, 2001
Gerwald, H. & Helbig K. (2006). A Governance Model for Managing Outsourcing Partnerships - A View from Practice. proceedings of 39th Hawaii int. conference on System Sciences, 2006
Gurp, J. van & Brinkkemper, S. & Bosch, J. (2005) Design preservation over subsequent releases of a software product: a case study of Baan ERP, Journal of Software Maintenance and Evolution: Research and Practice, 17, pp. 277-306
Harris, A. & Giunipero, L.C. & Tomas G. et. al. (1998) “Impact of Organizational and Contract Flexibility on Outsourcing Contracts”. Industrial Marketing Management, 27, p. 373-384
Lee, M.K.O. (1996) “IT Outsourcing Contracts: Practical Issues for Management”. Industrial Management & Data Systems, 96(1), pp. 15-20(6)
Maher, M.E. (1997) “Transaction cost economics and contractual relations”, Cambridge Journal of Economics, 21, p. 141-170
Ulset, S. (1996) “R&D Outsourcing and Contractual Governance: An Empirical Study of Commercial R&D Projects”. Journal of Economic Behavior & Organisation, 30, p. 63-82
Vining, A. & Globerman, S. (1999) “A conceptual Framework for Understanding the Outsourcing Decision”. European Management Journal, 17(6), p. 645-654
Williamson, O.E. (1985) “The Economic Institution of Capitalism”. The Free Press, New York.
Williamson, O.E. (2005) “The Economics of Governance”. American Economic Review, 95(2), p. 1-18
Related work and further reading
Gottschalk, P. & Solli-Sæther, H. (2006) “Maturity Model for IT Outsourcing Relationships”. Industrail Management & Data Systems, 106(2), p. 200-212
IT governance Institute (2003) “Board Biefing on IT Governance, 2nd edition”, www.itgi.org, 9-21-2008
Rajneesh, N. & Hagedoorn, J. (1999) “Innovating through strategic alliances: moving towards international partnerships and contractual agreements”. Techonovation, 19, p. 283 - 294
5 Evaluation and Selection of Outsourcing Partners By Martijn de Kuijper
When a company decides to outsource their product software development, many new issues and problems arise. This is even more true, when the development of a software product is outsourced to a foreign country. As described in the previous chapter ([Chapter Wilco]), one has to first decide on the kind of strategy to follow and how the company is going to collaborate with a new partner in that specific country. This brings us to the next step of the preparation phase, i.e. finding such a suitable business partner.
Figure 1 The partner selection process
The whole process from the beginning, finding a partner, until the end, signing the contracts, is discussed in several researches and often put down as a systematic and step-by-step process (as depicted in figure 1). In practice, as our research points out, this process is often a more an ad-hoc, opportunity driven process, i.e. often a partner is chosen that is most convenient, without an extensive evaluation. In this chapter, we will discuss every step in this process in order to create a generic starting guide for companies that are looking for outsourcing partners in foreign countries.
5.1 Criteria Before diving into the world of partnering, it is obvious that a company should prepare itself in order to make the right decisions and eventually the right choice for a partner. As described in the previous chapter, there are sever partner levels, i.e. commodity, provider, partner and advisor. From commodity to advisor, the level of trust, commitment and amount of communication increases, which changes the criteria a potential partner is assessed on. These criteria should be well defined before taking the first step, i.e. the search, because in every phase of the process these criteria play an important role. These criteria and its relevance differ per organization. The number of important criteria can be reduced to a smaller number, where six to eight criteria will often be sufficient (Carmel and Tia, 2005).
In literature, Geringer identifies two categories of partner-selection criteria in the context of international joint ventures (Geringer, 1991), i.e. task-related criteria and partner-related criteria.
Task-related criteria are related to the skills and resources the outsourcer requires, e.g. technical skills and resources (programming language, technical infrastructure etc.), while the partner-related criteria are related to the efficiency and effectiveness of the partner’s co-operation (e.g. national or company culture, organizational size, structure). While there can be an unlimited number of criteria, these two categories comprise the most important and recognizable criteria.
5.1.1 Partner-related criteria
As mentioned above, the partner-related criteria are related to the efficiency and effectiveness of the partner’s co-operation. These criteria are not affected by the type of project / work that is outsourced, but will be a more permanent set of criteria depending on the outsourcer’s preferences (does the company want to partner with small or large companies? Is there a preference for specific country? Etc.) In practice, these criteria are often not clearly defined and as perceived during our research, the most important partner-related criteria are the past experience between colleagues (as in other companies or colleagues within the company with past experience at other companies) and a partner and between the outsourcer itself and a potential partner. Depending on the partner level, these type of criteria will be more important from commodity to advisor.
5.1.2 Task-related criteria
The task-related criteria are related to the skills and resources the outsourcer requires for competitiveness. These criteria change per project / task that is outsourced, because every project will require other skills and resources. These are of course not only technical skills and resources, but also , for example, financial resources and skilled managerial personnel.
As mentioned earlier, the criteria should be defined before starting the search for partners. As some criteria are more important than others, depending on the activities that are going to be outsourced, it is also important to prioritize these in order to eventually make a comparison between the potential partners. Take into account the partner level you are looking for, because if you for example looking for a commodity provider, partner-related criteria such as culture and experienced managerial staff are less important. With such a short-term relationship you just want to “get things done”. On the other hand, if you are looking for a long-term partnership and want to leave a lot of the management activities up to the partner, culture, trust and experienced managerial staff are of great importance.
Weight Partner-related criteria Task-related criteria
8 Desired programming expertise
7 Pricing structure
6 Amount of available employees
5 Core competencies
4 Total amount of employees
3 Development methods
2 Communication systems
1 Attrition rate
Table 1 Example set of criteria (commodity partner level)
5.1.3 Searching for potential partners
There are numerous companies that are able to perform activities for Dutch companies (in every branch), in Eastern Europe, but finding potential suitable partners among these many is a tough task. During our research we concluded that all the companies we visited used the same “method” while searching for a potential partner, i.e. using their network and past experiences. Some companies started outsourcing their activities to former employees who started their own company after the outsourcing company closed their foreign development centre, while others used their personal connections in order to find a suitable partner. It is important to make sure these connections (i.e. companies in the network) are in the same branch and have a comparable business model (described in the previous chapter [Chapter Wilco]). This makes sure the large list of potential partners is already narrowed down. Other ways of locating potential partners are using specific intermediary companies or chambers of commerce.
Intermediary companies - There are several companies that are located in a specific country / city, which assist Dutch companies in finding local partners or setting up a development centre of their own. They function as an intermediary party that know the local culture, rules and people. With their knowledge and experience, they can assist foreign companies with doing business with that specific country.
An example of such a company is Uniconnect, which is located in Timişoara, Romania. Uniconnect uses its large network and knowledge of local institutions to help Dutch companies doing business in Romania. For finding local partners, Dutch companies can fill in a matching request where they can specify all their criteria for a partner. Subsequently Uniconnect matches the Dutch company with several Romanian companies.
Chambers of commerce - There are several chambers of commerce that are in between countries and often have an establishment in both countries. These chambers of commerce are sometimes semi-government and sometimes they offer commercial services. They can assist in many aspects (e.g. starting up a business, legal issues etc.), including finding partners. There are several examples of such chambers of commerce:
General EUnite
“Centraal‐ en Oost‐Europa Trade Club” (COETC)
Czech Republic The Netherlands-Czech Chamber of Commerce
Romania The Romania-Holland Commerce and Industry Chamber
Hungary Hungarian Business Network – HBN
Netherlands‐Hungarian Chamber of Commerce
Table 2 Examples of Chambers of Commerce per country
Choosing a country for outsourcing your activities can also be an important issue, depending on the partner level. For outsourcing to a commodity partner, choosing a specific country is less important, because if a certain potential partner possesses the required skills and other relevant qualities, that should be sufficient. On the other hand, if you’re looking for a long-term partnership, country selection becomes an important step. For long-term partnerships, a fit with the partner (described in the following section) is crucial. This means a fit in national culture, a fit in company culture, making sure there are no language barriers etc.
The mentality of the Eastern Europe people differs per country, which could be a vital issue. During our research, we noticed that the more western countries (e.g. Czech Republic) do have a more assertive mentality, which is important if you want to shift more of the managerial activities to a foreign partner. The Romanian people are less assertive, i.e. they are not as direct as the Dutch people and can’t say ‘no’ to certain requests (even if they are not able to perform the requests).
5.2 Preliminary selection Many public information about the companies can be found on the Internet, in company brochures or for example the annual report of a company, but this information is not adequate to assess a provider on. To gain more knowledge about a provider – knowledge you specifically like to know, mostly regarding the specific tasks you would like to outsource - you can send out an Request For Proposal (RFI) to several companies. An RFI contains a set of questions, which, when answered, will give more in-depth information about the specific company. An RFI contains for example the following sections:
‐ General information o Questions about the company structure, culture, financials, attrition rate, number of
employees, number of employees in the subject matter of the RFI etc. ‐ Competencies
o Questions about the core competencies and competencies specifically in the subject matter of the RFI, e.g. programming skills, managerial skills etc.
‐ Communications o Communication is an important issue in outsourcing. Questions considering
communication tools, communication processes, SLA’s are crucial.
‐ Past experience o Questions about the past experiences with providing services to (foreign)
outsourcing companies, working in virtual teams etc.
Depending on the kind of project or level of partnership (e.g. commodity or provider), these questions can be extended with a lot more additional questions.
After receiving the RFIs, there is more in-depth information available about the companies, which means a better preliminary analysis can be conducted in order to find a potential “fit” between you and the other companies. This is where the partner-related criteria come in to play.
In order to find this potential fit, Ruokonen et al. propose a FIT analysis, which consists out of the following three elements that include the partner-related criteria:
Figure 2 FIT Analysis (Ruokonen et al.)
Per element, one should ask itself several questions in order to determine the degree of fit. After answering these questions for yourself, you should be able to shorten the list of potential partners.
Strategic fit
‐ Are your growth strategies in line with those of the partner? ‐ How critical is cooperation with you for your potential partner? ‐ How is the competitive position of your potential partner in line with the one of your own
company? Competence fit
‐ Do the candidates have the required resources for the planned operations? ‐ How well do the competences of the partner candidate complement your own
competences? ‐ How do your resources complement the ones of your partner candidates?
Organization fit
‐ Does the culture of your company and the candidates’ culture match (e.g. formal vs. informal culture, flexibility vs. bureaucracy)?
‐ How big are the differences in national culture? Do these differences complicate the communication and collaboration? Are there other countries which might have less differences in national culture?
5.3 Partner assessment After the preliminary assessment using mostly the partner-related criteria, the long list of potential partners is reduced to just a few. Carmel and Tjia (2005) suggest that two or three potential candidates should be sufficient if a company needs just one provider. The short list of candidates contains companies that potentially are a good fit and could, if not eventually chosen in the current partner selection process, also be a potential partner in the future.
Request for proposal - After this preliminary selection, the task-related criteria come in to play, in order to define whether a potential candidate is able to perform the activities you would like to outsource. This means you will have to investigate whether the candidates have the desired programming skills, development methods etc. A Request For Proposal (RFP) is a suitable method to gather this information. Like an RFI, an RFP contains questions for the candidate, in order to gather additional information. The RFP, as the name suggests, also requests for a proposal from the candidate, based on the information given. This information must contain both the business case as technical issues. An RFP contains for example the following sections:
‐ Reasons for RFP o This will describe the business case, so the candidate can get a feel of the project /
product for which the activities are being outsourced. One could state that this is less important, if the potential partner can “just deliver the requested activities”, but as we noticed during our research, involvement and the feeling of responsibility are important motivating factors.
‐ Project description o A description of the project and its requirements, either mandatory or desirable.
‐ Goals and scope ‐ Deliverables and acceptance criteria
o Describing the final deliverables and the criteria on which the proposal will be accepted.
‐ Costs and rates o Here you can define whether a fixed price or a T&M (time and materials) structure is
preferred. The candidate can then define its costs and rates. ‐ Proposal delivery
o How will the proposal be delivered? In order to make sure the proposals are in the same structure, the proposal delivery describes for example the format of the proposal, the proposal content and the final date for the proposal etc.
‐ Additional questions If additional information about for example technical skills is required, additional questions can be asked.
After receiving back the RFPs, the final step in the selection process begins, i.e. choosing the final partner. With the additional information gained from the RFP, you should have a clear overview of all the potential partners left; how is the fit with your own company (partner-related) and which companies can deliver the required services (task-related)? However, these rather identifiable characteristics of the candidates are still not sufficient (especially for long-term partnerships) for making a final decision, due to two reasons:
1. The information in the RFI and/or RFP can contain a lot of information that is not or partially true, because the candidate desperately wants to attract new outsourcers.
2. Even though you have a good overview of the candidates’ characteristics and skills, an important factor is making sure there is a “click” between both parties. Trust and a fit on personal level make sure the collaboration will be better.
In order to test these issues and assess the candidates in more detail, visiting the foreign location is very important. Making sure there is a fit on personal level and a likely good collaboration, is only possible with personal contact.
5.4 Partner negotiation After finding a potential partner, the most important part of the alliance formation is the negotiation phase. Finding a partner and a mutual understanding of the benefits of the partnership does not necessarily mean that it will be a successful partnership. Both parties will have their strategic objectives and ideas about how the partnership is going to be formed. It is important to come to an agreement on these issues to understand each other’s needs and aims. Examples of important issues to consider:
‐ Ground rules on rights and obligations ‐ Ground rules regarding using IP ‐ Preventing imitation ‐ Pricing structure ‐ Risk and reward clauses
5.5 Signing contracts Finally, based on all the gathered information of the steps described above, a final partner is selected and the outcome of the negotiations can be formalized in a written contract. Even though a written contract is not necessary for the legal existence of a contract, there are various reasons why a written contract is needed (Ruokonen et al.):
‐ Confirms verbal discussions with the partner ‐ Introduces rules that neither can unilaterally change ‐ Facilitates taking into account the most essential issues in the relationship and thus
decreases costs and risks ‐ Secures the tenure of the relationship ‐ Ensures that the relationship stays alive in the event that the representatives of either
or both parties change over the course of time ‐ Minimizes the risk that either party would sue the other in court ‐ Complements the clauses that come from the national laws of the counterparts
Finally, the contract will be signed in order to come to a final partnership. Such a contract with a business partner should at least include:
General information The names and contact information of the counterparts
Background and purpose of the contract
Definitions of the key concepts
Territory (product, market, technology, etc.) in question
Duration
Terms Obligations for both parties
Rights of the parties (patents, trademarks, confidential information, ownership of property, results of the cooperation, etc)
Limitation of competition
Compensation, penalties, limitations of risk and responsibilities
Payment terms, funding for the action
Targets and goals that the counterparts have agreed on as relevant for a satisfactory relationship
Appendixes, other terms, priorities of the documents
Policies Methods for changing the contract
Confidentiality and safekeeping of the documents
Terms on how to resolve disagreements
Date and signatures
Table 3 Content of a contract
5.6 Conclusion The selection of a partner for outsourcing product software development is often done in a very ad-hoc and opportunity driven manner. In order to create a guide for the partner selection process, we identified several steps in this process, i.e. searching for potential partners, preliminary selection, partner assessment, partner negotiation and signing contracts.
There are several ways to find potential partners, but as we pointed out, the best place to start looking is your own network. Other companies within your network have probably encountered the same issues and operate in the same branch, which already narrows down a very long list of potential partners.
For assessing the potential partners you should formulate a list of criteria to assess these partners on. There are two types of criteria, i.e. the partner-related criteria, which are related to the efficiency and effectiveness of the partner’s co-operation, and the task-related criteria, which are related to the skills and resources the outsourcer requires. These criteria can then respectively be applied to a Request For Information (RFI) in order to find a potential fit between your company and the potential partner company and to a Request For Proposal (RFP) in order to make sure the potential supplier is able to perform the activities you would like to outsource.
Subsequently the negotiation phase will be very important to come to a mutual agreement on several aspects like rights and obligations and risks and rewards etc. The outcome of these negotiations will be put into a contract and will finally be signed to come to an actual partnership.
5.7 Literature Bivainis, J. (2006). Development of business partner selection. Economics. 73, 7-18.
Carmel, E., Tjia, P. (2005). Offshoring Information Technology Sourcing and Outsourcing to a Global Workforce. Cambridge University Press.
Cavusgil, T.S., Evirgen, C. (1997). Use of expert systems in international marketing. European Journal of Marketing, 31(1), 73-86.
Geringer, M.J. (1991). Strategic determinants of partner selection criteria in international joint ventures. Journal of International Business Studies, 22, 41‐62.
Ruokonen, M. et al. (2008). Global Network Management ‐ Ideas and Tools for ICT firms to succeed in international network environment.
6 Managing Transition to a Nearshore Location By Dirk Menkveld
This chapter presents the transition model to manage the transition process in distributed product software development. We take a look at transition topics like knowledge transfer, change management, and governance. First, there is a lot to say about transitioning IT work. It’s a difficult process which requires good management to make it a success. Second, we’ll discuss the process where transition is managed and raise some key elements which need to be considered to successfully manage this process. Combining theory and practice, we’ll discuss the transition model which explains the process in more detail. Then, we’ll see how this model is applied through three case studies. And finally, we will conclude this chapter with an advice for project managers.
6.1 Background After the process of finding, selecting and contracting the right partner for outsourcing a part of the work, the transition phase is beginning. This is a difficult and critical period for the company, because management will discover whether they’ve made the right choice. Before we start talking about this process, we’ll use the following definition throughout this chapter:
“The transition process is the period where activities are being shifted from an internal unit to a nearshore location”
Here activities are tasks involved in software maintenance, bug fixing, testing, and developing. The internal unit is the company located in the Netherlands and the nearshore location is a unit or company located in Eastern Europe. Normally, transitional outsourcing involves the migration from one technological platform to another. Such transitional outsourcing has three phases: (a) management of the legacy systems; (b) transition to the new technology/system; and (c) stabilization and management of the new platform. Any one or all of these three phases could be turned over to a third party provider (Dibbern et al., 2004). So, there are several phases to be considered. It depends on the company’s core business what to outsource and how. When the decision is taken to start the outsource process, a plan needs to be made in order to successfully manage the entire setup of working together with a nearshore partner. This plan is executed by proper project management, in which all facets of the transition process are included. The transition can be divided into four phases: initiation, ramp-up, main transition, and wrap-up. Later on we’ll discuss each of these phases. To limit the risks, it pays to transfer activities in phases, starting with simpler tasks or limited geographies. Another critical step is to conduct training with the new provider at the existing location or onsite at the new location. While this step may require more time and effort than anticipated, it can be streamlined with the right approach (Chadwick-Jones, 2004).
For the project managers in place it is necessary to bring certain number of nearshore developers to their internal unit to analyze the technology and architecture so they can get back and install the same technology and architecture. In general, this costs the company a lot money (nearshore worker and the in-house trainer), but on the other hand it prevents a lot of problems. This means that neither the in-house trainer nor the nearshore worker is producing anything during that period. The transition period is
perhaps the most expensive stage. It takes from three months to a full year to completely hand the work over to a nearshore partner. All infrastructures at both sides need to be operational and functional with a ready-to-use communication platform in place. The whole transition process is costly and sometimes even more than the expected savings. In fact, there may be no savings at all. (Overby, 2003)
6.2 Knowledge transfer This part of transition management is most critical and costly for the company to setup nearshore collaboration. Carmel and Tjia (2005) describe this process as successfully transferring specific types of knowledge and experience into the minds of all those collaborating on the work across many kilometers. They distinguish four types of knowledge which should be transferred: Skills, Process, Domain, and Work and culture, with the following description:
• Skills, such as learning a new programming language.
• Process, such as harmonizing development methods between onshore and offshore sites.
• Domain, such as business application, architecture, algorithmic, and artistic.
• Work and cultural norms, such as organizational and national culture.
From top to bottom the knowledge transfers goes from easy to more difficult. Skills are explicit knowledge, which easily can be transferred, whereas work and culture is tacit knowledge and is very difficult to transfer. A lot of training sessions are needed in order to successfully transfer this type of knowledge.
6.3 Change management One of the things is in the overall change management. Carmel and Tjia describes change management as overcoming the inertia and resistance within the organization to a difficult change. It holds: implementing measures and reward systems to motivate offshoring, creating new organizational structures to support change, Internal selling, Funding demonstration projects, education about offshoring, implementing human resources policies to reassure employees of their positions.
6.3.1 Governance
To manage the offshoring part in a company, a clear plan needs to be in place. This means establishing structures, roles, responsibilities, and written agreements to ensure that control coordination, and relationships are all functioning smoothly between the client and the provider in offshore outsourcing. (Carmel and Tjia, 2005). Knowledge and experience asymmetries, and requirements and task characteristics (such as complexity, instability, ambiguity, and novelty) prompt onsite and offshore team members to engage in acts of sense giving, sense demanding, and sense breaking (Vlaar et al, 2008). Which means that workers on both locations need to be free in order to solve any upcoming problem at hand? Making sense of their tasks and their environment increases the understandings on both sides. Eventually, this will lead to exploration and value generation overall where overall performance of distributed significantly increases.
Also, a proper communication technology needs to be in place. A high internet access line is needed to support weekly (or daily/monthly) conference calls, large file transfers,
remote login, and etcetera. Besides that, a software tool is needed for project management, bug tracking, discussions for the project manager to control; we’ll take a look in the knowledge management chapter.
Nearshore software development scenarios may include experts and developers in teams with domain specific knowledge who collaborate internationally across multiple local contexts. A key challenge in the understanding and also practice of such distributed work is concerned with the issue of knowledge, and how it can be effectively transferred, monitored and managed.
6.3.2 Another perspective
Because of the rapid changing environment and continuous new technology development outsourcing in general became a global scenario. In order to keep up with competitors companies needs to be cost effectively on the product software development. The decision to outsource is normally based on costs which hold no more. Now, it’s based on scarcity on the Dutch IT market whereas cheap and good developers can be found in Eastern Europe. Why? The main reason because its a few hours away and they control the English language.
So, IT companies are looking in Eastern Europe to move the development process. Of course, there are some disadvantages, but they do not play a big role because of the advantages. As we have seen in the previous chapters, a decision to offshore product software development is easily made. After the partner selection a difficult process is initiated, where the questions is:
How do I manage to move responsibilities, maintain quality and keep productivity up-to-date when a move my development process to a nearshore location?
The answer can be found in the remainder of this chapter. Later on, the transition model will be introduced and will help project managers to oversee the different phases of the process and in the lesson are some key elements in general.
6.4 The Transition Process As has been told there are four phases bound to the transition period. In this part we’ll explain the six phases in more detail and how to deal with problems that can be prevented in some situations. Overall, the average period of the transition process is about 3 months until a year.
6.4.1 Initiation
In order to know whether outsourcing parts of the development process is the best solution cost effectively and efficiency, a feasibility study is needed. When the decision is taken, a solid transition plan is needed to plan the period. Most of the times this is done base upon a project plan. All activities are scheduled and the responsibilities are assigned. Then, the word needs to be spread and the transition (project) plan is distributed. Some meetings are scheduled where the plan will be reviewed and discussed. The best way for a solid collaboration is to create a matrix where resources are outlined vs. skills. This can be extended with a skill gap analysis in order to identify the weak and strengths of the IS staff. This can be helpful for the during the transition process. Last, but not least, a timeline is needed where the milestones are marked.
6.4.2 Ramp-up
When the plan is there and ready to be executed, support staff can be assigned to the development of the product software. Now, a determination of the actual training can be based on gap analysis. The training stage is probably the most intensive and expensive stage for both locations. Where the deliverables are collected, reviewed, and accepted they can be determined in roles and responsibilities. The best way is to assign an evaluator for every transition. In that way, you can monitor all things during the process. Another thing is to create support point at the internal unit where all knowledge is in one place and can be accessed all over the time.
6.4.3 Main transition
Now, the transition is started. Knowledge transfer is the most intensive part, which can be done through on-site visit and training. The idea is the meet the persons with the knowledge and the ones who’ll take over parts of the development. This is also the best way to learn the product environment. Later on, when the training period comes to an end, you need to measure whether the knowledge transfer was successful. After the training period, a stable communication infrastructure is needed for the remainder of the transition and distributed collaboration. In between meetings can also be helpful in order to improve the collaboration.
6.4.4 Wrap-up
This last phase is not that exciting, when all nearshore workers are operational, the actual documents and code need to be moved from the internal unit to the nearshore location. Meetings can now take place at the nearshore location where the project is reviewed.
6.5 Transition model In all traditional product software companies a method is implemented for the development process. Most of them follow the Software Development Life Cycle (SDLC), others implemented other development methods. The one thing here is that you can map the SDLC into a project frame, and even this can be mapped into the transition process, which is depicted in figure 1.
Figure 3
As you can see the first phase, investigation, initiating, initiation has a lot of overlapping. Whereas, analysis and design can be mapped into the planning phase of the project and the ramp-up of transition. This is where deliverables are determined and assigned to developers. The most interesting part of the figure is where development, implementation, testing, and maintenance are mapped into executing and monitoring and controlling of the project into the main transition. This means that this part of the SDLC is the transition part, or actually the part which is outsourced by most of the companies. We’ll take a closer look in the next paragraph. The last part is the closing and wrap-up part where all activities are evaluated.
6.5.1 The best way to do the main transition
As a company, if you really want to move all activities from your internal unit to a nearshore location, the best way is to begin small (with basic things) and after a learning period to end big (move all development). This is depicted in figure 2. You can see that the last four phases of the SDLC are in the descending order, which means that the maintenance is easiest to do and development is the tough job, which considerably needs a lot of monitoring and controlling.
The transition model
As we combine and summarize the above part of the transition process, it’s time to present the transition model, where and is depicted in figure 2.
Figure 4
The transition process is modeled in figure 2, where four phases are presented: initiation, ramp-up, main transition and wrap-up. During this process the project manager is monitoring and controlling the whole process and is responsible for all things. The special part of this model is the evaluation, where the training is evaluated and the knowledge of the workers is tested whether they know enough about the product
Main transition
Transition
Development
Testing
Depoyment (upgrade)
Maintenance
SDLC inverse
software development process. As you can see there is an arrow back to the ramp-up phase which means that the best way is to start with maintenance as described earlier. After that you can cycle through the list and move responsibilities from your internal unit to the nearshore location.
6.6 Case Studies In the following case studies you’ll see that the model of the previous section is … in real life practices.
6.6.1 Case study Company A
Throughout the years company A developed an outsourcing strategy, where a global IT infrastructure is required, the development process needs to be known, teamwork is the key factor of successful cooperation, the design needs to be modular and extensible, and an excellent code-management system is implemented. All these factors come together through communication where information is processed. Higher management is responsible for the setup of the transition. The know-how is located company A and needs to be accessible for the nearshore unit. Therefore the business unit in the Netherlands forms the body-of-knowledge, where experts are always available for questions. Before transition begins, the whole process is mapped, which is used by the project manager to create a transition plan, which equal to a project plan. The transition phase starts with minor development responsibilities, like bug fixing or maintenance work. This is due to get to know each other, learn the product, and build a good collaboration environment. During the initiation of the transition process experience managers are moved from one location to the other to build a team for a certain project. Then the training of the people begins, which lasts about 3 to 6 weeks for developers to require proper verifiable knowledge about the product at hand. In this short period of time a personal relationship is build to gain trust on both sides. Once, the people are used to working this way, more and more responsibilities are moved from the Netherlands to the nearshore location. This period requires a lot of changes on several levels, where issues arise on organizational, technical, political, and cultural level. Company A experienced the most difficulties in the documentation and communication. It’s actually not the documentation itself, but the interpretation of the documentation. It sometime happens that people have another idea about a solution, which is immediately resolved by the company through a direct channel of communication. They keep a shadow role in place where something goes wrong.
6.6.2 Case study Levi9
Depending per project, there is a transition plan in place, which is based upon project management. This document holds everything from team composition to which tasks needs to be executed on what period of time. At Levi9 there several things very important for the transition phase. One is selecting the right people for every unique project. Second is trust, which is based upon personal contact. Therefore, in the beginning they immediately start with building trust. So, there is a period of 1 week where they’ve some social activities for team building and establish a solid working environment. Then, a learning period is needed to transfer the knowledge and learn the application, which can last around 1-3 months. There remains a point of contact at the outsourcing company, which actually is required to support the process. When something arises during the development and this person has not enough or no knowledge about it, new knowledge is acquainted. The most problems arise in the
documentation. Some parts are not good documented and aren’t interpreted in the good way (as we saw at company A), which costs a lot of effort to resolve. The most documentation consists of requirements where some of them are unclear. Some projects start easily with some bug fixing and slowly more and more responsibilities are shifted from one location to the nearshore location.
6.7 A generic process Besides the two companies described in the other Case Studies we visited some more. In general the transition period is a critical period, but a doable period if you plan ahead. In most cases we saw that this period starts with easy projects, like maintenance, bug fixing, etc. and slowly moves with more responsibilities. During the transfer period there is always a point of contact available, which is actually very important. The problems arise through interpretation: not properly explaining a requirement, not understanding a requirement, etc. It’s far most important to learn and establish a good collaboration environment. To be flexible is sometimes not the best for everyone, but can be very handful. The best way to succeed is to be enthusiastic, be about people, and especially be about learning. Conflicts arise where product are not working, communication fails, and the wiki is not covering every topic.
6.8 Lessons learned Create a Transition Plan - Provide a brief overview of the transition goals, any assumptions that the plan is based on, and any risks that have been identified that could severely limit your ability to complete the transition on schedule.
Give the nearshore employees a proper training - This training is intensive and expensive for companies, but essential for success. Here a company knows whether the nearshore location is well enough skilled in order to do the job. Informal communication is also a key motivator for all staff at both locations.
Communication - In development, projects, and transition, communication is the key. A lot of meetings are needed in order to keep everyone updated about the latest issues around the project. So, a solid communication platform needs to be in place between the internal unit and the nearshore location. Threaded discussion, instant messaging, blogging, web conferencing are examples of how to keep everybody informed.
Point of contact - As we saw in explanation of the transition process, and in the case studies, a point of contact is essential in this process. This contact needs to know every INS and out about the project and needs to know who is involved, what he or she does and how to reach them in time.
Start small - The best lesson here is to start with small projects and involve the people at the nearshore location directly. This will lead to a considerably motivated and well skilled people when they start learning the product. After the first step, you can easily move more and more responsibilities from the internal unit to the nearshore location.
Clear documentation - The foresee problems in the near future, it is advisable to argue about the deliverables through (video) calling and if possible on-site. This is meant to provoke wrong interpretations over the same documents.
Customer involvement - What nearshore companies want is customer involvement. Actually, it is what the developers want. There need to be a way to involve the customer (user of the product) in order to improve functionality and performance of the product.
6.9 References Carmel, E. & Tjia, P. (2005). Offshoring Information Technology, Sourcing and Outsourcing to a Global Workforce. Cambridge University Press.
Chadwick-Jones, A. (2004). Outsourced, But Not Out of Mind. Turning contractors into strategic partners. Mercer Management Journal, 29-36.
Dibbern, J., Goles, T., Hirschheim, R. & Jayatilaka, B. (2004). Information Systems Outsourcing: A Survey and Analysis of the Literature. The DATA BASE for Advances in Information Systems, 35(4), 6-102
Gopal, A., Mukhopadhyay, T., Krishnan, M.S. (2002). The Role of Software Processes and Communication in Offshore Software Development. Communications of the ACM, 45(4), 193-200
Gopalakrishnan, S., Kochikar, V. P. & Yegneshwar, S. (1996). The Offshore Model for Software Development: The Infosys Experience. Proceedings of the 1996 ACM SIGCPR/SIGMIS conference on Computer personnel research, 392-393
Guck, R. (2008). Managing Distributed Software Development. Retrieved September 21, 2008, from http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=ART&ObjectId=6002
Kraut R.E., Streeter, L.A. (1995). Coordination in Software Development. Communications of the ACM, 38(3), 69-81
Nicholson, B. & Sahay, S. (2004). Embedded knowledge and offshore development. Information and organization, 14, 329-365
Overby, S. (2003). The Hidden Costs of Offshore Outsourcing. CIO Magzine, 1-13
Rottman, J.W. (2006). Successfully Outsourcing Embedded Software Development. Published by the IEEE Computer Society, 55-61
Steinberg, J. (2008). Business Transformation Outsourcing: Lessons Learned. Retrieved on September 21 from: http://www.outsourcing.com/legal_corner/
Vlaar, P.W.L., Fenema van, P.C. & Tiwari, V. (2008). Cocreating Understanding and Value in Distributed Work: How Members of Onsite and Offshore Vendor Teams Give, Make, Demand, and Break Sense. MIS Quarterly, 32(2), 1-29
7 Outsource Planning and Cost Evaluation Metrics for Product Software Vendors
By Kevin Voges
Throughout the past 25 years of rapid advances in information technology (IT), most businesses have realized the strategic role and competitive advantage IT can provide to an organization. Many companies see opportunity to cut IT costs or extend IT staff while still maintaining the benefits of technology by downsizing the IT function and outsourcing it to firms that specialize in operating IT efficiently and reliably (Ward and Peppard, 2006).
A decision to outsource is driven by numerous factors, from a desire for cost-cutting or managing legacy systems, to the desire to focus on the core business, enable rapid business change or expansion, or obtain strategic advantage by keeping up with ever changing technology. During the last decade the IT outsourcing marketplace has undergone a dramatic transformation in scope and complexity. Also, the trigger to outsource has been shifting from a cost driven perspective to a resource driven perspective. It has been calculated for example that in 2012, there will be a shortage of 12.000 highly educated ICT professionals in the Netherlands (ICT Marktmonitor, 2008).
One of the newer trends in offshoring is the concept of Nearshoring. Nearshoring means sourcing service activities to a foreign country that is relatively close in distance or time zone (or both). The customer expects to benefit from one or more of the following constructs of proximity: geographic, temporal, cultural, linguistic, economic, political, or historical linkages.
One of the criticisms of the nearshoring concept is the management complexity that comes along with it. There are a lot of factors that influence the complexity of managing a nearshoring project including distance, which in turn influences time, resources and budget. Managing teams is hard. Managing staff abroad is even harder. This chapter will take on an operational view of the management process in a nearshoring project. We will take a look at the following topics: Planning, Cost estimation, Measurements and Service Level Agreements (SLAs). Figure 1 below gives an overview on the topics being covered.
Figure 5
Planning in a nearshoring context is essential to the success of a project. This chapter will reveal the complexities and basics that may occur in the course of a project en will elaborate on the corrective measures that can be taken if required.
Cost estimation for an IT project is difficult even with all of the models available to us. When embarking on a nearshore project, there are some extra factors that need to be taken into account when estimating costs. This topic will elaborate on several different models and techniques that are used for software cost estimation and will concentrate on what is used when being in a nearshoring context.
Metrics are the basis on which a project can be managed successfully. Most of the time this fact is very obvious. However, the real question is what metrics are best used when doing a nearshoring project. This topic will describe the importance of metrics and what KPI’s are used in nearshoring projects and why these are important.
SLA’s are an inseparable factor in any outsourcing situation. These contracts provide managers a basis on which to monitor the progress and or service when outsourcing or nearshoring to a third party.
This topic will describe how SLA’s are being used in a nearshoring context. One of the more interesting things we look at is for example the performance incentives that exist in practice and what works best.
In all chapters we will also take a look at the Outsourcing Management Maturity Model (see appendix B) that is based on the Capability Maturity Model, first introduced by Raffoul (2002), and how this model can be used in a nearshoring context. This model is a framework that was established to create effective vendor management structure, create measurable and enforceable service-level agreements (SLA’s), implement formal processes, and drive vendors to improve service quality. The model was also developed to enable outsourcing to be managed as an investment portfolio whereby cost is reduced, risks are mitigated, IT organization credibility is established, and outsourcing benefits are materialized in a timely manner (Fairchild, 2004).
Maturity models are common in many fields, from education to quality management and software engineering. Most organizations move through different stages in outsourcing. Some make the same mistakes repeatedly, while other progress toward an improved process methodology. Using this model we can look at the different topics and see if there is a mature outsourcing process in place and how to improve on this process.
7.1 Outsource Project Planning A detailed plan of the nearshore software development outsourcing can function as a tool to indicate that the project is being executed as expected. The software development outsourcing plan contains for example the details of the human resources involved, their skill sets and the time of completion of work at each stage. The software development outsourcing plan also reveals the complexities and basics that may occur in the course of the project development and will help corrective measures to be taken, if required.
When planning for software development in a nearshoring context, there are certain key points that become more important. The standard project planning tools have to be adapted to take into account the distance, which in turn influences the time, resources and budget. The programs themselves don’t really have to change; it is more the factors
that are already in the program get different levels of priority when not being in constant management control of the development team.
The phrase project planning encompasses creating work breakdown structures, and then apportioning tasks to staff members over time. It also includes the creation of various timelines and critical paths including Ghant charts, PERT charts or the like (Jones, 2004).
In a nearshoring context the following factors are prioritized higher than usual in the project plan.
7.2 Communication The IT industry is more dependent on the transfer of information and communication, than any other industry. The software development outsourcing companies are keen about maintaining a healthy communication with their clients. Barriers of any form that threaten to hamper the smooth flow of information at any stage can be disastrous to the whole outsourcing process, which may in turn lead to unnecessary negotiations and modifications. The major medium used for the transfer of information in outsourcing includes Internet, e-mail, chat, videoconferencing, collaborate tools & project management software.
Communication has to receive a higher priority because of a number of reasons. First of all this is simply because of the fact that there is more distance between the managers and development teams. What also plays a role is that there are language and cultural barriers that require more precise descriptions and thus more communication to get the message right. What this means for most companies is that more tools are being used to communicate and that the communication in itself is almost constant.
7.3 Design Specification Design specification is peculiar to software development outsourcing companies. Because of the cultural differences, the language that is used for design specification is very important. What is also important is that functional documents should more accurately describe a situation. For example a functional requirement that stated that an input field should be made, was eventually delivered as an input field, but with hexadecimal input instead of normal text input. The point of this example is that the delivered product was exactly what the functional document described but was not what the customer wanted.
So the main reason why the specification of functional documents are prioritized higher than usual is because of differences in languages and thus interpretation of certain information described in written form.
7.3.1 Reporting
Reporting becomes very important in a nearshoring context because this is the one of two most important tools that managers have to act upon when deviations in plans occur. The distance between the development team and the manager, forces the manager to rely on reports that are coming in from the development location.
7.3.2 Monitoring
This is the second most important tool for managers. Even with the almost constant communication, monitoring progress (or lack of it) during a project is made more difficult because of the fact that there is no “hands on” awareness of something going wrong or being late. The monitoring factor is of course dependent on the reporting factor. When the reporting factor is better, monitoring will be easier.
7.3.3 Escalation management
The reason why escalation management is given a higher priority in a nearshoring context is that it is very important to first of all, have a escalation procedure in place. Secondly, it is given a higher priority because the responsibilities in a nearshoring context should be well defined and distributed between the management location and the development location. This distribution works because it empowers the development location to handle more and more responsibilities over time.
Risks Involved in offshore software development outsourcing:
• Misunderstanding can arise between the vendor and the client if the discussion regarding the software application is not based on the final document.
• Misunderstandings may also arise, if the vendor representative and the client are not close to each other, as it is virtually impossible to explain all the finer details during the course of the conversation/discussion.
• The possibility of cultural clashes between most of the professionals who are in the East and clients in the West, cannot be overlooked.
• The difference in the time zones between that of the vendor and that of the client could be yet another barrier. Mutual adjustments have to be made in such situations.
Before an organization can improve its outsourcing process, it must accept that mistakes, surprises, errors, failures, foul-ups, and blunders are all part of the trying-and-testing game.
7.4 Outsource Project Cost estimation Software engineering costs (and schedule) models and estimation techniques are used for a number of purposes. These include:
• Budgeting : The primary but not the only important use. Accuracy of the overall estimate is the most desired capability.
• Tradeoff and risk analysis : An important additional capability is to illuminate the cost and schedule sensitivities of software project decisions.
• Project planning and control : This is to provide cost and schedule breakdowns by component, stage and activity.
• Software improvement investment analysis : Also an important additional capability is to estimate the costs as well as the benefits of strategies such as tools, reuse and process maturity.
There are quite a few models that have been developed in the past couple of decades. There are parametric models, expertise-based techniques, learning oriented techniques,
dynamics-based models, regression-based models, and composite-Bayesian techniques for integrating expertise-based and regression-based models. Many of them are proprietary models and hence cannot be compared and contrasted in terms of the model structure. Also every model is continually challenged by the rapid pace of changing software technology (Boehm et al, 2000).
7.5 Cost estimation in a nearshoring context In a nearshoring context, the approaches to cost estimation are very depended on the situation at hand. If specifications are clear, then cost estimation is done using certain models and techniques. But when specifications are not clear, time and material constructions are used, which differ per company and country.
Metrics for evaluating an outsourcing project typically fall into two categories:
• Process metrics : For the evaluation of the steps required to create work from inputs into outputs.
• Output metrics : For the evaluation of all the deliverables including the finished product.
In the next section we will explain these metrics and give examples.
7.5.1 Measuring processes
There are steps that can be followed to successfully measure processes (Power et al, 2005). The first step in measuring a process is to define the process itself. When there is no clear definition of the process that should be measured, an organization might measure different things at different times. In outsourcing, you must clearly define the process and its components.
The second step in measuring process is articulating the attribute being measured. You can measure multiple items for any artifact. In weight training, for example, measures might include an individual’s body fat, stamina, and muscle strength. Composite indicators, such as body mass index, integrate individual indicators. Body mass index gives a composite score of an individual’s physique by compiling height and weight indicators. In outsourcing, it’s important to clarify what each indicator measures and how each indicator relates to other indicators. Attributes such as the time taken to complete a process or the number of critical issues that arise during the process are common measures (Power et al, 2005).
The third step is analyzing the measures. Scores are meaningless unless understood within a given context. Context normally involves the process’ history and outsider information. The process history compares how you are currently doing with how you did in the past. Developing a historical context for evaluating metrics requires time and experience. Comparing how you did today to how you did yesterday won’t expose anything brilliant; however, comparing how you did today to your average monthly performance will provide some insights (Power et al, 2005).
Outsider information is of a more immediate context than history, which takes time to develop. Using external benchmarking, organizations can compare their indicators to those of other organizations.
Two types of benchmarking are common:
• The organization compares itself to the average performance of organizations in the industry. This type of benchmarking is ideal in the process’ early stages, because it indicates where the organization should be relative to rest of its industry.
• The organization compares itself to industry leaders. This is more suitable in the process’ later stages, when the organization is looking to reach higher goals. When measuring benchmarks, it’s important to use comparable operations—that is, compare apples to apples and oranges to oranges. Without a base for commonality, the comparison will not be grounded in any reality, and the resulting information will be invalid or not useful. The fourth step involves devising appropriate interventions to improve performance in certain areas.
Interventions can serve as positive or negative reinforcements. Positive reinforcements involve understanding what actions worked well and repeating them to strengthen the process. Negative reinforcements entail uncovering what went wrong, correcting it, and then applying the correction to improve the process. For example, if you know that your vendor selection process is satisfactory and sound, you must ensure that all successive projects follow the stated methodology to gain the same positive results. On the other hand, if you find shortcomings in your attempts to transition the project, you must identify them and devise and implement suitable alternatives. Managing knowledge helps organizations devise appropriate interventions. The fourth step feeds back into the second or third step, depending on where you need new measures.
7.5.2 Measuring outputs
Output metrics are more subjective than process metrics and vary significantly with the customer. Organizations derive these measures from an understanding of what the customer wants. Outsourcing processes can have internal and external customers. If an organization outsources its human resources functions, such as payroll processing and employee benefits administration, its employees are the customers of interest. If the organization outsources call center management, the people who buy its products and service, and call the center are the customers of interest. Not surprisingly, the first step in developing good output measures is identifying customers and their needs (Power et al, 2005).
Most processes have multiple categories of customers. Although all customers might share certain characteristics, their experiences and needs can distinguish them. Experienced customers’ needs will differ from those of new customers, as will the needs of frequent or repeat customers from those of occasional customers.
The second step in measuring output involves devising surveys or other instruments to elicit customer perceptions of the process of interest. Customers will quickly become frustrated if they see their opinions ignored or find that it makes no difference in how you deliver the product or service. The third and fourth steps of measuring outputs are the same as for process metrics (Power et al, 2005).
7.5.3 Key Performance Indicators
Key Performance Indicators define a set of values used to measure against. These raw sets of values fed to systems to summarize information against are called indicators.
There are many different key process indicators that can be used when in a nearshoring context. Organizations that are veterans at the outsourcing game know that the success of a project is not one-dimensional. They know that outsourcing is not an end goal in itself, but rather a way to achieve any number of goals. They also know that it is unwise to assume that goals are achieved inherently upon signing an agreement; progress needs to be measured and tracked.
One successful outsourcing measuring tool is the contract scorecard. The scorecard establishes not only the quality of the service, but also the financial outcomes, how the relationship is functioning and if the deal is achieving its strategic aims – in sum, assessing the overall success of the deal from a holistic view. The four components used to assess a successful outsourcing deal are service quality, financial, relationship and strategic (Cullen, 2005).
7.5.4 Service Quality
Service-quality key performance indicators (KPIs) are the operational metrics representing the basic outcomes of service delivery. It is rare to find a deal without these metrics. Elements to assess include the following:
• Accuracy : Whether information is correct.
• Reliability/availability : Whether service is accessible (for example, uptime/downtime, abandon rates, outages).
• Completeness: Whether activities are done in full (ie. data entry, processing, documentation).
• Efficiency : Whether work is done fast.
• Response Rate : Whether reactions are fast (initiation, turnaround, resolution).
• Timeliness : Whether deadlines are met.
• Satisfaction : Whether users/customers are pleased.
7.5.5 Financial
Financial KPIs are monetary metrics comparing current costs with different fiscal points. These fiscal points can be past data, costs under previous service delivery regimes, current market rates, and the effect on overall costs. Historical cost is the most popular fiscal point as it is often the easiest to measure.
• Historical : Compared with previous periods.
• Baseline : Compared with an agreed baseline (when the services were insourced or when they were performed by a different service provider).
• Competitiveness : Compared with market rates (assessed through benchmarking).
• Total Cost of Ownership (TCO) Contribution towards reducing (or, conversely, escalating) the entire supply chain, total asset cost or total technology costs.
7.5.6 Relationship
Relationship KPIs are perception metrics assessing behaviors exhibited by both parties. These are ‘soft’ metrics in that they represent the parties’ opinions and are thus not open to ‘disputes of fact’. If one party’s perception is not what the other party believes is appropriate, often what is required is better communication in order to change the perception. These metrics are becoming more popular as organizations learn that a dysfunctional relationship is often a leading indicator of cost or service suffering.
• Communication : Frequent and honest.
• Meeting Needs : Proactive and reactive.
• Creative Solutions : Better ways of doing things.
• Conflict Resolution : Focus on solving problems.
• Management Time : Provide time and focus.
• External Relations Cohesion : Project a united front and don’t discuss issues outside.
• Industry Model : How others see the relationship.
• Positive Interaction : Enjoy working together.
• Integration : The supply chain appears seamless.
7.5.7 Strategic Metrics
Strategic KPIs are high-level metrics that demonstrate results beyond the letter of the agreement. These metrics apply if there is a bigger picture to the deal than merely the exchange of cash for services.
They include the following:
• Objective Achievement : The degree to which the reasons for outsourcing are being met (eg. core focus, innovation, standardization).
• Innovation : The introduction of better practices, enabling applications (purpose-built intranet, online services) and business improvement ideas.
• Business Contribution : Goals beyond just the exchange of cash for services (e.g. joint product offerings, R&D initiatives, knowledge transfer).
• Corporate Alignment : The extent to which the service provider conducts business in line with the client’s wider goals.
7.6 Outsource Service Level Agreements In outsourcing a software project, traditionally, the onsite company hands over the management and the day-to-day functions of the project to be developed to a company established offshore. The onsite and the offshore companies enter into a contractual agreement. This agreement provides the terms and conditions agreed between the two
companies related to the transfer of services. By this agreement, the offshore company acquires from the onsite company the documentation of the project to be executed, along with transfer of people, assets, and other resources.
Over a large number of years important work has been carried out by CTTA (1987). A collection of best practices, which is called Information Technology Infrastructure Library (ITIL), focuses in particular on the investigation of the various aspects of Service Management and introduces as one of the main concepts for Service Management the Service Level Agreement (SLA). However, the quality of services in service level agreements and its metrification are not addressed.
In the Capability Model for IT enabled Outsourcing Service Providers. (Siegel and Gopal, 2002) a framework and an improvement path is described that customers should expect service providers to progress along from the minimum level of having the capability to deliver a service that meets client requirements, up to the highest level of enhancing value through continuous innovation. In this Capability Model, which has five levels of improvement, customer requirements management and measuring and control of service processes are explicitly addressed. For example, on the maturity levels 2 and 3 it is stated that procedures for SLA specification, measurement and control should be developed and implemented (Trienekens, Bouwman and van der Zwan, 2004).
The OMM framework defines 5 levels of maturity concerning SLA’s:
• Level 1: SLA reporting does not exist.
• Level 2: Here SLA’s are established for all outsourced services to quantify service outcome and to track processes to detect and address target deviations.
• Level 3: SLA targets are reported regularly. Outsourcing vendors have implemented a balanced scorecard to ensure SLA prerequisites are being met.
• Level 4: Service Level Agreement targets are met continually.
• Level 5: Service Level Agreement targets are continuously exceeded.
One of the most important trends is the shift of the goal of an SLA from being a financial and technical contract towards an instrument for the management of the customer’s expectations.
7.7 Some lessons learned When companies decide to start nearshoring projects, there are a few things that should be considered in order to make sure that companies know what they are doing.
First of all, companies need to make sure that they have their own internal processes up to par before even considering to nearshore a project. If this is not the case, the risk that a project will not turn out the way the company had planned is very high. There are a lot of extra steps in the nearshoring process where information can get tied up, changed and misinterpreted.
Second of all, the main reason why companies choose nearshoring is no longer a cost only motivation. It is more and more motivated by the fact that talented resources are getting scarcer every day. Small countries like the Netherlands will have to start looking
abroad more and more to find the resources and talent this knowledge driven country needs.
Third, there are no standard ways of doing nearshoring. It is based on learning as you go and developing the relationships abroad over time.
Lastly, it has often been said that culture plays an important role in any relationship abroad. In a nearshoring context, this role is becoming even more important because of for example the realization that managing teams abroad should be done by local people instead of the standard paradigm that companies need their own people to retain control. Management control and controlling costs are best done by local people.
7.8 References
[1] Currie, W.L. (2003). A knowledge-based risk assessment framework for evaluating web-enabled application outsourcing projects. International Journal of Project Management, 21, 207-217
[2] Bendeck, F., Goldmann, S., Holz, H., Kotting, B. (1998). Coordinating management activities in distributed software development projects. This paper appears in Enabling Technologies: Infrastructure for Collaborative Enterprises, 1998. (WET ICE '98) Proceedings., Seventh IEEE International Workshops on Publication Date: 17-19 Jun 1998 On page(s): 33-38,
[3] Jones, C. (2004) software project management practices: failure versus success
[4] Sedigh-Ali, S., Ghafoor, A., Paul, R.A. (2003) Metrics and models for cost and quality of component based software. Proceedings of the sixth IEEE International Symposium on Object oriented Real Time Distributed Computing
[5] Bourgault, M., Lefebvre, E., Lefebvre, L.A., Pellerin, R., Elia, E. (2002) Discussion of metrics for distributed project management: preliminary findings. This paper appears in: System Sciences, 2002. HICSS. Proceedings of the 35th Annual Hawaii International Conference on, Publication Date: 7-10 Jan. 2002 On page(s): 10 pp.-
[6] Boehm B., Abts C., Chulani S. (2000) Software development cost estimation approaches – A survey. Annals of Software Engineering, Volume 10, Numbers 1-4, 2000 , pp. 177-205(29)
[7] Smith, M.A., Mitra, S., Narasimhan, S. ( 1996) Offshore outsourcing of software development and maintenance: a framework for issues. School of management, Georgia institute of technology, Atlanta
[8] Kovacs, G.L., Paganelli, P. (2003) A planning and management infrastructure for large complex, distributed projects-beyond ERP an SCM. Computers in Industry, 51, 165-183
[9] Ramos, S., Oliveira, K.M., Anquetil, N. (2004) Legacy software evaluation model for outsourced maintainer. Proceedings of the eight European conferences on software maintenance and reengineering.
[10] Herbsleb, J.D., Mockus, A. (2003) An Emperical study of speed and communication in globally distributed software development. IEEE transactions on software engineering, 29(6), 481-494
[11] Heiko Gewald Kay Helbig (2006) A Governance Model for Managing Outsourcing Partnerships A View from Practice
[12] Rafael Prikladnicki,1*,† Jorge Luis Nicolas Audy1 and Roberto Evaristo2 (2003)Global Software Development in Practice Lessons Learned
[13] F. Franceschini and M. Galetto A. Pignatelli M. Varetto (2003)Outsourcing: guidelines for a structured approach
[14] Sandra A. Slaughter, Donald E. Harter, and Mayuram S. Krishnan (1998)Evaluating the Cost of Software Quality
[15] Jos J.M. Trienekens, Jacques J. Bouman and Mark van der Zwan (2004) Specification of Service Level Agreements.
[16] Siegel, J. and Gopal, A. 2002. eServicesCapability Model (eSCM) v1.1, Carnegie Mellon University, http://itsqc.srv.cs.cmu.edu/escm/
7.9 Appendix Level Description
Vendor Management Fundamentals
This state represents the worst‐case scenario. It is characterized by a narrow contract management focus, misaligned expectations, absent SLA reporting, nonexistent processes, and no
foundation to build trust and create value. The remediation strategies revolve around changing vendors constantly, but with limited success.
Defined Service Outcome
To reach this status, the following conditions must
be met:
• Establish remediation strategies to address vendors' miscommunication issues, redefine roles and responsibilities, and reset expectations with outsourcing vendors.
• Establish a relationship management structure to create a winning relationship.
• Establish SLAs for all outsourced services to quantify service outcome.
• Establish SLA tracking process to detect and address target deviations.
• Establish engagement management processes to request new services from outsourcing vendors.
• Enforce benchmarking strategies in outsourcing contracts to constantly assess outsourcing competitiveness.
Measurement This level can be reached by fulfilling the following criteria:
• SLA targets are reported regularly.
• Outsourcing vendors have implemented a balanced scorecard (or its equivalent) to ensure SLA prerequisites are met.
• Change management processes are implemented to ensure outsourcing vendors adhere to enterprise architecture principles.
• Escalation management processes are establishedto address service malfunction with outsourcing vendors.
• Business continuity processes are implemented to ensure outsourcing vendors' disaster recovery services meet business requirements.
• Outsourced services are benchmarked at least once per year.
• Service single points of failure are identified.
• Business and IT measures are correlated and reported regularly.
Trust Level 4 can be attained by meeting the following
conditions:
• Vendors' security arrangements are proven to be in line with industry standards.
• Success stories are identified, whereby outsourcing arrangements reduced cost, improved service quality, and increased responsiveness.
• Service‐level agreement targets are met continually.
• Capacity management processes are established to issue yearly capacity plans, track monthly usage against forecasts, and alert IT organizations and business units to service upgrade timing and cost implications.
• Vendors' command‐and control processes are integrated and
automated.
• Benchmarking costs are reduced by replacing extensive benchmarking studies with third‐party consultants validating selected outsourcing proposals.
• Vendors' delivery processes are based on operations excellence best practices, or their equivalent.
• Service single points of failure are addressed.
• The IT organization's contribution to business metrics is reported regularly.
Recognized Business Value
The following conditions are required:
• All outsourcing goals are accomplished.
• Service‐level agreement targets are continuously Exceeded.
• A process maturity model is adopted to evolve outsourcing management formal processes.
• Outsourcing vendors' unit prices are competitive, and at least 90 percent of new proposals are cost Effective.
• New technology is leveraged to enable strategic business initiatives.
• Vendors' new skills are provided whenever demanded by business units.
• Outsourcing arrangements' contribution to business cost reduction and performance improvement strategies is quantified.
Table 4. OMM Model (Fairchild, 2004)
8 Requirements engineering and Release Planning By Diana Sidharta
The requirements engineering and release planning process are parts of the product management process. These processes aim to gather requirements, processing these into product requirements and divide these into releases and assign developers to execute tasks.
This chapter focuses on the effect of the process- and workflows within the requirements engineering and release planning when a part of the development department or the department as a whole is outsourced. In order to draw some conclusions, qualitative research has been conducted where in two and a half weeks nine Dutch software product companies have been visited. During this empirical study, the conclusion can be drawn that requirements engineering and release planning are processes that are not outsourced by software product companies. To what extend can work be distributed?
Product software companies outsource their development department, but draw a line when it comes to the extension of letting the outsourcing department participate in the requirements engineering and release planning process.
The objective of this chapter is to show that it is possible to distribute some aspects of the requirements engineering to an outsourcing location, but that this requires good and clear communication between the different locations.
8.1 Reference Framework Within software product companies, different processes are used as a guideline for a specific type of job. These different processes are somehow related to each other, and to certain stakeholders. Software product companies have a product management process, what consist of multiple processes. The reference framework described in figure 7.1. is set up in order to create a better understanding within requirement engineering and release planning, and the related domains within the product management domain.
The structure of the framework is based upon the artifacts of product management, and upon the set of stakeholders identified within the scope of work of the product manager. It provides information about key process areas, stakeholders and their relations. The framework shows four process areas and the sub functions of the product management domain and the relations with internal and external stakeholders.
Figure 7.1 Reference Framework for Software Product Management. 1
The four process areas that are important in software product management are portfolio management, product roadmapping, requirements management and release planning.
Process area Purpose
Portfolio management Entails the decision making about the set of existing products, introducing new products by looking at the market trends and the product development strategy, making decision about the product lifecycle, and establish partnerships and contracts.
Product roadmapping Strategic planning of releases in advance, by taking the availability of the resources into account.
Requirements management Contains the activities of gathering, identifying, revising and organizing incoming requirements from the various stakeholders.
Release Planning Is the mapping of requirements to software releases.
Table 1.1 Definitions of the Process areas.1 8
This chapter focuses on requirements engineering and release planning in relation to development. The preceding step of requirements engineering is roadmap construction, which is part of product roadmapping.
Roadmaps are employed as decision aids to improve coordination of activities and resources in increasingly complex and uncertain environments.13 Roadmap construction is related to requirements organizing and the release definition. To explain these two fragments of the framework, the roadmap construction viewpoint is described.
Where release planning is the mapping of requirements to releases, there are two types of release planning: Road-mapping and operational planning.8 Product roadmapping can be expressed as a strategic method, whereas the Release Planning can be expressed as an executable method. The other fragments within the portfolio management are not discussed here and the topic of roadmapping will not be further elaborated.
With respect to the research in the field of requirements engineering and release planning, the process areas connected to the development side of software product management will be admitted in this chapter. This chapter will be more on the executable part of the topic and therefore topics from a more business side perspective will not be elaborated. It will help to create more understanding about the requirements engineering and release planning process in combination with the subject outsourcing. This chapter can therefore support product managers by setting up and establish a solid process.
8.2 Requirements A requirement is ‘a condition or capability needed by a user to solve a problem or achieve an objective’16. A user in this case can be seen as the end-user or as the customer. Requirements can be defined as an assessment of the needs of a system, by including why the system is needed; what feature will service or satisfy the need; and how the system needs to be constructed.
Developing a software product is done by involving the different stakeholders representing the different end-users, in order to set up requirements that fulfill the market needs. Because requirements can be set up from a certain point of view, a distinction in type of requirement can be made, such as: business requirements, user requirements, functional requirements, and technical requirements.
Requirements can be set up on a high level, where the focus is on the goals and objectives of the system on managerial level. These are also known as business requirements. The other type of requirements is set up on product level, where the focus will more be on the development of an actual product. User requirements address what users need to do their job. Functional requirements are also called behavioral requirements because they address the system functionality. Technical requirements are the non-behavioral requirements and address an attribute or quality of the system, and these types of requirements include areas such as performance, design, and implementation.
Within the engineering phase, requirements of users and stakeholders are identified and documented. Requirements concern the functionality and the quality of the product.
The requirements engineering phase is a more constructive part of the production process, and focuses more on the construction of the realization, whereas requirements management focuses more on establishing common understanding between the customer and other stakeholders that will be addressing the requirements at an early stage in the
project life-cycle, and establish suitable base-lines for both development and management use to maintain control. Therefore one can say that the requirements engineering focuses more on the what to establish, and the requirements management more on how to establish.
8.2.1 Requirements management
As mentioned in the introduction of this paragraph, requirements management focuses more on establishing common understanding between the different stakeholders in order to establish suitable base-lines for development and management.
The reference framework includes the requirements management process. This process has three important steps: requirements gathering, requirements identification, and requirements organizing. These three steps are followed in order to create a product requirements list.
Within the requirements gathering all requirements of the internal and external stakeholders are gathered. Stakeholders who can be involved are sales and marketing, the customer, the company board, the market, R&D, and development. These stakeholders all have their own vision of the product and requirements can therefore differ or be identical to each other. Nevertheless, the requirements are set up into a list that will be analyzed and identified by the product manager.
The product manager analyses the gathered requirements, and translate these into product requirements. Duplicate requirements are removed and requirements that describe a similar functionality are connected and rewritten.
The last step of the requirements management process is the requirements organizing. Figure 7.2. shows the whole requirements management process as stated in the reference framework. Within this figure, the requirements’ organizing is related to the roadmap construction. The roadmap construction consists of a planning of the number- and types of releases of the product for the upcoming year. The roadmap construction is based on the theme and core assets and is validated by the company board.
Organizing the requirements therefore means that the requirements also need to fit the theme and the core assets of the product. Within the requirements organizing step, product requirements are selected and organized into product and core asset. These requirements are listed in a requirements list and are potential product requirements for a new release
Figure 7.2 Requirements management cycle.
8.2.2 Requirements engineering
Requirements engineering is a cyclic process that involves requirements elicitation, specification and validation, and verification, to identify, document and validate user requirements, where the user is available to participate in the process.
The requirements engineering phase is the first step towards a solution of the data processing problem. During this phase, the user’s requirements with respect to the future system are carefully identified and documented. These requirements concern both the functions to be provided and a number of additional requirements, such as those regarding performance, reliability, user documentation, user training, and cost.
Within requirements engineering, three phases can be distinguished:
Requirements elicitation - Elicitation is all about creating understanding about the problem for the set up of new requirements.
Requirements specification - Once the problem is understood, the problem needs to be described. In this phase a product specification document is set up, which describes the product to be delivered, and not the process of how it is developed.
Requirements validation and verification - When the problem is described, the different stakeholders involved have to agree upon its nature, where the requirements are validated and verified.
Figure 7.3. resembles the process of requirements engineering, with its interaction with the user.
Elicitation Specification Validation
User
Problem Domain
User feedback
UserRequirements
Knowledge
RequirementsSpecification
Requirementsmodels
Request moreknowledge
Validationresults
DomainKnowledge
DomainKnowledge
Models tobe validated
by user
Figuur 7.3 Framework for the requirements engineering process.
The focus will now be on the possibility of outsourcing the requirements engineering as a part or as a whole. In this situation the owner of the requirements engineering process is a developer, or a representative of the development department.
A conclusion that can be drawn based on figure 7.3. is that the owner of this process needs to have knowledge on the problem domain. What means that they need information about the market, problem, rules and regulations, and users. Because product software is related to a certain market within a specific country, an outsourcing company does not have any knowledge about the rules and regulations for example.
There are two solutions for this problem, a company can either choose to educate their developers and let them also participate in the specification phase, or by setting up requirements within the on-site location. The last solution means that distribution of work is geographically divided, where developers are not involved into the elicitation and specification phase. In this case, development does have any influence on the set up of requirements, but are only developing the requirements/tasks.
The disadvantage of not involving the development department within the requirements engineering process, is that their vision from a technical perspective is not taken into account. An example is for instance Company A from the business case. This company does not involve developers into their requirements engineering process. Developers are only developing the tasks that is devoted to them. Even though they are only developing, they know that some technical requirements could have done in another way that makes the product more efficient.
The advantage of involving the development from the first phase on, is that developers can relate to the problem and go through the process, setting up requirements from a technical perspective. What might influence the communication time. Because creating understanding within an environment that does not have any relation to the problem domain, where it is much easier when the developers all have knowledge about the domain. So educating the developers first may lead to time saving and better products at the end.
8.2.3 Requirements communication
During the requirements engineering and requirements management process, different stakeholders are related to these processes. The different stakeholders all participate in the requirements gathering phase, but they do not know if the new release of the product will contain the requirement that they have set up. Therefore, communication between these different groups is an important aspect. The different stakeholders need to be informed about the new release and its new requirements.
Within the development of a product, different stakeholders are involved in the requirements gathering phase. The procedure of setting up requirements until the processing of the requirements into a product requires good communication between departments and stakeholders.
A product manager is responsible for managing the requirements engineering and requirements management process, and communicates with the external as well as the internal stakeholders and forms the centre of communication.
The type of communication depends on the situation where requirements are communicated in. Gathering requirements from different stakeholders can be collected in a face-to-face environment, where the product manager and the internal and/or external stakeholders can be part of. All stakeholders can come up with requirements for the new release of the system. Face-to-face environments can be done in form of interviewing all the stakeholders separately, but can also be done in a meeting involving all stakeholders. Interviewing all stakeholders separate provides the product manager a clear overview of what each stakeholder exactly wants in a product, involving all the stakeholders in one meeting makes it able for all the parties to communicate with each other about ideas in order to create new requirements altogether.
All the requirements mentioned are documented, to provide the product manager and stakeholders’ liability when certain requirements are miscommunicated. Interviews and records of the meetings should be worked out into a document and send to all the stakeholders, in order to keep them informed of the requirements that are included and omitted in the next release.
The planned requirements for the next release need to be communicated with the development department. A product manager will select the requirements that need to be implemented in the next release, and assign developers to a certain task. Communication between the product manager and the developers must be supported, because the developer needs to know what a product manager expects from him, and the product manager needs to monitor the status of the requirement. Face-to-face communication can occur in this situation, but will take more time to approach all the developers in to assign tasks, and request the status of all tasks. Communication between the product manager and developers can also be supported by a system which keeps track of all tasks and employees. As support, communication through e-mail, IM, and telephone should be available, when certain tasks are not clear for one of the parties.
The use of communication is important, a product manager can directly see if the work planned still match the (release) planning, and who is responsible for certain tasks. It provides information about the development status of the product. When there is a probability that a release is behind schedule, information from the system can be used for decision making on managerial level.
8.3 Requirements modeling Creating understanding in the development of requirements requires a unified way of documentation. In order to develop a requirement, the development needs some specific information before they start developing. This is also called requirements modeling.
A product manager needs to give a time estimation for each task, and provides an estimation in consultation with a developer based on a user story. A user story is a reminder to have a conversation with your project stakeholders. User stories capture high level requirements, including behavioral requirements, business rules, constraints, and technical requirements.
Figure 7.4. represents the meta-model of requirements engineering. Within this model each step of the proces is defined together with the actions that are important for the execution of a step. In the model, deliverables are stated. In figure 7.4. deliverables are user story, requirements list and the product requirements list. The product requirements list, is the final version of the requirements list where identical requirements are connected and redefined. This figure also shows that the user story identifies the user needs, and defines the situation or problem by creating and defining a possible solution and take the constraints in mind. The meta-model creates more understanding about modeling requirements.
For the requirements engineering cycle, the process ends by defining a product requirements list, what will be the trigger for the release planning proces. The importance of requirements modeling within the release planning process is that the different stakeholders know what information needs to be communicated. An example is: that a developer needs to know what type of requirement he needs to develop, what means that a requirement description needs to be modeled in a certain way to make it understandable for them. Figure 7.5. shows the developed deliverables and the related information, that is required in order to process and eventually distribute a software product towards the customers.
Requirements Gathering
Define situation/problem
Identify user needs
Determine constraints
Define possible solution
Create user story
Set up requirements list
RequirementsIdentifying & Organizing
Define FunctionalRequirements
requirements identification
Define Product requirements list
DefineNon-FunctionalRequirements
[Redefine requirement]
[Product requirement]
Figure 7.4. Requirements engineering meta-model
Prioritize & SelectRequirements
Identify type ofrequirement
Identify urgency
Identify Businessvalue
Release definition
Calculate Priority
Select prioritized requirements
Define release content
Specify requirements tasks
Estimate workload per task
Calculate time estimation per release
Define Release definition
Scope change management
Validate release definition
Assign resources to tasks
Recalculate workload
Launch preperation
Set up User manual
Compare changes to definition
[Not validated]
[Validate]
Make software available
Distribution product
Figure 7.5. Release planning meta-model
The conclusion that can be drawn from this figure is, that within release planning the important aspects in relation with the requirements modeling is that requirements are divided into several tasks. This because a requirement in practice can be seen as a whole function of a product, so it can consist of multiple tasks. Thereby, the workload for each task needs to be calculated in order to estimate the release date when a set of requirements are developed in a release. Calculation of workload of each task is done by (a representative of) development.The product manager assigns a level of priority to each task, by receiving the workload calculation, the product manager can divide the tasks per release. which are assigned to developers.
Within requirements modeling, communication between product manager and development is required, in order to exchange information between both parties like tasks and status’. The product manager is responsible for requirements modeling.
As seen in the two meta-models, processing requirements requires clear communication between stakeholders, that is done in form of documentation.
8.3.1 Requirements analysis
During the requirements gathering phase, all stakeholders participate what results in a list with different types of requirements. As mentioned before, these requirements will be translated into a list of product requirements. A new release can also be seen as a project that has a fixed time and budget for the development. Therefore, only a selection of the listed product requirements can be developed within the boundaries of the project.
Requirements are analyzed within two different processes within the product management. The first moment of analyzing requirements is within the requirements management process, where the product manager has to analyze the gathered data from the stakeholders and removed duplicate requirements and connects and rewrites requirements with a similar functionality. The second analysis is done within the release planning process, where the product requirement needs to be prioritized.
8.4 Release planning The release planning phase continues from the requirements engineering phase, where this phase ends by specifying and organizing the requirements. Releases are known to be new versions of an evolving or new product. A release plan determines proper priorities and assigns features to certain releases.
“Release planning for incremental software development assigns features to releases, such that most important technical, resource, risk and budget constraints are met”. 10 A release plan is only necessary for new development or major enhancement projects that will utilize a phased or incremental approach for development and implementation.
The release planning process is triggered by an incoming list of product requirements, where a release manager is responsible for prioritizing the requirements and setting up a release plan.
Figure 7.6. Release Planning Process1.
After prioritizing the requirements, a selection of the prioritized requirements will be made that needs to be implemented in the next release. How the process continues from the requirements selection can differ per company. The way as described in the framework is that a release definition is set up, and validated by the different stakeholders before the product is being developed and launched. A release definition contains information about the next release of the product, the estimated time to develop, and shows which requirements will be developed.
Within the release planning process the product manager is responsible for prioritizing requirements and allocating this to a release. The release date is planned, based on availability and capability of the resources in relation to the development of new requirements.
Planned requirements can be used as guideline for developers. Development entails not only technical design, coding, unit tests, but also production of collateral materials, such as brochures and training material.
In order to release a developed requirement and to ensure a sufficient level of quality, the developed requirements needs to be verified by several tests. Typical types of tests are: functional unit tests for small units, these are performed by a tester which is not part of the development team; integration test focuses on dependencies between modules; system
tests for the complete software system; acceptance test for the complete product (software and collateral); and a final test of the installation files. In the chapter testing, these tests are elaborated.
Figure 7.7 Release Planning Methodology12
When requirements do not pass the test, it needs to be fixed by the allocated developer; otherwise, the product can not be released. The figure of the release planning methodology creates a better understanding of the release planning process. It gives the key stakeholders the opportunity to manage the uncertainty in the release planning process in a more effective manner.
This methodology is not designed to develop a set of story combinations that are optimal instead of generating single optimal combination of stories. The stakeholders can then choose from the combinations. In this way the method guides the stakeholders.
The release planning process starts with the current practices of gathering all user stories and estimating both the size of each story, expected value and project velocity. It recognizes that values are subject to levels of uncertainty. A development team cannot estimate the business value of a story, due to the high variation possible in financial return. Similarly, can the project velocity change from iteration to iteration what results in the differing amounts of work what is carried out per iteration. The cause can be that members of the core development team have to temporarily leave the project to focus on other activities. This can be another project or supporting existing software systems.
The methodology shows that there are three key measures within this process, that makes it able to calculate and derive the urgency of a requirement. The measurement is eliciting from the development and management team. Then optimistic, pessimistic and most likely values for task sizes are given to the task size, business value and the project velocity. Once distributions are known, risk analysis simulation is performed to acquire the distribution in real time in order to complete a selection of stories in a release. Similarly, the distribution for the combined business value of the stories can be obtained. In this way the stakeholders can explore the earnings of various release plans in terms of the likelihood of returns and the likelihood of completion on time. 12
An important aspect of the release planning is prioritization of requirements. In most situations the product manager prioritizes the requirements together with stakeholders (company board, marketing etc.) In most situations there are different and conflicting priorities between the different stakeholders.
The increasing focus on value creation as a result of software development implies the question of the impact on value for the different features or requirements. In order to determine the most attractive feature, values must be allocated to certain dimensions such like value and urgency.10 Each company can measure the value of different dimensions, but it will be most likely that value and urgency will be chosen.
Value is addressed to the assumed impact on the value of the final product, where the value is considered to be independent of time. Urgency is addressed to the time-to-market aspect, which is relevant for reflecting the market needs and competitor analysis information.
The first release contains the requirements of high value and high urgency. Depending on the implemented development method, the classification of the prioritized requirements may differ.
8.5 Business case Case A: Outsourcing your development within your company
Company A is a Dutch product software company that develops and market products for the mobile telecommunication market. They develop mobile application services like text messages, browsing, and mms.
This company outsources the development of their products in the Czech Republic and also in India. This company has multiple establishments abroad, where employees are in service for the Dutch company. The difference between the establishment within the Netherlands (on-site location) and in the Czech Republic (nearshore) or India (offshore) is that the type of work is limited. The establishment in the Netherlands focuses more on the managerial part of product development and is also the ones who decide what to develop, where the establishments in the Czech Republic and India are more focused on the product development.
Development is an activity what is a part of the R&D department. This department has several activities that are related to managerial activities and development activities. In order to see what activities can be outsourced, this company grouped activities that are related to each other. The outcome is that they had three main activities: construction, technical product management, and strategy, commercial, product management. Distinguishing these activities makes it able to see where each activity fits within the global model on-site, nearshore, or offshore. How this company distinguishes the activities per location is shown in figure 7.8.
Figure 7.8. Global model.
The conclusion that can be drawn in this situation is that the construction activities are outsourced in a nearshored as well as in an offshored environment. The managerial related activities are only done on-site except for project management which is part of the construction activity. In this case release planning is not outsourced, but requirements engineering is outsourced to some extend. In figure 7.8. we see that the set up of system requirements is done on the nearshore location, where user requirements are done on-site.
In practice, the development department is not involved with the requirements set up. Developers do not have any influence on setting up system requirements or any other type of requirements. The internal stakeholders within company A are within the strategy & Commercial BU Product management, and also the technical and operational product management. The strategy&commercial BU product management are responsible for the set up of requirements based on a strategic level, where the technical and operational product management is responsible for the set up of the user requirements. In the global model it is stated that the system requirements are set up in the nearshoring environment. But the situation within the physical company is different than it is modeled in figure 7.8.
In order to see what how the requirements engineering is related to the development department in this case, the communication lines within the company needs to be clear. The communication process of the on-site and outsourcing location is described in figure 7.9.
Figure 7.9. Communication process within Company A.
The product manager is responsible for the requirements engineering process, where he gathers, identifies, and organizes the requirements before setting up the release plan. In the environment of company A, the product manager communicates together with project managers. Product managers assign project managers to execute a project, and to
assign available resources to that project. Together with the developers, project managers can provide an estimation about the duration of the project based on development time of all the requirements. The project managers report the time estimation to the product managers. This makes it able for a product manager to set up a release plan.
A product is split in several components which is assigned to a team, which can be split by product platform or by individual responsibility. The developer is also the code owner, in order to prevent concurrent development.
The requirements, Design, Implementation, and Testing are documented. Remarkable is that the way of working in their nearshore offices differ from each other, because one establishment uses a system to document in, and the other does everything on paper.
Nevertheless, the managers know the status of their project, and which developer is responsible for what. Due to the division of the department per location. It makes it able to provide a clear overview, and give this company a great advance to cooperate together with the other locations and manage the communication between them. It can be compared to working in a business only more geographically divided. Where departments were used to be spread within one building, they are now spread over the globe.
8.6 Conclusion Requirements engineering and release planning are processes that are in six of the nine cases we have studied not outsourced. A reason for not outsourcing the requirements engineering and release planning process, is because these processes are executed on a high level, where outsourcing is only done on development level.
Even though, involving development into the requirements engineering process may lead to advantages as creating more understanding and better participation. This may lead to creating products where requirements are more connected to eachother, and to an efficient way of working. But in order to achieve this, a company needs to invest a lot of time in training and educating their people, and a lot of time is invested in communication.
Communication is the key within distributing software development. Developers need to know what is expected from them, and the managers need to let developers know what they expect when. In a distibuted environment more communication is required compared to a company in a not distributed environment. This requires a stabile organizational structure, where there are single points of contacts for the product manager to contact from the outsourcing location.
8.7 References
1. Weerd, I. van de, Brinkkemper, S., Nieuwenhuis, R., Versendaal, J., Bijlsma, L. “On the Creation of a Reference Framework for Software Product Management: Validation and Tool Support”, Proceedings of IWSPM’06. Minneapolis/St.Paul, USA, 2006, pp. 3-12.
2. Regnell, B. and Brinkkemper, S., “Market Driven Requirements Engineering for Software Products”, Engineering and Managing Software Requirements, A. Aurum and C. Wohlin (eds.), Berlin, Germany, Springer Verlag, 2005, pp. 287-308.
3. Carlshamre, P., Regnell, B. (2000). “Requirements Lifecycle Management and Release Planning in Market-Driven Requirements Engineering Processes”, International Workshop on the Requirements Engineering Process: Innovative Techniques, Models and Tools to support the RE Process (REP’00), 11th IEEE conference on Database and Expert Systems Applications (DEXA’00), September 6-8, Greenwich UK, pp. 961-965.
4. Greer, D., Ruhe, G. (2004). “Software release planning: an evolutionary and iterative approach”, Information & Software Technology 46(4), pp. 243-253.
5. Regnell, B., Höst, M., Natt och Dag, J., Beremark, P., Hjelm, T. (2001). “An Industrial Case Study on Distributed Prioritization in Market-Driven Requirements Engineering for Packaged Software”, Requirements Engineering, 6(1), pp. 51-62, Springer.
6. Deifel, B. “A Process Model for Requirements Engineering of CCOTS*”. In: Proceedings of workshop of the requirements engineering process (REP’99). Co-located with DEXA’99 Florence Italy. IEEE Computer Society Press, Los Alamitos, CA, September 1999.
7. Carlshamre, P. (2001) A Usability Perspective on requirements engineering: from Methodology to Product Development. (Dissertation, Institute of Technology, 2001).
8. Herrmann, K. “Visualization of Release Planning”. In: Proceedings of 1st international Workshop
on Requirements Engineering Visualization (REV’06), IEEE Requirements Engineering, Minneapolis/St.Paul, USA, 2006.
9. Vliet, H. van, Brinkkemper, S. “Requirements Engineering” (not published?) 10. Ruhe, G. (2005) “Software Release Planning”. In: Handbook of Software Engineering and
Knowledge Engineering, (3) 11. McDaid, K., Greer, D., Keenan, F., Prior, P., Taylor, P., Coleman, G. (2006). “Managing
Uncertainty in Agile Release Planning”. In: Proceedings of 18th International Conference on Software Engineering and Knowledge Engineering (SEKE’06), pp. 138-143.
12. Logue, K., McDaid, K. (2008) “Agile Release Planning: Dealing with Uncertainty in Development 13. Time and Business Value”. In: Proceedings of 15th Annual IEEE Conference and Workshop on the
Engineering of Computer Based Systems, pp. 437-442. 14. Kostoff, R., Schaller, R. (2001) “Science and Technology Roadmaps.” IEEE Transactions on
Engineering Management, 48(2), pp. 132-143.
15. Carlshamre, P. (2002) “Release planning in Market-Driven Software Product Development: Provoking an Understanding” Requirements Engineering, 7(3), pp. 139-155.
16. Vliet, H. van, Software Engineering – Principles and Practice. John Wiley &Sons, 2000. 17. IEEE standard Glossary of Software Engineering Terminology. IEEE Std. 610.12, 1990.
9 Distributed Software Development By Willem Spruijt
There can be a lot of good reasons to offshore your company’s software development. For example, it is likely that labor-costs will decrease significantly and the speed of your development process will go up with the availability of human resources in nearshored areas that offer software development services. But how do you deal with the worries that come with 'going nearshored'? How do you make sure that your development process still run as smoothly as it did before half of your team was a few hundreds of miles away? In other words: how can you collaborate with your nearshored site in such a way that your developed product quality remains high or even increases?
This chapter tries to answer the above mentioned questions. Although the topic of distributed software development is very broad and can be seen from many different abstraction levels and dimensions, this chapter incrementally walks through the important aspects that come with this topic. It will give scientific insights and theories, but also practical ways of actually executing the steps and tooling that will support these insights and theories. The information presented in this chapter was obtained by empirical fieldwork, gained during a research project in Eastern-Europe. In the first part of this chapter, the focus will be on the process of nearshored software development. It deals with communication, which answers questions such as:
• How do your programmers communicate?
• What documentation is used between the sides?
• Are there standardized methods to structure this communication?
• What (agile?) software development method are you using?
• And what about version/release management?
• Who reviews the code to enforce quality?
The second part concerns the explicit and tangible part, which handles questions such as:
• Where is your code stored?
• What kind of coding standards are used?
• And which tools do you have in place to support the process?
A case study is also presented about Servoy, a company based in the Netherlands that develops tooling for java-developers. The company experienced fast growth in the last years which forced them to look for non-Dutch resources. The case study gives in-depth information on the software engineering process within this specific company. The chapter ends with a number of concluding lessons that are important for successful collaborative software engineering.
Figure 6: Example of a development flow within an organization
Smith, Mitra, and Narasimhan present the cause of outsourced software development in their paper on … (citatie?): 'Falling hardware prices worldwide, the availability of telecomunications (and of course the internet nowadays), and the existence of many well-trained, low-paid analysts and programmers, now enable the developing world to compete for software development work.'. In the last decade, the scarcity of well-trained software engineers and the improvement of the network infrastructure in nearshored countries even strengthened these factors. The questions here is how to get all the right processes in the right place. This subchapter handles several aspects of the process of software
engineering.
As a starting point, the importance of dividing your activities and slicing your software development process is the base of outsourcing. Depending on what software development method is used (e.g. Waterfall/RUP/SCRUM/etc.) and the type of product that is being developed, the choice whether an activity is done in one phase or another can differ. In this chapter, the following development phases are defined to constrest diferent outsourcing models:
1. Requirements specification
Gathering the requirements and structuring them for product software is typically an activity that is done on-site. This has many reasons, but the main reason is the fact that the onsite company is responsible for the elements that should be in the software.
Usually done: onsite
2. Design
After the definition of the requirements, the design of the software is made. Usually, a software product design consists of two parts: functional design and technical design. In a functional design, the gathered requirements are structured in such a way that it results in a clear definition of functions (what should the software do?). A technical design focuses on the question how the functions described in the functional design are implemented. This can include the technologies/programming languages that are used but also the architecture of the software itself. Depending on the software product, the abstraction of the specifications can differ.
Compared to the other software development phases, this phase leaves more freedom to decide whether the design is done on-site of nearshored. An advantage of nearshoring the design part of your software is that the onsite development party has a stronger feeling with the actual construction. When dealing with more innovative projects where the
requirements are not fixed and still changing, outsourcing the design can lead to misunderstandings in the project. When the design is made offshore, the developed the design will speed up the development phase of the product. The other side of the coin is less transperency in the design of your product. If only a list of requirements is provided and the nearshored company fulfills the design and the construction phase, the risk of a bad design rises. Therefore, the choice to outsource your design phase is also closely related to the relation and the trust between the two parties.
In this phase it is very important that you realize who has the knowlegde of what data. If the design is made by de nearshored party, this should be very well documented when a company chooses to switch to another party to do their offshore activities. This is a very important issue, since it is almost impossible to make all data tangible.
Usually done: onsite and/or neashored
3. Construction
If one development phase qualifies for nearshoring, it is the construction of the product. The construction includes the complete transformation from a technical
design to a fully functioning (probably not yet tested) software product. As mentioned in the introduction, the shortage of qualified people for this job (programmers) and the fact that this phase takes the most time, in an on-site-nearshored situation is almost in every case done nearshored. Outsourcing your production phase can lead to significant time reduction, time that is important in the world of software development.
To generate more assurance and to reduce risk, some companies choose to use a hybrid situation. In this case, a part of the product development team works on-site and a part works nearshored. A logical result of this situation is the increase of communication between the two sites. Later in this chapter, more insight will be provided specific on the
construction phase and the use of software development methods to gain maximum value from your collaborative working environment.
Usually done: nearshored
5. Testing
Although it is covered in one phase in this structure, the testing of a software product can be subdivided in more specific phases. In the context of this chapter, the best division can be made into functional and technical testing. Technical testing includes the checking of software quality, seen from a technical point of view (is the architecture implemented well? Are there still bugs in the application?), while functional testing concerns the functioning of the product (does every function do what it should do and how it is described in the functional documentation?). When offshoring your testing activities, the most appropriate way is to let the construction-team do the technical testing. When choosing to do so, the nearshored construction team gets more reponsibility and the communication is reduced. When not doing so, the test-version of the software has to evaluated onsite, which results in a delay when the test are not successful.
Depending on where your functional design is made, the functional testing can be done on-site or nearshored. Becasuse the functionalities described in a functional document can be subject to a difference in interpretation, both sides need to do more effort to prevent misunderstandings.
Usually done: on-site & nearshored
6. Installation
The installation or deployment of a software product is typically done on-site. Especially for products that are not web-based or not distributed via the web, the installation of the product takes place at the clients of the organization on-site. When products need to be adjusted to a customer’s environment, many configuration management activities are required before deployment. Because the software’s deployment requires a lot of activities that are done at the clients site, it is very hard to offshore these activities. However, when a product is distributed (e.g. offline desktop applications) or online (e.g. web-applications) this activity can be offshored. In this case the nearshored company is able to perform the deployment at their site.
Usually done: on-site
7. Maintenance
Maintenance of a software product includes all activities that have to be done after a version is released. Maintenance consists of developing hot/bugfixes and patches. Because of the fact the nearshored company already has experience with the development of the product and the activities often include programming tasks, this phase can be nearshored easily.
Figure 7: development process at Inside
9.1 The importance of communication The (five/six) phases insinuate that if you offshore one or more activities of your software development process, it will go flawlessly and totally fluent. In practice however, the communication while executing this process is important. Even when all documents and milestones of the process are in place, it is very important that the on-site company constantly communicates (through documents, instant messaging, calling and online collaboration systems etc.) with the nearshored company to reduce the chance that communication errors arise. Especially the fact that, for example, the functional documentation is generated within another company then where it is developed is important to keep in mind. Therefore it is essential to a successful nearshored sofware development process that all the communication tools are in place. Our empirical research shows that instant messaging (supported by tools such as Skype, MSN and GTalk) is the most used tool for communication, before emailing and calling. The power of instant messaging is the combination of direct communication and non-verbal communication that solves more language problems and gives room for better explanation. One of the major advantages of nearshoring in contrast to farshoring is the small time-difference. Due to the maximum time difference of 3 hours, this isn't that much an obstacle for communication.
9.2 Distributed version and release management Versioning your software and its releases is one of the most important parts of the software engineering process. As software and system architectures get more complex and are part of an ongoing development process, a steady and well-planned planning is required. Often, a complex product with multiple versions has one or more codelines and consists of multiple versions that have separate lifecycles. Besides, the different products have to be deployed in different environment, which requires a high level of configuration management.
When applying the process of version and release management nearshored, in a nearshored environment there are a several challenges that occur. First of all, the planning needs to be very well structured to communicate this with the nearshored site. The 'who does what and when' needs to be in place to ensure that the process runs flawlessly.
To give an example: company A just released and deployed version 4.0 of their software and are moving on to the development of 4.1. The company decided to outsource the maintenance of version 4.0 to the nearshored company B. While company A is developing new features for 4.1, bug reports from customers come in. Because the maintenance of the 4.0 version is in the hands of company B, the responsibility for solving bugs is theirs. When bugs are solved and new builds (e.g. 4.0.0.1) are released, the same bugs have to be solved in both versions. One can understand the even in this simple example, the communication of process documents, code changes. etc. need to be demarcated to ensure that the responsibilities are in the right place.
9.3 Distributed Component Based Software Engineering (DBSE) One of the challenges in (outsourced) collaborative software development is the decomposition of the software product. When decomposing software into components is done right, the ease of assigning activities to specific persons or teams can increase. When mapping this decomposition to outsourcing software development, this decomposition can be a starting point for dividing tasks to the nearshored site. The paper on Rapid Component Based Software Engineering, Repenning et al. confirms this statement: 'One downfall of traditional distributed software development approaches is that software projects are often insufficiently decomposed. This results in overlapping or misunderstood responsibilities, which can lead to significant communication breakdowns and complete project failure. The nature of components forces designers and developers to better encapsulate functionality into cohesive, reasonably well-documented chunks of software.’
9.4 Deliverable management Deliverables are the products or services that are produced by a project and tasks. Eventually, all projects have the creation of tangible or intangible deliverables and/or services as a goal. When developing a software product, deliverables can be technical documentation, requirements documentation, program-code or compiled binaries. Depending on the software development method that is used, these deliverables are the result of a phase or a cycle, and are planned as soon as the planning for the software is made.
When a software development process is (partly) done in a nearshored setting, the existence of a plan including all deliverables can improve the structure in communication. When the company on-site communicates the plan to the offshored company, more insight is given into the planning and which product will be finished when.
9.5 Product documentation When talking about product documentation, we can divide this into three
parts. The first is the the technical documentation, which describes the
parts of the software and how they are implemented. It describes which
technologies are used and which patterns are applied. The second is the
functional documentation, which describes which functions are covered in
the application. And finally the end-user documentation (or user help)
describes how to user the is able to use your software.
When viewing this from offshoring perspective, it is most likely that our
technical documentation will be made by the nearshored party. However, this
depends on how the structure of the collaboration is set up. This holds
especially with the functional documentation.
9.6 Software engineering methods The choice for a software engineering method is a determining aspect of structuring the process of software development. The standard process described above is one of the many ways that is used to develop software. Basically, there are two types of software development methods. The first is the traditional waterfall method, in which each of the phases are done chronologically and the start of a new phase only starts with the end of an old phase and no iterations take place. The second type of methods, called agile development methods, are a result of failing projects that used the waterfall method. Because of a lack of involvement of customers during product development, the complaint was often that the final result differed a lot from the clients expectations. Agile modeling tries to prevent this situation by making short iterations and shortening the distance to the clients.
9.6.1 Waterfall
As shown in the picture below, waterfall methods consist of number of predefined phases, and each of the phases is only started when another phase is finished. The waterfall method gained a lot of popularity during the time that software engineering matured in the last decades. Especially with the development of complex systems, this method is still used a lot. However, the disadvantage is the long time-to-market (a software product is deployed only when all the phases are finished) and the so-called 'moving targets'. In many cases, clients change the requirements during the development of the product. This can lead to major issues when the waterfall method is used and, for example, the requirements are already finished.
9.6.2 Agile Development Methods
To reduce time-to-market for a software product and to solve the issues that arise with changing requirements, the agile development methods such as XP and Scrum are used increasingly. Instead of a number of development phases that are executed chronologically, the phases in an agile process are iterative and contain fewer activities. With the use of prototyping (giving feedback to the customer with a runnable demo), the chance of misperception of requirements and changing requirements is smaller. During the research, we noticed that the usage of Scrum increased remakably. As shown in the diagram below, Scrum consists of sprints (iterations) of which the length is determined by the executing company (30 days in the diagram below). The product backlog and the sprint backlog contain activities that have to be done in that product or sprint. But, as with most of the agile development methods, the real power lies in the working prototype that is delivered at the end of this sprint. At this point the customer can give feedback, and the requirements of the product can be adjusted on-the-fly.
Figure 8: Scrum lifecycle
9.7 Using a development method in a nearshored context The question is, however, how do you use these development methods when you develop nearshored? As we've seen in the introduction of the chapter, the software development process is sliced into different phases, which can be done on-site or at the nearshored location. When using a waterfall-based method, the ease of nearshoring these phases increases. Because each of the phases has its own scope and endpoint, less communication has to take place once the task description is sent to the offshored company. However, when using an agile development method, the feedback that is provided by the customer can cause a struggle. Because a lot of the software development is done nearshored, the on-site organization has to facilitate the communication between the customer and the nearshored company. Depending on which parts of the process are done nearshored, agile development methods require far more integration between teams and sites.
9.8 Coding management
9.8.1 Code standards
When talking about collaborative developing/ programming, the code standards determine the way of coding and structuring the design of the application. Small issues like the indentation when using accolades can highly influence the readability of the programming code. Besides this, the agreements upon the country-specific language that is used for in-code documentation and naming your classes/ functions/ variables/ etc. is very important. For examaple, what if a part of the code already developed in the German language and the offshored party needs to continue in English. This can lead to messy code which eventually generates more bugs
The empirical research shows that the maturity of tooling in this field is still very low. Allthough there are plugins available for existing IDE's like MS Visual Studio and Eclipse, this is only used in large teams. Instead of using plugins to control the code standards, another way is to review the code manually.
9.8.2 Code reviewing
A few years ago, the use of the eXtreme Programming method increased. One of the important aspect in this method is pair programming, in which two programmers work next to each other (as with one keyboard) on the same programming code. Although the costs for such a method are high, so are the advantages. Next to the fact that two know more than one, a collaboration between a senior and a junior programmer can quickly increase the knowlegde sharing within a company. Next to this method, phased code reviewing can also lead to major quality improvement of the software product.
When working with a team that is partly near shored, code reviewing can ben done at the nearshoring company. This happens a lot since the nearshoring company can control an evaluate the performance of the nearshoring situation.
9.9 Tooling Tooling is one of the essential factors to have in the right place for a successful software development process. Even if all the processes, methods and tasks are in place, the tooling should be there to support all of these. To give an overview of the tools that are needed to improve the (nearshored) development process, a classification is made. Each of the tools is described and its supportive function in the development process is provided.The list below is the result of the emperical research in which the different companies are asked about the tooling that is used.
9.9.1 Instant Messaging
The most-used tool for direct communication (even more than calling) is instant messaging or 'chatting'. By sending short messages in order to communicate, both sides have more time to formulate their messages clearly, which prevents problems that occur with language issues. Besides that, peers are able to communicate with multiple people simultaneously or in the same chat session.
But there comes another big advantage with the use of instant messaging. As developers discuss a lot of problems that are related to programming code, instant messaging can help in sending code from one peer to another to give more insight in the problem that is
discussed. Most used: Skype, MSN Messenger, GTalk
9.10 Calling One of the reasons that calling is used not so much as instant messaging, is the fact that the threshold to actually pick up the phone and call the other peer for a short question, is (especially for developers), too high. On the other side, when topics that are more important need to be discussed, calling can improve the process because the ability to estimate the other person’s thoughts increases. But calling not always takes place between two persons. Often conference calls are used to involve the full development team in the process.
Seen from a cost perspective, 'Skyping' (calling using the Voice Over IP-tool Skype) is far more attractive then traditional calling. Especially on the long-term, traditional calling costs can rise when a lot of communication takes place between the different sites. Most used: Skype, Traditional
9.10.1 Emailing
Since the birth of the internet one decade ago, emailing determined the new way of communication between people. As expected, emailing is used a lot, but mainly for discussions issues that not have to be solved directly. Besides this, email is still the way to send documents or files.
In some rare cases, where no code repository (see below) is used, programming code is send through email and synced at the receivers site. Of course, this leads to several concurrency issues by the extend of the complexity of the software projec risest.
Most used: MS Exchange, MS Outlook, Gmail
9.10.2 Remote Desktop Applications
If problems are becoming really complex, but especially when people need to be trained, remote desktop tools can provide a solution. When using remote desktop, one person can, with permission, take over another person’s computer and further elaborate on a topic, while demonstrating it to the person who’s computer has been taken over. Sometimes, the environment or configuration of the peer’s situation is so specific that it is faster to use remote desktop to solve a problem than to make a complete copy of the environment. Most used: Windows Remote Desktop, Skype + Remote Desktop Plug-in
9.10.3 Project management systems
Project management systems are used to keep track of the releases and project tasks. Depending on the software development methods that are used, different tasks are created in the system that are assigned to persons by a project manager. When a project management system is implemented right, more insight can be given in when which task should be done and, for example, if a release is delayed.
When applying such a tool in a nearshored environment, the structured base of tasks is even more important. When working with an integrated team on different locations, the existence of clarity in 'who does what' should be totally clear, in order to compensate the decline of communication between the sites.
Most used: Jira, eGroupWare, Home-build
9.10.4 Integrated Developing Environments
To support programming, often IDE's (Integrated Development Environments) are used. IDE's support the programmer by structuring the software architecture and solve language-specific problems at an early stage. Therefore, IDE's improve the speed and efficiency of the software development process.
IDEs come with a lot functionality that supports the overall development process. For example, when a test framework is used to improve the quality of the code, IDE's are capable of executing these tests and deliver test reports. Besides this, plugins in the IDE's can be used the check the standardisation of the code to meet the products code quality standards or can be used to generate documentation out of the code (JavaDoc for example).
Most used: Eclipse, MS Visual Studio, NetBeans
9.10.5 Code Respositories/ Version Control Systems
Version control systems can be used to store programming code and its revisions. Developers that have access to this system have the ability to checkout code and to commit it. To prevent concurrency of the code, most version control systems are able to merge code and create the possibility to revert back to an older revision.
Most used: SubVersion (SVN), CVS, MS SourceSafe
9.11 Case study Servoy is a privately-held company established to develop, sell and support the Servoy suite of products. Servoy markets an application development and deployment environment used to create and deploy user interface applications. The idea for Servoy started in 1998 by the four co-founders of the company -- being frustrated with the limitations of desktop database tools on one hand; and the complexity of web-based development tools, the steep learning curve, and the long development time on the other. The co-founders decided to build an enterprise-ready development and deployment environment -- based on industry standards -- that would enable developers to build solutions even faster than with desktop database tools. By 2002, the first beta version was ready; and by April 2003, the first commercial bundle of Servoy was shipped. Servoy Developer and Servoy Smart Client are compatible with virtually all computer platforms; and can connect to multiple and/or different SQL databases at the same time. In addition to the rich Servoy Smart Client that first shipped in 2003, a new Servoy Headless Client has been introduced to facilitate browser-based applications.
Today over 1500 companies and more than 10,000 developers are working with the Servoy product suite. Companies like Symantec, Stanford University, Verizon and UCLA hospital rely on Servoy for managing and presenting data to their customers and employees through rich applications over the LAN, WAN and Internet connections.
The Servoy worldwide headquarters is located in The Netherlands (Amersfoort) where all research and development, as well as international sales and marketing activities are centralized and coordinated.
Servoy can count Apple, Oracle and Sybase among its technology partners. All Servoy Developer and Client licenses also include a user license for Sybase iAnywhere's RDBMS system. iAnywhere is a scalable, industrial-strength relational database that also includes the ability for mobile deployment as well as multi-device synchronization.
9.12 Literature Using Components for Rapid Distributed Software Development by Alexander Repenning, Andri Ioannidou, and Michele Payton, Wenming Ye and Jeremy Roschelle
Supporting Distributed Extreme Programming by Frank Maurer
Tools for Geographically Distributed Software Development by Ryan Bagueros
Offshore outsourcing of software development and maintenance: A framework for issues by Michael Alan Smith*, Sabyasachi Mitra, Sridhar Narasimhan
Global Software Development by James D. Herbsleb and Deependra Moitra
An Empirical Study of Speed and Communication in Globally Distributed Software Development by James D. Herbsleb and Audris Mockus
10 Software Quality Assurance in a Distributed Development Environment
By Christina Mantelli
“You can’t manage what you can’t measure”. With this old management adage, this chapter introduces the topic of Software Quality Assurance (SQA) Management. A link to offshoring strategies is provided with the ultimate purpose to identify current and potential SQA trends in the distributed software development field. As Aman & Nicholson (2003) state, the field of software development in the domain of offshore outsourcing is relatively new and procedures for quality control and project management, though developing incrementally, still need to be improved and fully evolved.
In the theoretical framework for global IS development, as described by DeLone et. al. (2005), quality is recognized as an essential outcome variable of the “input-process-outcome” research framework.
Table 5 - Research Framework for Distributed IS Project Success (DeLone et al., 2005)
Situational Variables [INPUT]
Process Variables [PROCESS] Outcome Variables [OUTPUT]
Geographic distance Coordination/Communication Software Quality
Organizational Boundaries
Common Standards
Functional Differences Quality Control
The most important situational variable (input) identified, is the geographic distance that creates the need for implementing quality control projects. Organizational boundaries and functional differences that may exist among the remote offices encourage the need for adopting common quality standards and procedures. In addition to this, DeLone et. al. (2005) recognize some of the process variables influencing software quality. Better coordination and communication patterns can be achieved through the implementation of common software processes and quality standards to improve coordination and eliminate communication gaps. Finally, there is a need for applying different IT tools to enable software quality activities and control processes that help teams to achieve better software product quality.
While efficient use of global resources can bring greater flexibility to software R&D processes and IT and business service delivery, the overarching driver for most has been cost, i.e., access to skills at a lower price. Consequently, the use of offshore or nearshore resources has become – for technology product companies, IT service providers, and end users of IT-based solutions – an integral part of their quest to remain competitive. Companies seek for the most suitable conditions in order to support their internal or external clients at a low cost without compromising service and product quality. It is therefore, recognized the necessity of focusing on certain aspects on Software Quality Assurance (SQA) management which leads this study to the following research question:
“How do software companies, involved in offshoring outsourcing deal with aspects and issues related to software quality assurance management?”
The outcome of a productively implemented SQA management and the derivation of proper and well assessed results clearly indicate business effectiveness (Kasse, 2004). In a distributed software development environment though, implementing and maintaining a SQA management strategy is not an easy task. Many barriers exist compared to co-located software development projects, influencing to a great extend the various quality processes. Geographic distance, cultural differences, dispersed projects and disseminated development teams, must all be well coordinated and synchronized to produce at best quality.
The first part of this chapter is devoted to the analysis and definition of software quality, and the significance of an appropriate and considerable planning of the software quality assurance strategy. In the following sections, the relation of the Software Development Life cycle is introduced with the various quality assurance activities deployed in each distinct phase of the cycle. The influential magnitude of process standardization follows as an essential indicator of the successfulness of an offshored project and the role that external certifications and assessments play, such as the ISO and the CMMI. Finally the case study is focused on the practical representation of an implemented SQA strategy and the way a specific company deals with quality aspects and issues in the nearshoring environment.
10.1 Defining Quality Throughout literature, there seems to be a great variety of definitions, which all in total attempt to give a descriptive characterization of the quality term, resulting though in a variety of concepts. The vagueness on the software quality definition is justified based into two distinct reasons (Kan, 2002). The first reason relies on the entity of interest (the client company and/or the end user of the product) along with its viewpoint and divergent, perceived quality attributes (translated into user requirements). The second reason refers to the different levels of abstraction the term of software quality maybe encountered to. People for example may refer to quality from a more managerial and therefore a more generic and broader level whereas others directly link quality term to specific measurements and testing results. Taking into consideration this ambiguity and in an effort to provide a complete and as accurate as possible definition, this chapter focuses into two major aspects of software quality.
In a broader perception quality means “meeting requirements” and adherence to the predefined quality standards and processes (Tian, 2005). This process quality approach dictates that software product requirements must be measurable in order to identify whether the end product meets the preset standards based on the appropriate quality metrics (Kan, 2002). Apart from supporting business strategy, quality metrics can also capture performance in terms of how something is being done, relative to a standard, through a continuous process of measurement and comparison. An example of a process quality metric is the measurement of the defects density during testing. High defect rates are an indicator that the software is experiencing a high error occurrence during its development. The appropriate comparison with the previous releases’ results can help the development team or the product manager to act accordingly and create the necessary scenarios to assure quality.
Lewis (2000) gives software quality a second definition, from the consumer’s point of view. In this case, software quality is defined as “meeting the user’s needs” and adherence to quality attributes as described in the customer’s requirements specifications. A product quality approach is therefore introduced, where Lewis (2000) distinguishes two basic elements; The first element concerns the right performance of the product functions based on the user’s specifications and needs (fit for use, usability) and the second refers to the reliability aspect, meaning that the functions are performed correctly over time and throughout the continual uses.
Figure 9 - Software Quality Approaches
These two different quality approaches although seem to deal with different aspects, in practice they are totally interchangeable. This means that the measures of product quality are integral to the determination of process quality (Kenett & Baker, 1999). More specifically, in order to achieve the desired levels of product software quality, the appropriate processes must be clearly defined, implemented and finally mapped to the desired outcome. Underlying these two approaches is a set of quality factors which, if present in the software, can assure both the process and end-product quality viewpoint as well (Cavano & McCall, 1978). These quality factors’ definitions along with the corresponding questions, one should consider in order to satisfy them, are presented in the table below.
Table 6 - Definition of Software Quality Factors (Cavano & McCall, 1978)
Software Quality Factors
Definition Question to consider
Correctness Extend to which a program satisfies its specifications and fulfills the users’ objectives
Does it do what I want?
Reliability Extend to which a program can be expected to perform its intended functions
Does it function accurately all the time?
Efficiency The amount of resources and code required by the program to perform a function
Will it run on my hardware as well as it can?
Integrity Extent to which access to software or data Is it secure?
by unauthorized persons can be controlled.
Usability Effort required to learn, operate, prepare input, and interpret output of a program
Can I run it?
Maintainability Effort required to locate and fix an error Can I fix it?
Testability Effort required to test a program to ensure it performs its intended function.
Can I test it?
Flexibility Effort required to modify an operational program
Can I change it?
Portability Effort required to transfer a program from system environment to another
Will I be able to use it in another machine?
Reusability Extent to which a program can be used in other applications
Will I be able to reuse some of the software?
Interoperability Effort required to couple one system with another
Will I be able to interface with another system?
There, logically, comes the need to manage, measure, control and continuously improve software quality in an effort for a company to be competitive and keep a strong market position. Based on the aforementioned, software quality assurance provides management with the appropriate visibility into the entire process of software development, assuring that quality standards and predefined procedures are followed and quality goals are successfully met.
10.2 Planning Software Quality Assurance As Meyer (2006) observes, the quality in offshore software development, remains the main issue. Although cost cutting is the initial driver in the introduction of an offshored project, quality factors seem to be the reason for establishment. Close to this idea, quality assurance seems to be the panacea in distributed software development, a continuous set of processes and activities essential throughout the entire Software Development Life Cycle (SDLC). Therefore the systematic design of an accurate Software Quality Assurance plan is an essential precondition for the smooth operation of the distributed software development process. In this context, there can be distinguished two major implications for the top-level management to consider before any actions are taken:
1. There must be a systematic and clearly defined quality assurance plan, before the execution of any QA activities.
2. Measurement, analysis and feedback must be considered in order to monitor and control the QA activities.
The significance of a well documented plan is even more essential in the offshoring field, where distributed teams must be clearly communicated the specific activities to be
performed and the predefined processes to be followed in every phase of the SDLC. More particularly, the documentation of a SQA plan should outline the quality measures to ensure that the desired quality levels are met within a software development process (Lewis, 2000). As Dana Havlenova, quality manager at Brno in Acision says “Quality is not what I do; quality is what they want me to do. Top management must know exactly what they want to be done, and describe it in the process”. In order to achieve that, top management must always take into consideration the diversity of the processes and reflect throughout the SQA plan the specific quality metrics to be measured and compared as well as the relative quality assurance activities for each and every phase of the SDLC.
Quality assurance therefore, should not be restricted to the technical aspects only, meaning that the term itself does not refer only to the end product and its functionality and related features. Instead, quality assurance is a twofold facet including both technical aspect (auditing, inspections, testing) and a functional aspect (project management and plan creation, conformance of processes to standardized guidelines) (Carmel & Tjia, 2005). Relatively to the two-side definition of software quality, SQA is also characterized based on the process and the product aspects (Figure 1).
Figure 10 - The twofold spectrum of SQA (developed by Software Quality Consulting, Inc.)
As depicted in the above picture, there is a wide variation as of what is the discipline of SQA. Organizations with limited SQA’s roles are primarily limited to software testing and in most cases they are small companies and relatively low discipline. Measuring SQA effectiveness becomes therefore difficult since they lack of an internal description of software quality and the mission of SQA is not clearly defined. Consequently, quality assurance is not only about what is quality, but also to answer the question on how to achieve quality.
10.3 Quality Assurance and the Software Development Life Cycle (SDLC) There has also been much debate about when to perform SQA, how much to apply and how to measure its effectiveness (Voas, 2003).As already mentioned before, software quality assurance should be observed from the entire software development life cycle. Under the quality assurance umbrella, two major QA components are distinguished each of which embraces various quality assurance activities.
Table 7 - QA activities throughout the SDLC
Beginning the analysis, the two major components of Quality Assurance, Validation and Verification (V&V), should be further elaborated. Validation involves the control and assurance that the predefined and expected user requirements are present in the software product or in other words that the system meet the specified requirements. Verification checks the conformance of the software product implementation against its specifications, to control whether it is implemented correctly. More specifically, verification involves organizing and eventually confirming that the designed product meets the predefined specifications and requirements after the successfully execution of various activities throughout the different phases of the SDLC (Lewis, 2000).
In addition to this, three distinct categories of SQA activities can be identified, as indicated in Table 3. Starting with the set of prevention activities, the aim of a proper SQA management is underlined in the context of preventing quality deficiencies in advance and rendering the quality processes assessable by the relative measures (Lewis, 2000). Prevention activities, therefore, are mostly observed to occur during the early phases of the SDLC. Some examples include:
• Construction of formal product specifications, including the expected behaviour and other properties of the software artefact
• Perform formal verification activities including formal analysis techniques to verify the correctness of the product components in respect to the their formal specifications (Tia, 2005)
• Prescription of quality standards (further analyzed in the upcoming sections) • Documentation of coding conventions and standards • Change management activities including traceability, plan and implementation of
changes of the product releases
SQA COMPONE
NTS
SQA
ACTIVITIES
SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)
PLANNING
ANALYSIS DESIGN DEVELOPMENT
TESTING RELEASE & SUPPORT
(MAINTENANCE)
Verification &
Validation
Prevention Activities
x x x
Validation Reduction Activities
x x
Verification Control Activities
x x
Reduction activities are classified as inspection activities, including the most significant part of the SQA and the most commonly performed SQA activity; software testing. Software testing is used for the validation of the functional requirements of a software product, involving execution of the software and the observation of the program behaviour or outcome. Individual testing activities are classified using various criteria and examined accordingly (see chapter of Testing Management).
The SQA management role does not end with the product release. After product implementation and release, quality aspects still exist where failures observed and problems reported by customers need to be managed and controlled (Tia, 2005). Control activities therefore, aim at minimizing these remaining deficiencies usually through additional testing techniques and software maintenance procedures (see chapter of Software Maintenance), implemented basically during the later stages of the SDLC.
What is needed to be highlighted in this part is that the selection and the organization of particular SQA activities to be applied, depends on the requirements and nature of the project and the selection of the appropriate QA techniques revolve around the development methodology being used. Huo et al. (2004) identify two major categories of software Quality Assurance techniques, namely static and dynamic. Static techniques are mostly concerned with the examination of the documentation supported by different software tools as for example inspection tools and technical reviews. Dynamic techniques, on the other hand, such as testing and simulation, mainly involve code execution methods but both static and dynamic techniques can be used interchangeably, each supporting the other. Combining these two categories, Huo et al. (2004) provide a visualized representation of the differences between waterfall and agile software development and the relative types of Quality Assurance each one of them engages throughout the Software Development Life Cycle (Figure 3).
Figure 11 - Waterfall vs Agile SQA Techniques (Huo et al., 2004)
Based on the above representation, it is noticeable that in the waterfall development, dynamic QA techniques are applied later in the development life cycle, whereas in the agile development, both static and dynamic techniques are employed from the very early stages. Some of the most important remarks, they have been identified in the paper of Huo et al., between waterfall and agile development, based on the relevant QA techniques that embrace are summarized as:
1. Many QA activities in the agile software development occur in earlier phases that they do in waterfall development.
2. These activities are included in multiple iterations through the agile development and therefore they have a greater frequency compared to the waterfall development model.
3. In the agile software development, dynamic QA techniques are more frequently used than in the waterfall model.
A central thought for management to consider when offshoring software development is the classification of the activities to stay on-site and those that they need to be done offshore. Based on the research performed among the participated offshoring companies in Eastern and Central Europe, highly standardised activities, with low customer involvement, are number one candidates for offshoring. As indicated in the above table, in the earlier phases of software development, such as project planning, requirement analysis and architectural design, quality assurance activities usually involve inspection and reviewing (process quality assurance) rather than testing and configuration (project quality assurance). Therefore, high level processes including the corresponding QA activities are more likely to be performed locally whereas, more technical processes on the later phases accompanied by software testing, version control and other relevant QA activities, are rather to be offshored.
Whether a company decides to offshore certain activities and processes, and under which conditions, is essentially related with the nature and the profile of each company. In more details, companies that collaborate with independent offshoring software development vendors, they usually outsource solely the code development activities and occasionally several maintenance responsibilities as well. In this case the independent vendor applies its internal, local quality assurance processes appropriately combined and tailored to their customers’ needs and expectations. InsideSoftware, a Romanian offshore collaborator with Databalk (a dutch company focusing on ICT management for housing corporations and health services e.g. Websites, Applications, Databases, IT infrastructure, Security and overall IT availability), explains that sometimes they even need to turn to external quality consultancy in order to define internal quality levels and adjust themselves to their clients’ needs.
On the other side of the offshoring coin, large companies such as Acision and Levi9 have developed their own subsidiary, software centre, a captive centre as it is defined (Carmel & Tjia, 2005). Under these circumstances, it is observed that a tight collaboration exist between the remote offices throughout the entire SDLC. Companies’ effort is concentrated in developing common quality assurance processes, in a company-wide range, in order to consistently manage, control and coordinate activities between remote
offices. In terms of performance and quality measurements, mutual metrics and evaluations result in increased visibility for the top management and as already mentioned before with an increase in the effectiveness of the overall coordination of a distributed software development project. Later on this chapter, the importance of the development of a common and mutually acceptable SQA plan and management of the process will be presented, introducing the term of standardization and the role of the external certifications and assessments such the ISO and the CMMI for Software.
10.3.1 Documentation
Documenting processes and activities is a cornerstone of the software quality assurance management. Guidelines, status reports, test reports, review reports as well as the SQA plan itself constitute an essential mean to facilitate and coordinate the communication between the remote offices. Documentation of critical deliverables and processes helped ensure the evolving needs of quality were adequately addressed by the flexible process. Based therefore on the different needs, various types of documents exist, some are product and process specific and others are common to all processes. Based on ISO 9001, organizations are required to define the needs for the effective operation and control of its processes which are categorized and registered in the controlled documents (Hoyle, 2001) divided into three main categories.
Figure 12 - Relationship between documents (Hoyle, 2001)
1. Policies and Practices: include process descriptions, control procedures, operating procedures and internal standards.
2. Derived Documents: are the documents derived from the policies and practices such as plans, specifications, work instructions, technical procedures and reports.
3. External Reference Documents: are referenced in either of the above types of documents and include documents such as national/international standards and supplier, industry and customer data.
In practice though, there seems to exist contradictory opinions about whether documenting everything in details leads to actual efficiency. Based on the participated in
the research companies all of them consider documentation as a mandatory and indispensable part of their quality assurance processes. Analogous once more on the size of the company, is the level of abstraction of the documentation produced with smaller companies focusing more on the most important parts of their processes that they consider as essential to be documented while larger companies strive to “put on paper” as many details as possible.
An imperative remark here is that throughout the study it was noticed that people although put a great value on the documentation in order to assure quality, they partially doubt on their practical everyday usefulness. As Viktor Kovac, Line manager in Serbia at Levi9 says, “It might be true that people actually don’t use the documents. But still it helped us to structure some projects. Most of the people knew all the procedures by heart so they didn’t have to read the documents.” Dana Havlenova from Acision, also agrees on the overrated effort devoted in describing processes with every detail for every single product and people feel overloaded by the amount of information they have to read.
The effort put on creating and documenting common processes in a distributed software development environment, leads to another essential aspect of the offshoring field; the need for standardization of the processes in order to achieve a coherent and well coordinated workflow. Standardizing various processes of the SDLC gives the insight into the aspects such as how project reports are written, and the criterion to judge the quality of a developer's work. These standardized systems, often codified in manuals and databases, serve as points of reference to coordinate work across time and distance. Such attempts to standardize thought can often become problematic, and especially under the tension with the need for flexibility in a distributed environment. While some degree of standardization is essential to enable offshoring coordination, there is always the question of how much and what to standardize? (Sahay, 2003)
10.4 Software Quality Standards Geographic dispersion and cultural differences are considered as two of the most important issues companies have to deal with, in software development offshoring (Carmel, 2003). As a consequence, one of the major implications caused by distance is the relevant control and coordination of the involved software processes, where control is identified as “the process of adhering to goals, policies, standards, or quality levels” (Carmel & Agarwal, 2001). Coordination is not only enabled by networked technological infrastructure, but also together with the use of standard product designs, common development methodologies, and benchmarked management processes that serve as ‘best practices’ (Sahay, 2003).
While it may be relatively simple to standardize technical quality control methods, it is harder to get managers from different backgrounds to communicate with each other similarly. It is therefore apparent that in a distributed software development environment the need for defining and implementing common procedures and activities through the process of standardization becomes even more intense than in collocated projects. Throughout the research, it was observed that most of the participated offshoring companies are in the process or have already developed a company-wide system coordinating all the activities in the SDLC, bringing in closer and more synchronized relationship the remote offices. Acision company, through the implication of a Gate
Process System has reached that point and it is still in the process of evolving, improving and supporting that system even more.
One of the basic deductions derived from the research performed, conclude that whether the case relates to an offshoring partner company or a remote captive centre, the perception of the increased magnitude of standardization remains a common belief. As Napoca Software indicates about its company culture “The world we live in enforces high standards. We believe that excellence is the highest standard of all and we do everything in our power to achieve it.”
10.4.1 External Quality Standards and Models
In an effort to create standard processes and common procedures to increase the efficiency of controlling and managing business process and ultimately achieve higher quality levels, several software processes models where developed. This chapter will concentrate on the two most important and widely used; the ISO 9000 series and the Capability Maturity Model Integration CMMI.
ISO 9000 is a series of the International Standards for Quality Management Systems. They specify requirements and recommendations for the design and assessment of management systems. The purpose of these standards is to assist organizations to implement and operate effective quality management systems. They provide the mean for consolidating and communicating concepts in the field of quality management that have been approved by an international committee of representatives from national standard bodies.
The Capability Maturity Model Integration CMMI, was developed by the US Dept. of Defense Software Engineering Institute (SEI). CMMI was introduced in order to provide a model to be used by organizations for integrating systems and software development activities. It supports the coordination of multidiscipline activities that are required to build a successful project. CMMI involves five maturity levels where the last one (5th) is a theoretical ideal state where processes would be systematically managed by a combination of process optimization and continuous process improvement. Figure 4 provides an overview of the CMMI staged maturity levels.
Figure 13 - CMMI staged maturity levels
In the offshoring software development field, many software vendors are focusing on the certification and assessment of internationally recognized standards of quality, as a mean to create a better profile and attract potential contractors (Carmel, 2003). But once a common quality model is established, maintaining it is a challenging task requiring commitment from the organization and a proper work culture. These processes are fully documented, with key practices being measured, tested, and controlled to increase the productivity of software development. Such standardization helps to impart structure and predictability to the offshore software development processes.
Based on the research conducted for the purpose of this chapter, in the context of the importance for the offshoring companies to be ISO certified or CMMI assessed, opinions seem to be restrained. Most of the interviewers’ converge to the idea that neither ISO nor CMMI actually guarantees software quality. Although in several other offshoring destination countries, such as in India, offshoring software vendors put value on such standards (Carmel, 2003), in Easter and Central Europe the situation appear to be different. The quality certificates are rather seen as marketing to attract and satisfy customers than as a means to increase managerial control. Viktor Kovac, from Levi9, explains that “the idea is not to compete based on “processes” or CMMI level with India. The better way to compete with them is by playing out the “nearshore” and “people/culture” cards”. On the other hand, Acision company although still follows CMMI procedures, it does not consider it as a business priority any more. One of its current focuses on SQA management is to maintain and denote external certificates of ISO 9001:2000 which include a variety of activities to be organized and followed.
In an overall conclusion, offshoring companies in Eastern and Central Europe show a preference towards developing and implementing their own, specific quality assurance processes and procedures than following internal quality standards and models, relying at the same time more on personal trust than on the official image provided by these standards (Ramesh et. al., 2006). As Viktor Kovac put in plain words “The different CMMI levels provide an abstract umbrella under which you should tailor the other processes for the different projects. The higher you get in CMMI the more abstract the umbrella gets. You need to keep on tailoring.”
10.5 The practical implementation – Case Study The practical implementation of the above mentioned theories in relation to the importance of SQA management in the distributed software development environment will be examined through the analysis of a real life practice. This case study will be devoted to the internal practices and approaches as developed and implemented in Acision, the world’s leading messaging company. Acision provides communication solutions globally, for more than 300 communication operators and service providers, and the results are based on the research performed in the company’s offshored offices in Prague and Brno of Czech Republic. Furthermore, this research has been compiled from information furnished by the participated company with the understanding that any, or all, of the information presented here, strictly follow any confidential disclosures as imposed by Acision.
Beginning with the planning and development of the company’s offshore outsourcing strategy Acision determines its Quality Assurance Management strategy as a key requirement that needs to be fulfilled in order for the offshore outsourcing activities to be implemented successfully. The strategy as planned within the company simply identifies the “who does what” idea, and there exists a tight cooperation and coordination between the headquarters and the remote offices. The role of Quality Assurance manager within the company’s organizational structure is highly connected to the Testing Team, acting as an external, supporting entity (Figure 6).
Figure 14 – Acision’s Organizational Structure
Quality goals are developed through the balance scorecard at the top level management and communicated to the lower levels. By the time, this research was performed and due to the recent merger of Acision with Logica CMG, the new system of the balance scorecard including the quality goals had not yet been transferred to the remote offices. The offshore team therefore in Czech, as it was indicated, still works with the company’s objectives as they were formed from Logica CMG, cascaded to low level management. As an example of the company’s “business and quality objectives”, four areas of concentration are defined.
1. Internal –employee oriented 2. External – customer oriented 3. Innovation 4. Financial
Taking into consideration the aforementioned approaches of the software quality definition of the product and process quality, the following mapping can be indicated using Acision’s example in setting quality objectives.
Table 8 - Acision quality objectives
Product Quality Approach Process Quality Approach
Acision quality objectives Employee oriented
Customer oriented
Innovation
Financial
One of the major goals Acision strives to implement is the complete alignment of all processes through the entire software development life cycle and between the different remote offices. More specifically, Acision designs processes and guidelines in a companywide level, trying to eliminate a variety of different local processes which are considered quite costly and time consuming.
Quality processes, therefore, fall into the same category, as they are the same for the entire company, no matter where their offices are located, but there still exist some differences, the alignment of which is in progress. These differences are not related to the activities and the remote offices but mostly to the different products the company develops. One of the problems arising is the variety of guidelines within the company’s Configuration Management System (CMS). The great amount of detailed documentation precludes employees to easily read, understand and follow them, resulting in more time consuming and cost expensive processes.
One example of the documentation process Acision follows is the Test Quality Plan (TQP). TQP is a top-level document describing the activities and the Testing approach for the company’s Business Tools (BT) product. The basic issues described within the Test Quality Plan refer to the quality objectives to be met, the relevant documentation to be produced, the specific processes to be followed along the responsibilities to be taken and the needed resources throughout the entire SDLC. The significance of the TQP is highlighted within the scope description of the plan as “this document is the only steering document for the BT product”.
Some of the objectives as described within the TQP are:
• The project’s primary objective is to produce the product on time, within budget and close to the requirements, detecting as many defects as possible.
• The BT Team primary objective is to ensure a high quality product.
In the previous sections, a reference had been made, connecting the different quality assurance activities as implemented throughout the SDLC. Three basic categories have been analyzed, namely prevention, reduction and control activities. Using this framework, a situational mapping can be implemented in this case study using Acision’s quality processes as described in the TQP.
Table 9 - Acision's QA Activities
Planning Analysis Design Development Testing Release and Maintenance
Aci
sion
’s Q
ualit
y A
ctiv
ities
Prev
entio
n
planning and work delegation
requirements review
functional and high level
design review
configuration management
change management
Red
uctio
n
system testing
unit testing
quality control records
risk management
status reporting
metrics measurement
Con
trol
integration testing
acceptance testing
metrics measurement
maintenance testing
As it was previously indicated, Acision uses the Gate Process system, based on milestones and implemented throughout the entire SDLC. The quality milestones are an integral part of the test processes defined in the testing documentation and fully comply with the Gate Process system. The Gate Process supports different kinds of processes like new and old product development, product integration, service packs, maintenance and few others. For each type of project they have defined templates, work gates (or work deliverables) which are considered a compulsory part of the Gate Process system involving a defined set of deliverables (what needs to be done) and the relevant documentation, as well as the people involved in every project. As a quality manager in Prague and Brno, some of Dana’s responsibility tasks involve assuring that the deadlines are met, the gates are completed and reviewing the documentation.
At the beginning of this chapter, a reference to the significant magnitude of the quality metrics in relation to the company’s performance measurement has been made. Based on the Test Quality Plan of Acision, as mentioned before, that documents the basic guidelines for the BT Test Team, quality metrics and their measurement results are also taken into consideration (Table 6).
Table 10 - Quality metrics the BT Test Team for
Development
Project Phase Metrics
Number of Test Cases
Number of Test Cases per Test Area
Total number of TC (passed, failed, skipped, blocked)
Number of Test Rounds
Integration
Project Phase Metrics
Number of Test Cases per Test Area
Number of Test Cases
Total number of TC (passed, failed, skipped, blocked)
Number of Test Rounds
Maintenance
Project Phase Metrics
Number of Test Cases
Total number of TC (passed, failed, skipped, blocked)
Number of failed TC in regression testing
Total Number of tested Problem Reports
Number of Test Rounds
An additional quality assurance activity involves the identification of those projects that fail to comply with the Gate Process milestones and the reasons upon these failures. This activity results on the effort to eliminate problems arising when some of the projects do not properly proceed through the Gate Process, although there are some cases where procedures are dictating the actions to be followed, even if not all deliverables are completed. In combination to this effort of tightly monitoring the Gate Process compliance, there seems to be a highly effective collaboration between the remote offices of the Netherlands and the ones in Czech Republic. An intermediate person acts as the connection link between the product management in order to coordinate and ensure that the deliverables are properly completed and communicated to the offshore offices in Czech and ensure the smooth continuity of the activities.
Figure 15 - Use of intermediate to facilitate communication
An important contribution to the proper management and coordination of the SQA management in Acision is the participation of the QA managers in the management team meetings. This not only enforces the relationships between the remote QA teams but they also facilitate the communication of the quality goals and objectives, offering the opportunity of quality managers from the offshore offices to actively participate in the decision making and remain informed. Supplementary to this action, internal audits are now reinforced, where the quality manager in collaboration with the project and team manager attempt to identify best practices on different projects, eliminate potential gaps, and improve the process and product quality of the company.
The standardization of the business processes and as a consequence the alignment and unification of the quality assurance procedures within Acision is identified as the major, current business priority set. In accordance to this, external quality standards and assessments are taken into account, in an effort to enforce and improve internal processes but even in this case the value added from the external certifications seems to be debatable.
Acision is ISO certified where external audits take place twice a year in different projects and products. Although, the efficiency of these audits seems to be apparent in the improvement of the results the company receives every year, Dana adds to this; “ISO is too formal, mostly used for ‘show off’. Historically, it has a bad reputation because people think there is a lot of documentation and administration involved, but with the new version of ISO 2000 documentation is limited and the focus is concentrated on process improvement. But it always depends on the application to every company.”
Finally, Acision follows the CMMI assessment model, where it identifies itself in an overall company-range of level 2, aiming to improve during the next years and succeed to achieve a level 3. What is noticeable once again thought, is the low, current priority they give to the course of CMMI assessment, focusing more on the company’s internal, tailor made quality standards and procedures; “When it started (one year ago, )it was one of the biggest priorities but not anymore. Now there are other business priorities more important.”
10.6 Conclusion This chapter focuses on the contribution of the Software Quality Assurance management in relation to the offshore outsourcing field, through the combination of the literature theories of previous works and the results of a research performed in Central and Eastern Europe. Throughout this study, the research question was answered in respect to the following summarized key factors:
• The planning and implementation of a proper Quality Assurance strategy where it enables the systematic identification of the company’s specific quality goals.
• The importance of the SQA management and the relevant processes throughout the entire SDLC where specific quality assurance activities should be assigned and implemented in each and every stage in order to assure process and product quality.
• The need for standardization of the internal quality assurance processes and the role of the external quality standards and certifications which resulted in a contradictory theory applied in Central and Eastern Europe, compared to the other studies performed in other offshoring destinations.
Finally, the combination of the above key factors concluded in the elimination of the already identified by other studies, as major problems in the offshore activities, such as the geographic distances of the remote offices and the communication barriers of the distributed teams. With the conclusion of the importance of the Quality Assurance concept in the offshore outsourcing of the software development processes, companies need to assign value on this subject and consider the offshore activity as quality driven improvement rather than as a cost cutting investment.
“If you don’t know where you are, a map won’t help”
(Watts Humphrey)
10.7 References
Aman, A., Nicholson, B. (2003). The Process of Offshore Software Development. Proceedings of the Working Conference on Information Systems Perspectives and Challenges in the Context of Globalization, Athens, Greece, 201-216.
Carmel, E. (2003). The New Software Exporting Nations: Success Factors. The Electronic Journal of Information Systems in Developing Countries (EJISDC), 13(4), 1-12.
Carmel, E., & Tjia, P. (2005). Offshoring Information Technology: Sourcing and Outsourcing to a Global Workforce. Cambridge University Press.
DeLone, W., Espinosa, J. A., Lee, G., & Carmel, E. (2005). Bridging Global Boundaries for IS Project Success. Proceedings of the 38th Annual Hawaii International Conference on System Sciences (HICSS'05), 1, p. 48.2.
Hoyle, D. (2001). ISO 9000, Quality Systems Handbook. Oxford: Butterworth-Heinemann.
Huo, M., Verner, J., Zhu, L., Ali Babar, M. (2004). Software Quality and Agile Methods. Proceedings of the 28th Annual International Computer Software and Applications Conference (COMPSAC’04). 520-525.
Kan H. S. (2002). Metrics and Models in Software Quality Engineering. USA: Addison-Wesley.
Kasse, T. (2004). Practical Insight Into CMMI. USA, Boston: Artech House.
Kenett, R. & Baker, E. (1999). Software Process Quality: Management and Control. New York: Marcel Dekker Inc.
Lewis, W. E. (2000). Software Testing and Continuous Quality Improvement. Boston, MA, USA: Auerbach Pub.
Meyer, B. (2006). The Unspoken Revolution in Software Engineering. Computer, 39(1), 124-123.
Ramesh, B., Cao, L., Mohan, K., & Xu, P. (2006). Can distributed software development be agile? Commun. ACM, 49(10), 41-46.
Sahay, S. (2003). Global Software Alliance: The Challenge of Standardization. Scandinavian Journal of Information Systems, 15(1), 3-21.
Tian, J. (2005). Software quality engineering: Testing, quality assurance, and quantifiable improvement. Canada: Wiley-Interscience.
Voas, J. (2003). Assuring software quality assurance. Software, IEEE, 20(3), 48-49. Cavano, J. & McCall, J. (1978). A Framework for the measurement of Software Quality. Proceedings
of the software quality assurance workshop on Functional and performance issues. 133-139.
11 Distributed Software Testing in Practice By Nizar Abdat
Most people think that the purpose of testing software is to show that software works well. Working software does not always guarantee that it is free of errors or bugs. Therefore, testing should be done with the assumption that software must contain errors (Myers, 2004). Every single bug in the software production will bring additional costs in regards to customer support and patch developments. Even more importantly, fixing bugs squanders the time a company can spend on product development and limits the commercial success of their software in the market. To avoid those possible impacts to happen, a well-structured testing procedure must be done before launching the software into the market. The quality of testing procedures can be measured, for example, with the number of errors that are found in the software during the installation process or errors in the interfaces of the software. Finding and removing errors or bugs also means raising the quality and reliability of the program (Myers, 2004).
An important point is that software testing should be distinguished from the separate discipline of Software Quality Assurance (SQA, see chapter 7). SQA involves the entire software development process - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to 'prevention'. On the other hand, software testing encompasses operation of a system or application under controlled conditions and evaluating the outputs and it is oriented towards 'detection' (Hower, 2008).
Software testing has become a crucial process prior to the launching of software to the market. A study conducted by National Institute of Standards Technology (NIST) has also highlighted the economic impact of an inadequate infrastructure for software testing (Woodward & Hennell, 2005; NIST, 2002a; NIST, 2002b). The study reported that software bugs cost the U.S. economy $59.5 billion and more than a third of these costs could be avoided if better software testing was performed.
Nowadays many Dutch software companies have outsourced part of their business processes into other countries such as India, China, and Central-Eastern European countries. Mostly, these business processes include the Research, Development, Support and Maintenance processes. ‘Software Testing’ is seen as a sub process of the Development process must have a solid infrastructure as well. The following research question is the cornerstone of this chapter:
“How do the Dutch outsourcing companies organize their testing infrastructure successfully? And how do they perform the testing process in practice, both on-site and remotely?”
The mentioned question will be answered based on the research performed at nine different Dutch outsourcing companies, of which eight outsource to Central and Eastern European countries, and one outsources to Malaysia. Three companies have been selected as detailed case studies within this chapter. The research overviews the different testing procedures and techniques are used by the nine companies, also including their recruitment process of qualified testers. In section 2, more information about the software testing infrastructure of the outsourcing companies with several factors that impact the
infrastructure itself are explained. More practical situations of testing process in the outsourcing environment such as the feedback system and the division of testers are presented in section 3. Several types of common testing techniques used by the software companies can be found in section 4. And as the outcome of the research, more information related to the used techniques and tools by the nine companies are listed in section 5. Three case studies describing the testing procedures from three different Dutch outsourcing companies can be found in section 6. The chapter concludes in section 7 with a summary of the finding results.
11.1 SOFTWARE TESTING INFRASTRUCTURE Software testing is generally done after the development phase and before entering the production phase. The main goal of testing procedure is to ensure that the software being tested meets the agreed requirements between a company and its customers. In this chapter we discuss the outsourced companies and Dutch companies. The requirements describe what software must do and its operational constraints. Examples of the requirements include the functional, performance, interface, and quality requirements (Burnstein, 2003). Further information related to the requirements can be found in chapter 9.
The purpose of doing testing management is to detect the errors of software as many as possible and make the software ready before being launched to the market. As Mircea Negrila, the technical director of Netrom says “it is not working software if it has not been tested yet”. Testing management is the same at ground level for different companies and it applies to all companies, either for the one who outsource their projects or not. The mere dissimilarity is the applied software testing model. The software testing model is commonly referred to as testing phases or stages (Jones, 1997). The number of software testing stages employed varies greatly depends on the company size and the software complexity. According to the book of Jones (1997), the number of stages can range from as low as 1 to as high as 16 (Figure 1). For large and complex software, companies typically use a 12-stage process that can be aggregated into three categories: General testing stages include subroutine testing, unit testing, new function testing, regression testing, integration, and system testing; Specialized testing stages consist of stress or capacity testing, performance testing, platform testing and viral protection testing; User-involved testing stages incorporate usability testing and field testing. The software testing model also covers the standardized testing technologies and tools are used by the company (NIST, 2002b).
In general, the testing process is started when the tester has created a test case. A test case is a test-related item that contains the following information: (1) a set of test inputs. These are data items received from an external source. The external source can be hardware, software, or human. (2) Execution conditions. These are conditions required to run the test, for example a certain state of a database, or a configuration of a hardware device. (3) Expected outputs. These are the results to be produced by testing process (Burnstein, 2003). These results are measured using standard values or better known as ‘test metrics’. The test case must be verified and validated (Chernak, 2001) before proceeding with the test plan. The test plan contains the schedule of all testing activities for different testing techniques including the tools and technologies are used. It is mostly produced by the test manager or leader. Models such as TMap (Sogeti, 2008), Testing Maturity Model (TMM) and different V-models (Burnstein, 2003) can help companies to support their test planning activities.
Figure 1 - Software Testing Infrastructure (Jones, 1997)
The applied test plan also depends on the development methodology that is followed by the company. Projects with waterfall approach will have big differences compared to agile projects. Waterfall projects have strict entry and exit criteria for each phase and move from one to the next only when the previous phase has finished. Agile projects will starts a testing phase as soon as possible and allow them to overlap even though the development phase has not finished completely (Vingrys et al., 2008).
Besides the chosen methodology, the agreement or contract between a company and its customers also plays a role to determine the testing infrastructure. Some clients confer fully testing responsibility to the company to test the developed software. But, some of them want to be part of the tester team. In this situation, the infrastructure must fulfil the wish from both parties such as the job division with different testing techniques.
There is no best software testing infrastructure that suits all companies. There are always several factors which need to be taken into account. The ‘ideal situation’ of testing process would be to do the technical parts of testing in the outsourced countries and the functional parts in the outsource country, which is in this case is the Netherlands. It is still an assumption that since more and more departments of the companies are being outsourced (not only R&D departments), especially for those companies who do not have high complexity of their software, there is greater possibility that more ‘black box’ and system testing will be shifted to the outsourced companies.
11.2 MANAGING TESTING PROCESS IN PRACTICE Software testing management in the outsourcing environment often involve a few key aspects, such as the division of tester team, the location of run-time tests, and the feedback reporting process between the testing department, the development department and also with the clients when it is needed.
The number of tester team involved in a project depends on the complexity of software being tested. The more complex the software, the more testing techniques and number of testers are required. For example, Netrom needs less testers compared to Acision and Levi9 (see case studies for more details). It is also a common situation where many
software companies have less number of their testers compared to their developers. Related to the task division, the tester team can also be split up in the different locations. In the outsourcing country, the testers mostly test the functional parts of software. On the contrary, more technical testing is done in the outsourced country. In this situation, normally there are testing servers running in both countries. However, some software companies still believe the close location between testers and developers will generate better quality of software, especially due to the communication issue for the test feedback and report.
In order to establish a good communication, many software companies build their own portal or use external available bug-tracking tools in the market such as JIRA (www.jira.com) and Mantis (www.mantisbt.org). Through the performed research, it shows that the companies who use the portal as their bug reporting system involve only local testers. The example is Acision. In the opposite, companies like Netrom and Levi9 who use bug – tracking tools involve not only their local testers, but also their clients as part of the tester team. These portal and bug-tracking tools are also helpful for the release maintenance.
11.3 COMMON TESTING TECHNIQUES This section describes testing techniques which are used most frequently by software companies. There are two approaches to do testing; manual and automated. Many techniques can be done using both approaches depend on the complexity of the software. The former approach requires a tester to perform the operations of testing software without the help of any tools or applications. Thus, a creative and skillful tester is a ‘must’ to have. The latter approach makes use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and test reporting functions.
In certain situations, manual testing can be replaced by test automation. It is possible to record and playback manual steps and writes automated test scripts using the test automation tools. However, these tools lack the ability of decision-making and recording any unscripted discrepancies during program execution. Therefore, it is recommended to use both approaches to test the complex software in order to find the errors as many as possible.
Nowadays, there are many kinds of different techniques of software testing are available. None of them ensures bug-free software: each has its own strengths, limitations, and costs. Software testing is traditionally classified into black-box method and white box method (Farrel-Vinay, 2008). These two techniques are used to describe the point of view that a test engineer (tester) takes when designing test cases. Hence, the term ‘method’ is selected instead of ‘testing’ to distinguish them with the other testing techniques.
Black box method treats the software as a black box without any understanding of internal behaviour. It aims to test the functionality according to the requirements. Thus, the tester enters input data and only sees the output from the test object. This is what the tester will normally do for a system test.
White box method is where the testers have access to test the codes, design, or even the database of the software.
The size of a program must be taken into consideration. Large programs (say, programs of 500 statements or more) require a special testing treatment (Myers, 2004). In order to structure the testing of large programs, the following testing techniques can be done:
Unit (module) testing is a process of testing the individual unit (component) of the program rather than initially testing the program as a whole. The motivations for doing this are threefold. First, unit testing is a way of managing the combined elements of testing, since attention is focused initially on smaller units of the software. Second, it eases the task of debugging. When an error is found, it is known to exist in a particular module (Whittaker, 2000). Finally, unit testing introduces parallelism into the software testing process with the opportunity to test multiple modules simultaneously (Myers, 2004).
Integration testing tests multiple components that have each received prior and separate unit testing (Whittaker, 2000). It exposes the defects in the interfaces and interaction between integrated components. Progressively larger groups of tested software components corresponding to elements of the architectural design are integrated and tested until the software works as a system (Beizer, 1990).
System testing tests completely the integrated system to evaluate the system has compliance with its specified requirements. System testing falls within the scope of black box method, and as such, should require no knowledge of the inner design of the code or logic (Geraci, 1991).
System testing is the most difficult testing process (Myers, 2004). It requires a large amount of resources and evaluates both functional behaviour and quality requirements such as reliability, usability, performance and security. This phase of testing is especially useful for detecting external hardware and software interface defects or failures, for example, those causing race conditions, deadlocks, problems with interrupts and exception handling, and ineffective memory usage (Burnstein, 2003). Because this testing is a complicated task, special tools or even laboratory equipments and long test-times are needed. It is usually also performed by a team of testers. The best scenario is for the team to be part of an independent testing group. The team must do their best to find any weak areas in the software; hence, it is best that no developers are directly involved within the test team (Burnstein, 2003). There are several types of system testing which is mostly used by software companies as follows:
Functional testing - This testing technique at the system level is used to ensure that the behaviour of the system of software adheres to the functional requirements specification. This technique has a great deal of overlap with the acceptance tests. Very often the same test sets can apply to both. Both are demonstrations of the system’s functionality. Functional testing is black box in nature, which focuses on the inputs and proper outputs for each function (Burnstein, 2003).
Performance testing - A test technique in which the testers try to demonstrate that an application should meet certain criteria described on a test case, such as response time and throughput rates under certain workloads or configurations. The results of performance tests are quantifiable (Myers, 2004; Burnstein, 2003).
Stress testing - This system test is conducted to evaluate a system at or beyond its maximum ability in order to work properly, or in other words, to find the circumstances under which the software will crash. It is important to reveal the defects in real-time and
weak areas which are possibly caused by poor design. This testing is useful for the client perspective. When system operates correctly under conditions of stress, then clients can have confidence that the software can perform as required (Burnstein, 2003). And this will certainly valuable for the marketing points.
Security testing - This technique is used to evaluate the system characteristics that related to availability, integrity, and confidentially of system data and services (Burnstein, 2003) in a secure way. This testing technique should ensure no possible intrusion from external or internal sources.
Load testing Load testing is defined as the process of exercising the system under test by feeding it the largest tasks it can operate with (Agile Testing, 2005).
Compatibility testing - It is a testing technique conducted to ensure the compatibility of system/application with different web browsers, operating systems, and hardware platforms.
Usability testing - This testing technique is applied to evaluate the user friendliness of the software.
Regression testing - This technique is not a level of testing, but it is re-testing of software that occurs when changes are made to ensure that the new version of the software has retained the capabilities of the old version and that no new defects have been introduced due to the changes (Burnstein, 2003).
Finally, before the software delivered to the production phase, the final test is Acceptance Testing. This technique can be conducted by the company or client to validate whether or not to accept the product regarding to the agreed User Acceptance Testing criteria.
Before shipping the final version of software, alpha and beta testing are often done additionally. Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers' site (here is the outsourced companies). It is also often employed as a form of internal acceptance testing, before the software goes to beta testing. Beta testing whose software versions is better known as beta versions, are released to a limited users outside of the developers team. The software is released to groups of people so that further testing can ensure the product has few bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users. Two examples are Google Chrome (beta) and Skype 3.80 beta for Windows.
Remember that not all software systems need to undergo all the aforementioned types of testing techniques. Test planners and test team leaders need to decide on the appropriate testing techniques for particular software system. The choice depends on the characteristics of the system being tested and the available test resources. For example, if multiple device configurations are not a requirement of the system, then there is no need for configuration tests (Burnstein, 2003).
11.4 TECHNIQUES AND TOOLS Every company might have different decisions of what kind of testing techniques should be applied during their testing process. Small to medium software or modules that are
developed by company such as Netrom and Nokia Siemens generally need less time and testing techniques applied in order to evaluate the software system. Hence, most testing techniques are done in the outsourced countries. For companies such as Acision, Oce, Levi9, and Exact who have own development centers in the outsourced countries, test their software within those centers. Other condition may apply for Napoca, Servoy, and Inside who employ only unit and integration testing in the outsourced countries where the software is being developed. The remaining system testing is performed by their clients in the Netherlands.
Through the performed research, JIRA and Synergy are the most used tools as bug tracking system for software companies. However, some companies prefer to use their own built web application for this purpose. SVN repositories are a favorite choice as versioning tool among the companies. The overall view of the applied testing techniques and tools of the nine outsourcing companies are listed in Table 1.
Table 1 - List of applied testing techniques in different ten outsourcing companies
Testing Techniques
Acision (BusinessTools)
Napoca (Unit4Salary)
Servoy Netrom Inside (Databalk)
Nokia Siemens
Oce Levi9 Exact
Unit Brno Cluj Timisoara Craiova Bucharest Budapest Timisoara NoviSad K Lumpur
Integration Brno Cluj & Neth. Tim & Neth.
Craiova Bucharest & Neth.
Timisoara NoviSad K Lumpur
Functional Brno Cluj & Neth. Neth. Craiova Neth. Helsinki ‐ Budapest
Timisoara NoviSad K Lumpur
Performance Brno Neth. Neth. Craiova Neth. Budapest Timisoara NoviSad K Lumpur & Neth.
Load Brno Neth. Neth. Craiova Neth. Budapest Timisoara NoviSad K Lumpur
Usability Brno Neth. Neth. Craiova Neth. Budapest Timisoara NoviSad K Lumpur
Stress Brno Neth. Neth. Craiova Neth. Budapest Timisoara NoviSad K Lumpur
Security Brno Neth. Neth. Craiova & Clients
Neth. Budapest Timisoara NoviSad K Lumpur
Regression Brno Neth. Neth. Craiova Bucharest Budapest Timisoara NoviSad Kuala Lumpur
Alpha‐Beta product
‐ ‐ Beta version
Alpha version ‐ clients
Alpha release ‐ ‐ Alpha version Beta version
Tools Borland Studio (limited Pascal), BT Web Portal, MS Project, CM‐synergy, Gate Process tracking system
Visual Studio .NET, Automated bug‐ feedback system by Unit4
CLIPS, own built CMS as bug reporting tool
JIRA bug‐tracking system, MS Project, MS Excel, SVN repository, FTP tools
VPN software, proprietary bug – tracking system, TTP test tracker by Databalk
SVN repository, Crusie Control
QualityCenter, Merlin, QuickTest Pro
Apache Continuum, TestLink, JIRA bug‐tracking system, Mantis, WebLoad, Jmeter, OpenSTA, Compuware CARS, MS Word/Excel, Selenium, WebScarab Paros
Bug – tracking system from Synergy
Notes: - = is not applied
11.5 Case Study
11.5.1 Netrom
Netrom provides a big range of innovative IT software such as: 3D graphic, extended module of AutoCad for Architecture, different kinds of web applications, car-tracking system, and many more. Currently the company has more less 75 employees (mostly are developers) who graduated from local universities. They are working in four different department where each department works for different platforms, i.e. for Microsoft, Java, other web developments (PHP, Joomla, CRM tools), and Quality assurance which include the testing activities.
The tester team consists of five fulltime testers and one operational project manager. This team is focusing more on system testing. One or two persons from the developer team are also act as a tester for doing the unit and integration testing. The fulltime testers do not do ‘white box’ activities, only the testing project manager is responsible to validate the code before it can be tested. For most of their products, they have three different techniques for system test:
• Dummy test is done randomly by a tester who does not know anything about the software being tested. For example, by clicking any buttons of the software’ interface. This test looks similar to ‘usability testing’.
• Look and feel test has a goal to evaluate the features (such as colours, buttons, etc) of user interfaces which have to meet the requirements. This testing technique is also known as ‘GUI software testing’.
• Functional test is important to test the functionalities which have been on the requirements.
Netrom uses a ‘straightforward’ approach in developing their software. After receiving the test case from the clients, the test plan including the test design are made. When the company has received the agreement with the client about the test-design, the development phase to build the code is started. Since 85 - 90% of the projects use the agile development methodology; the test plan is divided into several modules that start to work at the same time. Therefore, during this phase, several unit and integration testing are done. When the overall system is finished, the mentioned three testing is ready to start. Some additional testing techniques such as performance, load, stress, and security testing; might be applied depend on the software complexity. Within the contract with the client, some extra maintenance might be necessary for relatively big software, including the regression testing. Also, depends on this contract, some clients want to be part of the tester during the software development process. Of course, here is in ‘black- box’ nature. Therefore, Netrom introduces two different terms of testers. Dedicated tester for testers from the client side and local tester is the testers of Netrom.
As the final step, acceptance testing is always done for all projects from all different platforms to be evaluated whether they have met the User Acceptance Testing or not, as well as its quality assurance. Related to acceptance testing, all found bugs are reported and tracked using JIRA with some own built extended modules such
as SharePoint access (www.microsoft.com/sharepoint), and several custom functionalities. All dedicated testers (client) have also an access to JIRA for particular project. Every project can have different configuration settings and modules within this tool.
When there are bugs or problems are found, the testing operational manager is responsible for scheduling the testing process including regression testing, if needed. All the feedbacks reports from clients are sent via the communication platform of Netrom, called Offshore Development Framework (ODF). It is a flexible framework that analyses the client’s information needs and structures the process of information exchange using checklists and a set of online tools and communication channels (Netrom, 2008). Subversion (SVN) repository is used as source management system for the version of delivered software and some Wiki information.
Regarding to tester recruitment, all candidates who have met the conditions will be tested in several stages. New testers will be assigned with some small projects before really involved to the real projects. The working result is validated first by the senior testers. The duration for new testers before involved to the real projects normally takes around one month.
It is concluded that Netrom with the range of its software products has been applying high-quality testing strategies. What make Netrom unique is that they have a specific and separate acceptance testing department to test all different kinds of projects, which is not often found in other companies.
11.5.2 Acision
Acision is a worldwide leader company for text-messaging in which two third of the text messaging service (SMS) around the world are sent using their product with the last version called SMSC v.5. The software that is used to manage SMSC v.5 called Business Tools.
At this moment, Business Tools (BT) is developed and maintained by a small team which involves 14 developers and one development leader, six testers and one test leader, one or two project managers, one requirement engineer, and one technical writer. The organizational structure of BT Team can be seen on Figure 2. All testing is done in Brno, Czech Republic. Unit testing and integration testing are responsible of developers. BT Test Team only does the system testing. All testers are obliged to follow Test Quality Plan for the assigned projects. The aim of Test Quality Plan is to cover the quality processes for test activities executed by BT Test Team. And the tester team leader is responsible for ensuring the compliance of projects regarding to the Quality Assurance.
Figure 2 - Organizational Structure of BT Team (Acision, 2008)
All BT Test Team always begins the testing process by producing the test documentation. The BT Test Leader first creates the test plan and test specification while BT Test members make the test descriptions and test reports. There is also a test manager application called BT WEB which is own-built web portal that are accessible for both developers and testers. All problems and bugs are reported into BT WEB with the agreed naming convention. Then, BT Test members create the test cases directly under certain scenario related to the reported problem on BT WEB. The test scenario is the most important part of a Test Case and consists of three types of information: Actions are steps which should be executed within Test Case. Second is Expected Results that describes some expected behaviour of application and the last one is Verify section which describes what should be verified within the step of Test Case (Acision, 2008). Next, Test Cases are executed using system testing activities, both automated and manual. BT Test Team distinguishes two types of system testing; System Testing for Fresh Development and System Testing for Incremental New Development. System Testing for Fresh Development defines all activities needed to handle quality assurance for completely new product. It follows standard waterfall lifecycle enriched with Gate Process milestones, which is an extended and modified V-model as it defined in Burnstein (2003). Figure 3 specifies the phases/activities and the responsibilities of BT Teams for the Fresh Development projects.
Figure 3 - BT Testing Process model or known as ‘extended V-model’ (Acision, 2008)
The system testing activities described in Table 1, such as load, performance, usability, stress, security and regression testing are mostly applied. However, since BT is a highly complex system, Acision also applies some additional testing techniques. They are instability testing to evaluate the ability of delivered software patch to be installed on supported platforms; configuration testing which focuses on the configuration aspects of the software; documentation testing to deliver user documentation to the delivered software; recovery testing to test the ability of software to recover from sudden malfunction of internal components (e.g. database restart), external components (e.g. disk array shutdown), or supporting sub-systems (e.g. network); storage and volume testing to evaluate the ability of software to manage its storage space as required; defects testing is to verify the implemented fixes to the agreed problem reports; and maintenance testing is used to verify the implemented fixes in regular patch releases (Acision, 2008).
The System Testing Incremental New Development type is more used for new features that are implemented in already developed product. In most cases, it involves less testing activities. Mostly they are only limited to defects testing, regression testing, and instability testing (Acision, 2008). Acision uses different term to call regression testing as ‘testing round system’. They introduce two different types of releases as part of the testing round system. The official release, which is only built for one or two particular clients and the differentiated release,
which is used for maintenance process for every 2- 3 months. The acceptance testing for both system testing types is done by reviewing the test cases and analyzing several metrics such as: the number of test cases, the number of test cases per test area, the number of test case result (passed, failed, skipped, blocked), and the number of Test Rounds.
Acision also uses system integration testing to ensure that two or more products can cooperate in symbiotic manner without operative incidents to create a solid solution (Acision, 2008). The BT Test Team holds regular meeting to discuss the current, suggested releases, documentation changes, unsolved problems on BT WEB and to prioritize some tasks including the testing round system. BT Test Leader schedules this meeting and assigns the representatives of the meeting.
Several other tools are used to provide good results of the testing activities such as MS Project to manage the planning of project and Borland Studio to write and run test scripts. Gate Process milestone is used for the tracking system while versioning system is done with CM-Synergy.
The tester recruitment process is done by interviewing the candidates. The interview consists of three stages. On stage 1 the candidate will be interviewed to see whether the general requirements and personal characters of the candidate match with the company profile. On stage 2, the candidate will be asked to do some scripting tests in C++ and also he/she will be asked about his/her testing knowledge including giving some additional feedback. At last, the candidate will also be interviewed by a Team Manager and be informed about the details of projects. The new tester will be assigned to a mentor to guide him/her to be acquainted with BT documentations and BT WEB, and practicing simple scripts. The new tester has also possibilities to do extra training courses once or twice a year.
The testing management of Acision is mature already, and this is essential for companies whose software products are complex likes Business Tools. The division of people and their tasks has been clearly defined. Therefore, from the interview they do not have any communication problems so far, also with the BT Development Team. As an addition, the regular meeting of Acision is an excellent approach to keep controlling and motivating the employees to always be discipline with the project plan.
11.5.3 Levi9
Levi9 Global Sourcing offers services for a wide range of platforms such as SAP basis support services, J2EE, Microsoft .NET, and Compuware. Levi9 develops and maintains (custom) software with more than 300 developers throughout Eastern Europe (Levi9, 2008a). The interview was held in Novi Sad (Serbia) because the Development and Quality Assurance center of Levi9 is located in this city.
For their software development process, Levi9 uses the Application Development Business Line model. Within this model there is a continuous process of four elements: the requirements are needed prior to development. Then development must
be evaluated before it can go to the production environment via testing management. Maintenance is important especially when the product has been launched to the market, either due to the found bugs or any new features implementation. Information about the maintenance process is also essential for the requirement documentations.
Levi9 defines ‘software testing’ as the mechanism to improve the software quality by showing that it performs as stated in the requirements, executing it with the intent of finding errors, and managing the risk of moving it from development to production (Levi9, 2008b). This definition is broader than the one from Myers (2004) because Levi9 uses Quality Assurance as the keystone of their testing management.
All testers at Levi9 are educated people from local universities. Many of them even have the certificates from selected training courses. Test teams work directly under the Software Testing Manager. The bigger view of the organizational structure of the people at Levi9 can be seen in Figure 4. The structure on that figure might be changed, depends on the involvement of the clients and the product complexity during the project.
Figure 4 - Organizational Structure of Levi9 (Levi9, 2008b)
Levi9 uses a risk-based testing, also known as the Quality Point approach. It is an approach that reduces the risk of distributing an application that does not meet business requirements and that does not function reliably. It helps Levi9 to determine what things to test and prioritize testing based on the cost of failure.
The greater the probability of an expensive failure, the more important it is to test that feature (Levi9, 2008c).
Related to this approach, Levi9 categorizes seven key process areas (KPA) which are: Test Planning, Test Case Development, Test Environment Preparation, Test Execution, Test Result Analysis, Management Reporting, and Quality Management. Test Planning is done to identify the items being tested, tasks to be performed, personnel responsible for each task, and risks associated to the plan. It is also important to develop the scope, approach, resources and schedule of the testing activities. The acceptance criteria are created by clients and the remaining by Levi9. Both the test strategy and test plan must have been reviewed and agreed by the Test Team, the Development Team, the User/Client Team, and the Management Team. The purpose of Test Case Development phase is to document the test cases that will be used to test the application functions identified during the first phase. Next, some steps that are necessary to prepare the environment for the test execution are documented in this phase. The documentation contains the description about the environment being tested, the initial setup, identification of data requirements, dependencies, recovery points, and backup – restore procedure of the environment. During Test Execution test cases are applied using several different testing techniques. Next, the results of Test Execution are compared with the acceptance criteria defined in the Test Plan. Reports are being made and provided to management with quality opinion based on the results of Test Execution and Test Results Analysis. Finally, within the Quality Management phase, the necessary steps to close out a product release test project are being coordinated. This includes cleaning up the test cases and discarding the old ones, archiving the old data, converting manual tests to automated tests, etc. These closing steps are necessary to ensure that the Software Testing Team will always have the tools needed to successfully repeat the testing process on subsequent product releases. Besides the KPAs, this approach also take consideration of the risky factors in which each of them has its own weight (scale 1-5). The factors are: test team, development team, release impacts, maturity and technical complexity of function, usage frequency, and defect impact (Levi9, 2008c; Levi9, 2008d). The KPAs are depicted on figure 5. Levi9 uses scrum methodology, and therefore, Software Testing is executed in parallel with the Software Development process.
Figure 5 - Software Testing Phases of Levi9
Unlike the Acision case, only unit testing becomes the responsibility of the developers at Levi9. Thus the testers work both on the integration and system testing. Several testing techniques which are used during testing process are: functional, performance, load, stress, compatibility, security. The security testing is done by following the Open Web Application Security Project (OWASP) guidelines which are listed on OWASP (2008). There are also two additional techniques, which are: smoke testing which is used as a ‘pre-test’ used to help determine if the application is fit for further rigorous testing as prescribed in the test plan; and common sense testing as an ‘ad-hoc testing’ to provide information about current quality of tested application and existing bugs with high priority. At Levi9, the acceptance testing becomes part of maintenance process. It has specific procedures for some types of activities which are listed on Levi9 (2008e). The acceptance testing can be done by Levi9, client, or combination team of Levi9 and client.
Levi9 uses many different tools to support their testing process. Apache continuum is used for the test coverage reporting. Compuware CARS toolkit is used to define the testing steps of a project. TestLink tool which is an open source application with many features for testing process (versioning, filtering, reporting, etc) is used for managing test scripts and knowledge sharing with the clients. For creating the automated scripts, Levi9 uses Selenium. And JIRA and Mantis are for the bug
tracking system. Some tools such as OpenSTA and JMeter are used for stress and performance testing, WebLoad for load testing, and WebScarab Paros for security testing. Some screenshots of the tools can be seen in figures 6 – 11. Like the previous case studies, the testers are recruited from local universities and via the network of the employees.
The software testing management of Levi9 is really mature since they have good and clear structure of KPAs. Their QualityPoint approach, which considers the risk management perspective, makes it different from the approaches done by the other eight companies. This case study will be a good example for company who has different wide range of big products or services.
Figure 6 - Screenshot of Compuware toolkit
Figure 7 - Screenshot of TestLink
Figure 8 - Screenshot of JIRA bug tracking system
Figure 9 - Screenshot of Open STA
Figure 10 - Screenshot of Mantis bug tracking system
Figure 11 - Screenshot of WebScarab Paros
11.6 CONCLUSION AND LESSON LEARNED Outsourcing software testing always becomes a challenge for software companies. Software testing process is done between the development phase and prior to the production phase of the software. Depending on the development methodology applied by the company, the timing becomes different. For example, a company that follows the agile methodology, software testing is started close to the time when software development is started. For waterfall and scrum, the schedule of test plan is generally different.
There are plenty of testing techniques available for every software company. But, the company should consider whether the techniques are necessary for their testing process or not. Thus, from the interview and some literature it is concluded that there are several factors of choosing the testing techniques, which are: the complexity of product, the methodology applied for the project, the size of tester team, the risks that may affected due to the errors or failure of the software, and of course the involvement of the clients during the testing process (related to the contract between the company and clients).
It is suggested to use case study 1 as a good example of testing management for software companies who produces many different types of small-medium products and involves less risks and maintenance efforts. In the contrary, case study 2 and 3 can be used as orientation for the testing process for companies who have high complexity products and the maintenance process.
11.7 REFERENCES Acision. (2008). Business Tools – Test Quality Plan. Retrieved on August 25, 2008.
Agile Testing. (2005). Performance vs. load vs. stress testing. Retrieved on September 3, 2008, from http://agiletesting.blogspot.com/2005/02/performance-vs-load-vs-stress-testing.html
Burnstein, I. (2003). Practical Software Testing. New York: Springer.
Beizer, B. (1990). Software Testing Techniques, Second Edition. New York: Van Nostrand Reinhold.
Chernak, Y. (2001). Validating and Improving Test-Case Effectiveness. IEEE Software 18(1), 81 – 86.
EtestingHub. (2007). Software Testing-Testing Life Cycles. Retrieved June 01, 2008 from http://www.etestinghub.com/testing_lifecycles.php
Farrel-Vinay, P. (2008). Manage Software Testing. New York: Auerbach Publications.
Geraci, A. (1991). IEEE Standard Computer Dictionary: Compilation of IEEE Standard Computer Glossaries. New York: Institute of Electrical and Electronics Engineers Inc.
Hower, R. (2008). Software QA and Testing Center. Retrieved June 01, 2008 from http://www.softwareqatest.com/
Jones, C. (1997). Software Quality-Analysis and Guidelines for Success. Boston: International Thompson Computer Press.
Levi9. (2008a). Company Profile of Levi9. Retrieved on September 5, 2008 on http://www.levi9.com/en-US/Pages/Home.aspx
Levi9. (2008b). Levi9 - Software Development. Retrieved on July 22, 2008.
Levi9. (2008c). Levi9 QA: Software Testing. Retrieved on July 22, 2008.
Levi9. (2008d). Software Testing Approach. Retrieved on July 22, 2008.
Levi9. (2008e). Maintenance General. Retrieved on July 22, 2008.
Myers, G.J. (2004). The Art of Software Testing. New Jersey: John Wiley & Sons, Inc.
Netrom. (2008). ODF. Retrieved on September 15, 2008 on http://www.netrom.ro/new/en/werk_ont.html#odf
NIST News Release. (2002a). Software Errors Cost U.S. Economy $59.5 Billion Annually. Retrieved June 01, 2008 from http://www.nist.gov/public_affairs/releases/n02-10.htm
NIST Planning Report. (2002b). The Economic Impacts of Inadequate Infrastructure for Software Testing. Retrieved September 05, 2008 from http://www.nist.gov/director/prog-ofc/report02-3.pdf
OWASP. (2008). OWASP Guidelines. Retrieved on September 6, 2008 from http://www.owasp.org/index.php/Category:OWASP_Guide_Project
Sogeti. (2008). Essentials of TMap Next. Retrieved on September 7, 2008 from http://eng.tmap.net/Home/TMap/The_4_essentials/index.jsp
Vingrys, K., Singham, R., Fowler, M, Parsons, R., et al. (2008). The ThoughtWorks Anthology - Essays on Software Technology and Innovation. United States of America: ThoughtWorks, Inc.
Whittaker, J.A. (2000). What Is Software Testing? And Why Is It So Hard? IEEE Software, 17(1), 70 – 79.
Woodward, M. R., & Hennell, M. A. (2005). Strategic benefits of software test management: a case study. Journal of Engineering and Technology Management, 22(1-2), 113 – 140.
12 Software Maintenance in Outsourced Projects By Rudy Katchow
The maintenance phase of the outsourced software project consumes a large part of the overall lifecycle costs. It is estimated that the maintenance phase constitute more than 50% of the total effort to build software products (1) (2).
In this chapter we concentrate on near-shore outsourcing of software development in Distributed Software Product Development (DSPD) environment. Ramasubbu & Balan (3) define DSPD as the division of labor by dispersing software development tasks among several remote development centers. While DSPD can provide many advantages such as the ability to increase the working hours beyond the single working site and reducing the development cost, it on the other hand has some disadvantages, such as increasing the cycle time of the DSPD maintenance projects and requiring more effort in implementing these compared to on-shore environment (4) (5).
Software maintenance necessities are intensive customer contact, short iteration cycles, and rapid response times (6). These characteristics contradict with the off-shoring practice that is usually accompanied with delays in terms of communication, frequent misinterpretation of requirements and lack of direct accountability.
With the growing popularity of outsourcing in general and DSPD specifically, software companies now have an alternative to outsource their support and maintenance operations. This can free up their time and make their developers to focus on the company’s core business. It helps to accelerate the development life-cycle of their product while maintaining a high level of customer satisfaction (7).
According to Gartner (8), many of the offshore projects will fail due to the lack of appropriate planning of these projects. Seybold & Keller (6) suggest also that software maintenance projects with short release cycles and small work packages are not good candidates for offshore development. To successfully implement near-shore outsourcing of software maintenance in DSPD environment, it is necessary to make the appropriate estimates of the feasibility of the near-shore outsourcing projects.
This chapter is mainly targeted at software project managers to help them to select the best methods for implementing DSPD maintenance projects, also it provide these managers with the experience from the case studies presented in this chapter as well as the some recommendations to alleviate the risks that might accompany the implantation of the software maintenance outsourcing project.
The first section includes an overview of software maintenance, maintenance categories, activities and models. During the following sections, we demonstrate the best practices and methods to implement software maintenance projects in DSPD environments. Afterwards transition management is illustrated with two case studies that we conducted during our research in Eastern Europe.
Furthermore, we elaborate with two case studies, (from scientific literature and from our conducted research in Eastern Europe), the support and maintenance
management and the interaction between different lines of support. Then we present release management from DSPD software maintenance perspective.
The last section contains the lessons learned, future researches and some recommendations to alleviate some of the risks that usually accompany the implementation of DSPD near-shore software maintenance projects.
12.1 Outsourced software maintenance overview
12.1.1 Definitions
Software maintenance is a broad activity comprising all the work done on a software product after its release to the customer. This includes the correction of errors and bugs, enhancement, deletion and addition of features and capabilities, adaptation to new technologies, the improvement of performance and other quality attributes (9).
The IEEE (10) defines the software maintenance as the modification of a software product after delivery by correcting faults, improving performance or other attributes or adapting the product to a modified environment.
The ISO/IEC 12207 standard for Life Cycle Processes (11) considers maintenance as one of the primary life cycle processes and describes maintenance as the modification to code and associated documentation due to a problem or the need for improvement. The objective of software maintenance is to modify existing software products while preserving its integrity.
12.1.2 Categories
As we can observe from these definitions that the software maintenance goes beyond the narrowly view of correcting errors to more wide perspectives. The IEEE had divided software maintenance efforts into four components. The IEEE (10) definitions of these categories are as follows:
Corrective maintenance: Reactive modification of a software product performed after delivery to correct the discovered faults.
Adaptive maintenance: The modification of a software product performed after delivery to keep the product usable in a changed or changing environment.
Perfective maintenance: The modification of a software product performed after delivery to improve performance or maintainability.
Emergency maintenance: Unscheduled corrective maintenance performed to keep the software product operational.
These definitions indicate that the software maintenance can be classified as scheduled or unscheduled and reactive or proactive as shown in Table 1 (9).
Table 1: IEEE categories of software maintenance
Scheduled Unscheduled
Reactive Corrective
Adaptive
Emergency
Proactive Perfective
ISO on the other hand has established three categories of software maintenance: problem resolution, which involves the detection, analysis, and correction of software malfunction; interface modifications, which is required when additions or improvements are made to the hardware system controlled by the software and functional expansion or performance improvement, which may be required by clients during the maintenance stage (12).
Canfora & Cimitile (9) have depicted a correspondence between ISO and IEEE maintenance categories as shown in figure 1.
Figure 1: Correspondence between ISO and IEEE maintenance categories
12.1.3 Software maintenance approaches
A typical approach to software maintenance is the quick-fix model (as shown in figure 2); that is based on modifying the source code first and then makes the necessary changes for the accompanied documentations. However most of these code modifications are made on the fly without making appropriate changes to the original design and documentation. The disadvantage of this model is that the modifications are not well documented (under time and budget pressure) that can demolish the original design and making future modification more costly to implement (13).
An alternative approach is the iterative enhancement model, this model based on the idea that the software products are developed in builds in which each of these builds correct, refine, and improve the performance of previous builds. The advantage of this evolutionary approach is that the documentation is kept updated while the source code is changed; also this approach is best suited for products with long and dynamic life cycle (14). Figure 3 demonstrates the iterative enhancement model.
Requirements
Design
Requirements
Test
Code
Design
Test
Code
Old System New System
Analysis Analysis
Figure 2 : The quick-fix model Figure 3 : The iterative enhancement model
12.1.4 Software Maintenance processes
Software maintenance processes propose the essential operations and related activities in addition to the detailed input/output to these operations (15).
The IEEE-1219 standard for software maintenance describes the maintenance process model in seven phases as shown in figure 4. These processes start after the
stage of post delivery of the software products and the IEEE-1219 elaborates the activities of the subsequent phases and their order of execution as well as the input/output deliveries in addition to the supporting processes and control milestones at each phase (10).
Figure 4: The IEEE Maintenance Process Activities
ISO/IEC 14764 (16) is an elaboration of the maintenance process of ISO/IEC 12207 standard (11), which deals with the totality of the processes comprised in the software life cycle. The activities described in the ISO/IEC 14764 are similar to those documented in the IEEE 1219, although the ISO/IEC 14764 is demonstrated differently as shown in figure 5 (15). The processes of the ISO 14764 standard are organized into constituent activities which are further sub-divided into tasks.
Modification Request
Figure 5: The ISO/IEC Maintenance Process Activities
12.2 Roadmap for implementing software maintenance In order to carry out software maintenance in DSPD, one approach is to keep the maintenance in-house (the maintenance teams distributed in near-shore and on-shore locations but they are part of the same company), an example of this approach are Océ, Nokia Siemens Networks and even small software companies like Servoy, a Dutch IT company which established its own near-shore maintenance team in Timisoara-Romania.
Another approach is outsourced maintenance, where maintenance is outsourced to a third-party that performs the maintenance operations in collaboration with the outsourcing company. Example of companies that adopt this approach is Unit4agresso, (an international developer and distributor of IT solutions which is headquartered in the Netherlands), that outsourced the maintenance of their payroll product to Napoca software, (a small software company in Cluj- Romania), and other Dutch companies that outsourced the maintenance of their products to Netrom, (a big offshore software development company in Craiova -Romania).
One of the major advantages of outsourcing maintenance to a third party is that companies can focus on their core competencies in the development of new products. Outsourced companies offer at least one of the following benefits: staff availability, special expertise or low prices. However there are also many risks associated with this approach (7). The service level agreement (SLA) between the outsourcer and the outsourced company should include all the terms and conditions to alleviate or reduce the risks that might be associated with the
Maintenance Review Acceptance
Problem and modification Analysis
Modification Implementation
Process Implementation
Migration
Retirement
outsourced maintenance projects. An example of these conditions is keeping the outsourcer informed formally about all the maintenance activities especially for corrective and adaptive maintenances (7).
During our interviews with some software companies in the Netherlands and Eastern Europe, we have identified some of the advantages and disadvantages that are associated with each of the previously mentioned approaches. These are illustrated in Table 2.
In addition to these two approaches, a new approach is emerging that is out-tasking maintenance. This approach is based on outsourcing in part the maintenance processes and active cooperation with outsourcers in performing the software maintenance operations partly. This cooperation reduces the risks of depending entirely on outsourcers and also efficiently reduces the cost of software maintenance at longer outsourcing agreement (17).
Table 2: Comparison between In-house maintenance and outsourced maintenance approach
In‐house maintenance Outsourced maintenance
Advantages:
Guarantee the quality of the provided maintenance services
Pay‐ by the job done
Independency and direct control of the maintenance activities.
Cost reduction if properly managed.
Assure that the company’s IP (intellectual property) remains within the company
Provide more time to the outsourcer’s developers to develop new products.
Managing in‐house maintenance projects is easier and less risky than outsourced maintenance which requires special experience in this field.
Staff availability with different expertise
Disadvantages:
Extra personnel and investment costs (salaries, bonuses, compensations, software tools and licenses, equipments, training cost)
Extra overhead expenses due to communication and integration of systems as well as knowledge transfer cost.
Work‐overload of maintenance activities might increase the pressure on the developers to build up new products
Maintenance quality can not be directly managed and monitored.
Keep certain expertise solely to support obsolete technologies that are developed for certain products
The process of integration and building trust relationship between the outsourced maintenance teams with the development and other line of support teams of the outsourcer is difficult and need lot of time compared to in‐house maintenance.
Difficulty to find skillful personnel Cultural differences and communication difficulties can hurdle the efficiency of the maintenance operations.
Dependency on the outsourced company.
12.3 Transition management One of the major challenges to the outsourced maintenance projects besides determining the scope of the required efforts in handling these outsourced projects is the transition of the maintenance activities for the software products to the outsourced company (1).
The stage of maintenance transition covers the seamless movement of the sustainability and maintenance operations of software products from one organization to another. This includes transferring the required knowledge and expertise that helps the outsourced company to perform all maintenance operations of the system.
In this section, we present some of the best practices that help the other project managers to assure successful implementation of this critical stage. The first case study reflects the experience of Levi9, a major global outsource company. We will look also at some of the practices and experiences of Acision, a world’s leading messaging company, in moving their software maintenance of one of their product to another outsourced company.
12.4 Levi 9 (Outsourced Company) case study: In this case study we will present from the point of view of outsourced company, the required steps and recommendation to achieve a successful transition of their accepted software maintenance projects.
12.4.1 Transition plan stages
The transition plan at Levi 9 is composed of 5 major stages (milestones) as shown in figure 6 in white boxes.
Step 1: On-Boarding
This stage involves conducting all the required trainings for the employees (in case the project require specific technologies, then extra training for the basic of these technologies are also performed in this stage). This stage also involves reviewing the project’s documentation, installing the development environment, becoming familiar with the application from the end-user perspective and carrying out code analysis and review.
Step 2: Instructional Training
This stage comprises of transferring more specific knowledge to the maintenance team in the outsourced company, this includes knowledge about the functional requirements, business models, release procedures, implementation guidelines, workflow procedures, communication procedures and reporting policies.
Step 3: On-the-Job Training
The outsourced maintenance team will begin an on-the-job training by working jointly with the original outsourcer maintenance team to provide the required support for the software products. Outsourced maintenance team will work initially with the outsourcer team together as practice (paired work, work
shadowing, parallel work, guided experience and experimentation) and later independently.
Step 4: Evaluation
After certain period (usually several months depending on the project’s size and complexity) of joint work between the outsourcer and outsourced maintenance team, a monthly assessment is carried out to make sure that the knowledge transfer is transmitted according to the defined schedule. In case of deficiency or delay of knowledge transfer, then some correctives measures are needed to overcome these insufficiencies; this includes providing remedial training or adding extra resources to the maintenance team.
Step 5: Hand Over
Once the outsourced maintenance team proves its ability to maintain the products successfully, the formal hand over stage can takes place. If the outsourced maintenance team can not maintain the products independently, more time should be given to the outsourced maintenance team to assure that maintenance capabilities are transferred sufficiently. During the transition process, some flexibility is considered necessary to overcome some of the external factors as the timely recruitment of human resources, staff changes and training availability.
Figure 6: Transition stages (milestones) in the front and their main transition processes in the back
12.4.2 Transition processes
The main goals of the transition strategy at Levi9 are to assure the continuity of the business activities during the transition period and the retention of knowledge during the knowledge transfer phase. The main transition processes are shown in figure 6 in the blue boxes.
Phase 1: Initial Assessment and Planning
During this phase the technical documentations of the product are reviewed, the required human resources are assigned to the project and the possible risks associated with the project are identified and documented.
Communication is essential to the success of the whole transition plan and of this phase in particular. Hence, Levi9 makes sure to agree with its clients (according
to their communication culture) on specific timing, communication mode and reporting policy.
The outsourcer maintenance and development teams are highly involved in this phase because they represent the principal source of the knowledge for outsourced maintenance team. The main output of this phase details the purpose and scope of the transition period, roles and responsibilities, schedule and milestones, training plans, knowledge acquisition plan (it is an application level document that tracks the schedule and efforts for each activity within the transition period), infrastructure plan (the required infrastructure for the transition) and governance plan (details about some mechanisms: e.g. quality management, progress reporting, escalation mechanisms, and document management).
Phase 2: Training and Knowledge Acquisition
Levi9 team starts performing in this stage some of the non-critical support activities with the supervision of the outsourcer’s team; this can be done through parallel work, pair programming, and work shadowing.
The outsourcer is then involved by providing the required knowledge and assistance through holding the necessary training and workshops sessions for Levi9’s team to help them performing their assigned issues (problems or incidents) and also monitor the quality of the performed activities.
Phase 3: Capability Transfer
This phase involves an actual simulation of the on-shore support and maintenance activities to be provided from Levi9’s near-shore development centers. Levi9 team will use on-shore facilities of the outsourcer to interact with the end-user through email and telephone with the supervision of outsourcer maintenance team. This simulation is done to make sure that Levi9 team is capable of performing all the required processes defined in the maintenance project. The results of this simulation are used to estimate the readability and the capability of the outsourced team and reveal some of the capability gaps or other practical issues that need to be solved prior to completing the transition period.
It is necessary at this stage to decide which team will be primary responsible for the maintenance activities and also to create an environment on the outsourcer side where the maintenance team can shadow the maintenance activities done by the outsourced company without negative impact on the performance of their assigned duties.
Phase 4: Capability Demonstration
In this phase, the outsourced maintenance team takes direct responsibility for the maintenance and support activities. The outsourced teams will handle almost all maintenance issues, including the critical ones with the support from the outsourcer maintenance team.
The capability of the outsourced maintenance team and the quality of the resolved issues is evaluated regularly by both the outsourcer and outsourced
company. The result of these evaluations shows whether the outsourced maintenance team is ready to be handed over the maintenance activities.
Phase 5: Support Handover
The formal hand-over of the maintenance activities is made during this phase. The outsourced maintenance team should demonstrate that it is capable of providing the sustainability of operations and maintenance responsibilities.
This stage involves some additional services proposed by Levi9 to the outsourcer company to improve the quality of the source code and provide extensive technical documentations for the outsourcer’s products by rewriting the functional and technical specifications if not existing, writing missing unit tests and lowering code complexity through refactoring the source code.
12.4.3 Proposed Transition Team
The Transition project is an onshore centric activity in which most of the activities are gradually shifted to near-shore locations. Levi9’s transition team will consist of a dedicated transition manager, near-shore project manager, and other transition team members as shown in figure 7.
The transition manager will be responsible to: manage Levi9’s transition team, coordinate with the outsourcer project manager, define processes and the plan for transition, communicate the progress of the transition project with Levi9’s account manager, help the outsourcer in moving their current business model to near-shore models and continually monitor and manage the progress of the transition phase. Figure 7 shows the organizational structure for the maintenance and support operations during the transition phase.
Figure 7: Management structure of the maintenance operations during the transition phase
After the completion of the transition phase, the near-shore project manager at Levi9 will be the single point of contact with the outsourcer side (usually the outsourcer’s application manager). Levi9’s near shore project manager will make sure that the reported issues and requirements are well documented and understood, he/she will also manage and coordinate the allocation of the reported issues to his/her maintenance team and assist the outsourcer’s application manager in scheduling the releases of the outsourced products. Figure 8 depicts the management structure of the outsourced maintenance after the completion of the transition period.
Figure 8: Management structure of the maintenance operations after the completion of the transition
phase
12.5 Acision (Outsourcer Company) case study: In this case study, we will investigate how the transition project is realized from the outsourcer point of view. In one of Acision’s products, the decision was to assign the maintenance operations of the third line of support (also called sustainability) to an outsource company. One of the main drivers behind that decision was the lack of human resources and the strategic choice to allow the current maintenance team focuses on the development of new products.
The tasks of the third line of support or sustainability team is to resolve the assigned issues by performing minor changes in the source code to provide work around solutions. In case the problem requires major code changes then it is allocated to the fourth line of support, or the maintenance team that develop new features and new products, to provide the necessary patches.
Acision realized, from its long experience in the outsourcing in DSPD environment, that the major issue for a successful transition phase and subsequent cooperation is building trust with the outsourced company. The main phases of the transitions projects are illustrated below and the general timeline for implementing maintenance transition project is shown in figure 9.
Stabilization phase - It is necessary to wait until the product is stabilized before conducting the transfer of the maintenance operations. During the stabilization phase of the product, many bug fixes and new features are carried out.
Training phase - The training phase of the outsourced company can be overlapped with the stabilization phase as shown in figure 9. This stage entails transferring detailed knowledge about the product and how it work internally.
Integration phase - Since the 1st, 2nd lines and 4th line of support (which is the development teams) remained within Acision, the integration phase of the outsourced 3rd line with the previously mentioned lines is an important issue. This includes integrating the different ticketing systems of these lines, agreeing on the communication policies and defining the responsibilities for each line of support.
Cutting over phase - Once the integration phase is completed successfully, the cutting over phase can begin by moving gradually the maintenance operation of the 3rd line to the outsourced company.
Monitoring and backup phase - The monitoring and backup phase is a continual process. This phase makes sure that the quality of the services provided by the outsourced company is within the terms of the agreed SLA’s. In case of peak-up work, some assistance from the development team (4th line of support) can be offered to assist the outsourced 3rd line in reducing the work overload.
Figure 9: Timeline for implementing the maintenance transition project
12.6 Maintenance management In this section we will provide an overview about the organizational structure of the maintenance teams and how the roles and responsibilities are distributed between the different lines of support. During our researches which were conducted in summer 2008 in some companies in the Netherlands and Eastern Europe, it appeared that the pattern of support structures varies according to the size, geographical distribution of the company and the complexity of the provided support. We have identified two patterns of organizational structure for the maintenance and support activities. The first pattern is for the small to medium companies, an example of this pattern is Databalk, Dutch provider of ICT solutions for housing corporations. The second approach best suits large companies, an example are Océ, Nokia Siemens Networks and Acision.
The maintenance support for the small-medium companies are usually organized into three lines of support, where the 1st and 2nd line are responsible to make the initial contact with the clients, provide the preliminary support and identify the
technical problems. These technical issues are then allocated to the 3rd line of support. Databalk for example outsources its 3rd of support to Inside software a Romanian software company. In addition to performing the maintenance activities, the 3rd line (in Databalk case) is also responsible for the further development of these products (add new features and functionalities).
The maintenance support of large companies is usually organized into four lines of support. Figure 10 shows the interaction between the different lines of support in DSPD environment for a typical large company.
The 1st line of support also known as the help desk is usually distributed in small centers all around the world. The help desk make the initial contact with the clients, provide the first line investigations and diagnosis, solving the issues and service requests (if they are able), making sure to keep the clients informed about the progress of their request and conducting sometimes customers satisfaction surveys (18). The help desk also log all the details of the reported issues and requests in the ticket tracking system and escalates these tickets to the 2nd level of support when it can not provide the necessary assistance. Tickets can also express the wish of the clients for extra functionally or new features; this will be handled as part of the requirement management activity.
In Acision the 1st line of support is distributed in 3 major centers (Brno- Czech Republic, Sao Paolo- Brazil and Kuala Lumpur- Malaysia) while for Nokia Siemens Networks, the help desks are distributed in small office around the world. This distribution facilitate the communication with the client using their own language while at the same time allows for 24 hours support using the “follow the sun model” (although this advantage is not used extensively in this company).
The 2nd line of support usually consists of business consultants, who are mainly responsible to separate the functional issues from the technical issues. Based on their knowledge, they provide more extensive support for the clients and they can further investigate their assigned issues to identify if the issue occurs due to technical problem and in that case the issue will be re-assigned to the 3rd line of support. The second line is distributed in few offices around the world, in case of Nokia Siemens Networks; it is distributed in several locations around the world (e.g. Beijing, Budapest).
The most important candidate for outsourcing in DSPD environment is the 3rd line of support also known as sustainability. The 3rd line of support is responsible to make the necessary changes in the source code to solve the technical issues and can also participate in the development of new features together with the development team. For Nokia Siemens Networks the 3rd line of support for one of their products is distributed in two locations, namely Budapest and Helsinki, each of these two teams is responsible for the maintenance of certain modules of the product. In the case of Acision, the 3rd line is outsourced to a third party. There responsibilities is to make minor changes to the source code or work around solutions and to provide extensive technical analysis of the major issues to the 4th line (developers) to make the necessary changes.
The fourth line of maintenance or developers of the product are usually not outsourced and they are responsible for solving the major bugs in the system and adding new features as part of the continuous development of the products. We
have found out that in most of the companies that we had interviewed, the developers assign 20% of their time to resolve bugs in their stable products while they spend the remaining 80% of their time to develop new features and functionalities.
Figure 10: The interaction between the different lines of support in DSPD environment
Assuring adequate communication between the different lines of support is one of the crucial issues for the success of the maintenance process. One typical example of issue in this context is the lack of documented information on the reported tickets that are escalated by the 1st and 2nd line to the higher levels of service support; resulting in increased work overload on the 3rd line and thus delays the resolution of the issues.
Another topic is the importance to continuously monitor the quality of the performed activities for each line of support. For example, if the 2nd line of support does not function effectively, this will increase the work overload on the 3rd line with many issues that could be solved by the 2nd line of support. The integration of the issue tracking systems between the different lines of support is
an also an important topic in optimizing the maintenance and support in DSPD environment.
The most important communication’s tools that can be used between the different lines of support beside telephone and email are Skype and Netviewer, while for the issues tracking systems like Jira and Bugzilla exists. Figure 11 shows a snapshot of some of these tools. Another tool which is necessary to make sure that the source code remains integrated and intact among the distributed teams is CruiseControl which is a framework for a continuous build process. Figure 12 shows a snapshot of CruiseControl application.
Figure 11: Screenshot of some of the tools used in software maintenance (Netviewer and Jira)
Figure 12: Screenshot of CruiseControl application, a framework for continuous build process
12.7 Support and Maintenance management techniques In this section, we will elaborate on some of the concepts that are used for managing the software maintenance activities. One of the best sources of these best practices is the Information Technology Infrastructure Library (ITIL) which is a registered trademark of the United Kingdom’s Office of Government Commerce (OCG).
In dealing with the software maintenance, we will focus on the service operation phase. This volume of the ITIL V3 (18) represent the practices in the management of service operation and provides the guidance to achieve efficient and effective delivery of services to the clients.
There are a number of service operation processes that combined together provide an effective IT support structure. We will analyze these service processes from the maintenance operations from a DSPD perspective.
12.7.1 Event Management
It provides the techniques to compare the actual events and performance against the design standards. This will provide the necessary mechanism to detect incidents before they occur. These methods are usually used in implementing preventive maintenance approaches.
12.7.2 Incident Management
It focuses on restoring the malfunctioning service of the clients as quickly as possible. Incidents include failures, bugs, questions which are usually reported by the client to the help desk or detected automatically via an event management processes. In this context, it is necessary to define time scales (based on priority of the incidents) to handle this incidents. These timescales should be well document in the SLA’s with the outsourced companies in the case of outsourced maintenance approach.
Levi9 has adopted the ITIL framework in performing their incident management processes; figure 13 represents their incident lifecycle and incident management through the different lines of support.
Figure 13: Incident management through the different lines of support
12.7.3 Problem Management
It deals with managing the processes of resolving the cause of the incidents and prevents the recurrence of these incidents in the future. It also ensures that the implemented resolution conforms to the control producers and is included in the release management process (18).
Although incidents management and problem management are separated processes, they are closely related and they share the same tools to assure that the best level of service quality and availability are maintained. An example of problem and incidents management processes is shown in figure 14.
12.7.4 Request Fulfillment
These are activities that deal with the realization of the demands that are expressed by the clients. Although, some of these demands are reported to the service support, they do not represent a disruption of the provided service; these processes are handled as part of the requirement management phase.
Update Incident record with classification data
Update Incident record with ID of Known Error
Extract resolution or circumvention action from Known Error Database
Can Service Desk resolve?
Executeresolution action
N
Update Incident count on Known Error record
Inform Customer of Work-around
Process Incident/Problem
Allocate to Problem Management team
New Problem alert
Raise new record on Problem Database
Match on Problem Database?
Match on Known Error
Database?
Routine Incident?
Incident alert
Asses Incident and follow routine procedure
N
N
N
Y
Y
Y
Y Support required?
Executeresolution action
N
Y
Update Incident record with classification data
Update Incident record with ID of Problem
Extract resolution or circumvention action from Problem Database
Update Incident count on Problem record
Close incident / problem
Prioritization
Figure 14: Problem and incident control process flow
12.8 Release Management Software release management is defined as the process through which software is made available to and obtained by its users (19). Delivering of small and subsequent releases assure incremental evolution and development of the products which in turn bring many advantages compared to delivering a monolithic product after long development time. Some of these advantages are the possibility to prioritize the requirements, reduce the time to delivery, easiness to estimate the schedule/cost for these smaller releases, client’s feedback obtained from each small release can be used to improve the product and most importantly is this incremental approach allows for more flexible and dynamic reactions to changes and addition of requirements (20).
In this section we will concentrate on the release management from the software maintenance perspective in DSPD. During the development phase, the first running version of the products is released. Following this initial release, the product enters into the maintenance phase with the goal to adapt it to the ever changing user requirements, the operating environment and the traditional resolution of incidents that might occur during the products’ utilization (21). The evolution of the software product might follow two different pathways, which are the major release (upgrade) and minor releases (updates).
A minor release occurs when the clients updates its product from one build of release to another (e.g. V2.1 to V2.2). These minor releases can also be issued based on the requirement to carry out small enhancements and corrective or emergency fix. At the end of the minor release path, there is the phase out state in which the current version is no more supported.
The major release occur when the clients upgrade their product to a newer release version (e.g. from V3.0 to V4.0), these major releases are issued when there are large amount of new features and functionality developed, also these major releases supersedes all preceding minor release since the last major release (22). Figure 15 shows a representation of this versioning structure.
Regarding the near-shore DSPD, we have realized that the same release management approach can be used. However, we have recognized some of the observations concerning the release management:
• Defining the priority of the requirements to be included in the next releases remains mainly the task of the outsourcer side even if the development and maintenance process is outsourced to third party.
• Most companies divided their products into modules which are assigned to different teams. For example the product manager of Servoy has assigned the different modules of one of his product to his two maintenance teams (Amersfoort-The Netherlands and Timisoara-Romania); as a result, new ticket (e.g. new features or bugs fixing) are assigned to the team in which their assigned module is directly affected by the new ticket.
• The release frequency is generally planned as one annual major release and one seasonal minor release, thus the release frequency does not depend on the number of the made changes.
• Since different teams work on different modules of the same products, there is a lot of interaction between these teams. Therefore, it’s advisable to keep the source code of the different releases under development centralized in one location (for example Nokia Siemens Networks performs daily synchronization of the source code of all their development teams and keep this centralized in one of their centers) to avoid redundancy and assure that all teams become informed when changes are made in the different modules.
Figure 15: Release management (versioning structure)
12.9 GEC Case Study In this section, we will elaborate on how to efficiently support the off-shore software maintenance in DSPD by studying the case of GEC, a global B2B e-commerce service provider. This case study is derived from the work of Yan (23).
GEC has developed an e-commerce product for one of its clients that is one of the biggest global companies. Development was outsourced to another company in Malaysia and GEC’s client currently maintains the product.
After the completion of the code development, the maintenance was carried out in different locations (e.g. Malaysia, US) as shown in figure 16. A team connection tool managed all issues reporting, processing history and assured the proper coordination between the different locations.
Figure 16: Maintenance phases of GEC
Yan (23) has drawn some the lessons learned from his research and suggested henceforth some important recommendations:
• Influence of over-time work could degrade in long term the efficiency of software maintenance; therefore it is necessary to agree with the clients in the contracting phase about the manipulation of emergency maintenance to avoid over-time work.
• Performance parameters and scalability were not considered seriously at the design phase which had resulted in serious consequences and extra-work in the maintenance phase; this could be alleviated by hiring experienced consultants in tuning the performance during the design phase, the outsourcer should also provide the expected scalability limits of their products to the outsourced company.
• Communication and time difference, although the latter suppose to give advantage to round-the clock development, had played a role in delaying the feedback from the remote locations; one way to improve these issues is through sending liaison engineers to the remote site and introducing efficient communications tools such as instant messengers.
• The main reason for maintenance delay was the difficulty to reproduce and simulate the problem in the local environment; therefore setting up similar development and maintenance environment of the products and providing extensive information about the reported issues could help in reducing the effect of this simulation problem.
• The lack of sufficient training for the outsourced maintenance team resulted in delaying the transfer of knowledge between the outsourcer and the outsourced company; thus, it is necessary to introduce formal training sessions.
The conducted research on the GEC case revealed the importance of trust between the outsourcer and outsourced company and the mutual understanding which facilitated the compromise in many topics (for example work’s delay versus extra urgent requirements). Communication, liaison engineers and compatibility of the systems between the outsourcer and outsourced company were also crucial factors for assuring efficient maintenance of this software product. There are other important factors but they are common to the centralized software maintenance.
12.10 Conclusion and lessons learned In this chapter we have provided an overview of the best practices in implementing outsourced software maintenance projects in DSPD. These practices were depicted from scientific literature and our conducted researches in some of the IT companies in Eastern Europe and the Netherlands. We would like to summarize in this section the main lesson learned from these practices.
Building trust between the outsourcer and outsourced company that can be achieved through long-term collaboration and mutual understanding, common commitment and passion for carrying out the mutual work are the key points of success for any outsourced maintenance projects. Assuring an adequate communication system is also considered a crucial task, this can be realized by setting up single point of contact through coordinators and project managers, installing effect communication tools, sending liaison engineers to work in off-
shore locations and understanding the cultural differences between the outsourcer and outsourced company.
Beside the previously mentions issues there are other topics, integration of the systems between the outsourcer and outsourced company, setting up clear SLA agreement that defines the roles and responsibilities for each part, sufficient training, efficient knowledge transfer and requisition and making sure that the reported issues and requirements are well documented and understood are all important topics that require more attention to assure the efficient maintenance in outsourced DSPD environment.
Although there are many advantages that are associated with outsourcing the maintenance to near-shore companies, we have also realized that the scarcity of human resources in special expertise is the primary driver for choosing this option by the Dutch companies and not for cutting cost only.
The lack of sufficient research in the field of software maintenance in near-shore DSPD environment will encourage many researchers to investigate many related questions. For example, future work in this field is needed to develop model for efficient software maintenance in DSPD environment and to standardize the offshore-software project management.
12.11 References 1. Pigoski, T. M. (1996). Practical Software Maintenance: Best Practices for Managing
Your Software Investment. John Wiley & Sons Inc.
2. Boehm, B. (1976). Software engineering. IEEE Trans. Comput. , 25, 1226-1241.
3. Ramasubbu, N., Balan, R. K. (2007). Globally distributed software development project performance: an empirical analysis. Proceedings of the 6th joint meeting of the European software engineering conference, Dubrovnik, Croatia, 125-134.
4. Carmel, E., Tjia, P. (2005). Offshoring Information Technology Sourcing and Outsourcing to a Global Workforce. Cambridge University Press.
5. Herbsleb, J. D. Mockus, A. (2003). An Empirical Study of Speed and Communication in Globally Distributed Software Development. IEEE Transactions on Software Engineering, 29 (6), 481-494.
6. Seybold, C., Keller, R.K. (2008). Aligning Software Maintenance to the Offshore Reality. CSMR 2008 - 12th European Conference on Software Maintenance and Reengineering, Athens, Greece, 33-42.
7. Ejaz Ahmed, R. (2006). Software maintenance outsourcing: Issues and strategies. Computers & Electrical Engineering, 32(6), 449-453.
8. Niccolai, J. (2005). Gartner: Five reasons why offshore deals go bust. Computer world. Retrieved September 1, 2008, from www.computerworld.com/managementtopics/outsourcing/story/0,10801,102677,00.html
9. Canfora, G., Cimitile, A. (2002). Software maintenance. In Handbook of Software Eng. and Knowledge Eng.
10. IEEE Std. 1219-1998 (1998). Standard for Software Maintenance. Los Alamitos, CA, USA: IEEE Computer Society Press.
11. ISO/IEC 12207 (1995). Information Technology - Software Life Cycle Processes. Geneva, Switzerland.
12. ISO/IEC 9000-3 (1991). Quality Management and Quality Assurance Standards - Part 3: Guidelines for the Application of ISO 9001 to the Development, Supply and Maintenance of Software. Geneva, Switzerland.
13. Basili, V. (1990). Viewing maintenance as reuse-oriented software development. IEEE Software, 7 (1), 19-25.
14. Lanubile, F., Visaggio, G. (1995). Iterative reengineering to compensate for quick-fix maintenance. Proceedings of the 5th International Conference on Software Maintenance, 17 (20), 140-146.
15. Abran, A., Bourque, P., Dupuis, R., Moore, J. W., and Tripp, L. L. (2004). Chapter 6 - Software Maintenance - 2004 version edition, Guide to the Software Engineering Body of Knowledge - SWEBOK. Piscataway, NJ, USA: IEEE Press.
16. ISO/IEC 14764 (2006). Software Engineering - Software Life Cycle Processes - Maintenance.
17. Hui, E., Tsang, A. (2004). Sourcing strategies of facilities management. Journal of Quality in Maintenance Engineering, 10 (2), 85-92.
18. Cannon, D., Wheeldom, D. (2007). Service Operation Itil - Version 3. Stationery Office.
19. Hoek, A., Hall, S., Heimbigner, D., Wolf,L. (1997). Software release management. In Proceedings of the Sixth European Software Engineering Conference. Heidelberg, Germany, 159-175.
20. Ruhe, G., Greer,D. (2004). Software release planning: an evolutionary and iterative approach. Information and software technology, 46 (4), 243-253.
21. Bennett, K., Rajlich,V. (2000). Software maintenance and evolution: a roadmap. Proceedings of the Conference on the Future of Software Engineering, Limerick, Ireland, 73-87.
22. Slinger, J., Ballintijn,G. , Brinkkemper,S. (2005). Release and Deployment at Planon: a Case Study. Technical Report SEN-E0504, Centrum voor Wiskunde en Informatica (CWI), Amsterdam, the Netherlands.
23. Yan, Z. (2004). Efficient Maintenance Support in Offshore Software Development: A Case Study on a Global E-Commerce Project. Proc. ICSE 3rd Int. Workshop Global Software Development. IEEE CS Press, 12-18.
13 Knowledge Management for Distributed Product Software Development
By Elia Giovaccini
Knowledge is a concept familiar to most of the readers and probably recognized as one of the main assets of the organization. However, when we turn to the Knowledge Management (KM) concept, the top management might have a different ideas on how relevant it is and how this should be implemented inside their organization. One fact that speaks on its own is that over 50 percent of Fortune 1000 companies have introduced the figure of chief-knowledge officer, who is in charge of creating infrastructures and a fertile environment for dissemination of knowledge (Rus, 2002). This last fact indicates the relevance of Knowledge Management, whereas the reality of the organizations investigated presented a diffuse underestimation of the matter. The KM concept emerged in the mid ‘80s with the aim of creating knowledge from the huge amount of information available. The academic world shortly followed, beginning research about the topic. In the last twenty years the discipline of KM has broadened covering all kinds of implications and proposing best approaches to KM applicable in the business world. According to Perry et al. (1994) developers spend a considerable amount of time on informal communication and distance is a barrier to this. Therefore, an effective approach to overcome this difficulty consists of creating a formal environment to support the communication process.
In this chapter the focus is on KM on distributed environments, with particular attention to knowledge transfer and what would be good practices to achieve performance improvements. The first section consists of a brief introduction to knowledge management, detailing the importance of it in a distributed development. Secondly the software product life cycle is presented from a knowledge management perspective on a distributed environment. In the third section trust and culture impact on knowledge transfer are analyzed. In the forth section particular attention is dedicated to the wide range of technological tools, available, to manage knowledge. Finally, the chapter concludes with two case studies, about the bright and dark sides that KM has.
13.1 Knowledge Management in Distributed Software Product Development
Knowledge management is a practice often underestimated by companies active in Distributed Product Software Development (DPSD) even if there is a shared awareness of the relevance of this matter. This chapter highlights the relevance of DPSD through a detailed insight on knowledge management with a focus on distributed development environment and providing some guidelines to drive companies to fully and safely exploit their knowledge in an offshored context. The interviews highlighted that typical knowledge related issues present onshore, are scaled up on offshore environments. Hence, with some corrective approaches valid onshore can be extended and applied on offshore environments.
Among the major issues concerning distributed environments, poor aggregation among knowledge resources (Desouza, 2006) is a relevant one, preventing easy
access and exploration of the existing organizational knowledge about processes and products. This creates, especially in distributed environments, undesired data and time overhead.
A second issue often recognizable is high people turnover (Rottman, 2008) inside the organization, which is a critical factor to be tackled in order to achieve knowledge retention and development. This aspect should be highly regarded while setting the KM strategy in order to put in place processes and systems that can limit the loss of knowledge inside the company. The academic literature presents two main categories of incentives to support knowledge retention, the first focuses on economic rewards while the second leverages the employees personal gratification. In chapter XX.X a detailed inside concerning the interventions that should be used from an HR perspective are presented.
13.1.1 Tacit Vs Explicit knowledge
Knowledge is often classified in two main forms, namely Tacit and Explicit as illustrated in Nonaka et al. (1995). Tacit knowledge refers to knowledge, which is difficult to transfer and to be articulated because of its intuitive nature and usually is absorbed through learning by doing processes. Whereas Explicit knowledge refers to the type of knowledge existing in written or symbolic form that is easily transferable using different means of communications such as documents, videos and audio format. The relevance of identifying the type of knowledge present in a DSPD environment is critical to the choice of the right knowledge management strategy.
In the software product development industry there are four main knowledge domains that are distinguishable. The source code of the software and part of the company –written- procedures are in a codified form, whereas domain knowledge, product knowledge, company culture and –unwritten- procedure of the company are more tacit and difficult to transfer.
13.1.2 Personalization Vs Codification of the knowledge
One of the most used classification concerning knowledge management strategies has been presented in the well-known article from Hansen et al. (2005). According to the authors the knowledge management can be either Personalization or Codification approach depending on the type of knowledge treated. A personalization approach focus on tacit knowledge which require people to get in contact to accomplish the knowledge transfer, whereas a codification approach mostly rely on global knowledge base where people can access documentation previously built by experts or peers. One of their main indications is that people should focus on one of the two strategies, following the Pareto model, the so-called 80/20 rule. However, Desouza (2004) presents an extension to this model in which propend for a so-called Hybrid strategy to be used in distribute software development which overcome the limitations that would accompany each of the strategy taken singularly.
The Hybrid approach presented in Desouza (2004) consists of a central repository containing common knowledge (about projects and from projects) but this also serves to trace the knowledge in projects, which are available through peers. The
main advantages deriving from this solution is to ensure maintenance on the knowledge, a higher quality of the knowledge through a ranking system, and ease of access since is globally and always available.
13.2 Knowledge Transfer Knowledge transfer (KT) is defined in Rest (2006) as “the process through which one network member is affected by the knowledge of another”. The KT happens both at the intra-organizational level and among different organizations, the latter is the main focus of this paper.
Knowledge transfer is considered a relevant challenge in organizations working on a distributed environment. According to Argote (2000) the effectiveness of knowledge transfer is recognized as basis for competitive advantage, on the base that intra-organizational transfers are more effective than inter-organizational transfer. However, the effectiveness of knowledge transfer often varies among organizations (Argote, 1999).
Knowledge transfer studies often focused on the formal mechanism, namely organizations’ internal procedures, formal knowledge bases (KB) available inside the organizations; however, this is just part of this process. A large part of knowledge transfer is often done through informal mechanisms (Ernst & Kim, 2002).
The field-interviews confirmed the diffuse organizations reliance on informal mechanism to transfer knowledge among the employees, which consists of informal meeting during social moment, such as lunch but also drinks together.
In order to achieve higher performance of KT organizations can intervene by creating opportunities for knowledge exchange or providing tools that facilitate it. During our investigation at the company NetRom, a large IT offshoring provider with headquarters in Craiova – Romania, showed to be very keen to invest on knowledge transfer, both at intra and inter –organizational level and consider knowledge management one of its winning services. NetRom supports knowledge transfer among the employees through several social moments; beginning with the possibility to have breakfast and lunch at the company canteen, during which colleagues from different departments can easily interact. Furthermore, various events are organized during the year, like company weekends where employees have the opportunity to strengthen their inter-personal relationships. At the inter-organizational level, the approach is of transparent and timely communications through face-to-face meeting every 6-weeks and a weekly conference call in which the team is confronted with the outsourcer, leveraging a set of IT tools. Next to this scheduled meetings with the outsourcing organization, there is the possibility to constantly communicate with the outsourced team through a so-called single point of contact. The single point of contact is usually the person responsible for the project, which acts as a communication hub, in order to avoid misinterpretation that might arise when dealing with different persons every time. A typical example of project knowledge transfer activities, for a medium scale project, at NetRom is depicted in figure 1.
Figure 16 - NetRom approach to a successful project knowledge transfer
Academics also directed their attention at issues concerning Intellectual Property (IP) as a main form of protection of the software source code. Issues about IP revealed to be of great concern among companies approaching offshore projects, these are namely the spill-over and appropriation of knowledge by the outsourced organization. However, the general feeling collected through the interviews is that in the software development field the use of the existing legal instruments and the common care used to preserve the leakage are often recognized as sufficient to the software protection.
13.3 Knowledge Management in the Software development process Knowledge Management differs among the various phases of the development process, constrained by the type of knowledge involved and the geographical distribution of the employees. In this paragraph will be analyzed in detail, for each phase of the software development, the Knowledge commonly created and used, as well as the practices typical of each phase.
13.3.1 Domain Knowledge
Domain knowledge refers to the type of knowledge specifically used in a certain field and country which is hardly part of the developer’s background. For
example a group of Romanian developers involved in a project concerning a Dutch housing providers may need knowledge on housing regulations to fully comply with it. This knowledge is required in order to better involve the developer and leverage his/her skills to produce a sound and efficient solution. This knowledge usually is transferred to the recipient through specific trainings, reading of material and in case of long collaboration even language courses are offered to the employees.
13.3.2 Requirements
In this phase the outsourcing party has to formalize, usually on a written form, the requirements for the software product; this is usually done onshore. In chapter XX a wide overview on requirements in distributed environment is presented. However, is important to stress the use of a common language and also the existence of some basic common domain knowledge to avoid misinterpretations. A common practice among the companies has been recognized to be that after having completed the requirements the organization onshore hosts the development team for some times, usually 2 to 3 weeks. During this timeframe the team gets acquainted with the onshore team, the knowledge domain of the project and starts a preliminary discussion on the requirements.
13.3.3 Design
The design phase usually is quite knowledge intensive activity, requires the component of the team to be in control of the knowledge domain of the project. This results in spending a large amount of time, around 75 percent accordingly to Walz et Al. (1993) on a learning process. The design is usually done onshore for the projects where only the implementation part is sourced, whereas organizations, which have the entire project outsourced usually, do the design directly in the offshore location. During this phase the informal meeting among team members proved to be really effective in order to achieve a higher level of knowledge exchange.
13.3.4 Implementation
The implementation phase is usually concentrated on the offshore site, where the actual coding is executed. During this phase the knowledge produced is mainly on the form of source code of the software, usually properly commented, following organization wide guidelines. In some organization the coding might be execute in multiple locations, therefore a set of procedure for code merging or concurrent development needs to be implemented. The main challenge from a Knowledge management perspective is to keep consistency among the versions and guarantee availability from any location.
13.3.5 Testing
The Knowledge management during the testing phase is mainly concerned with the need of information by the testers from the coders (Oshri, 2008), which can be either located onshore or offshore. Hence, there is need for traceability of the code to the right coders. Most of the source code repository tools now available allows to precisely link a programmer to a certain portion of the code, however
it’s of vital importance to have the system available and accessible for every member of the coding and testing teams.
13.3.6 Deployment
Once reached this phase of the product software development cycle there should be available user manuals, containing the explicit knowledge concerning the product, as well as guidelines for a correct deployment and training material to instruct the various type of users. This phase is rigorously planned in advance and requires meetings in which the team offshore clarifies the details that are not available to the onshore team about the software product.
13.3.7 Maintenance
The maintenance from a knowledge perspective is highly demanding, because it relays on the existing knowledge concerning the product, which needs to be present inside the organization; moreover, the process in itself requires knowledge transfer between different locations. Usually the maintenance phase involves the handling of tickets, generated by customers’ report of problems or requests for new features. The challenge is to assure that the knowledge concerning the tickets is correctly handled and available throughout the maintenance phase. Therefore, there is a need for appropriate software processes in place as well as tools.
13.4 How to successfully transfer knowledge to an offshore location Organizations do not always start a project from the beginning in the location offshore; instead, they transfer an existing project. Therefore, in order to achieve a successful knowledge transfer the organization needs to follow a number of steps. These steps consist of specifically designed processes supported by incentives plan for the personnel.
Transfer the knowledge concerning a project from one location to an one offshore requires a plan, which will have different requirements in terms of time and steps depending at which stage the product is in its lifecycle. In table 1 the collection of steps is presented that should be followed in order to successfully transfer the knowledge of an existing project. The steps derive from the best experiences collected during the interviews sessions.
Table 11 - Knowledge Transfer of an existing project: steps for a successful outcome.
Table 1 summarizes in six steps the activities and type of knowledge involved in transferring knowledge, about an existing project from one location to another. In first instance the organization needs to assess its current situation concerning existing relevant knowledge and expertise. Secondly, a technological assessment and planning is required, in order to implement tools supporting the knowledge preservation and update over the distance. After these preparatory phases, the team offshore involved in the actual project is transferred to the organization
Step Transfer an existing project
1 Activity: Assess the existing relevant knowledge and expertise needed at the outsourced location and create a transition plan.
2 Activity: Implementation of technological solutions to support the project knowledge.
3 Activity: The team from the offshore location is transferred to the company headquarter.
Knowledge transferred:
Domain Knowledge,
Project Knowledge,
Team Members (Who knows what?).
4 Activity: The team returns to the offshore location together with a one or more key‐ project leaders from the onshore site, who will stay for 6 months up to 1 year.
Knowledge transferred:
Project Knowledge (mostly Tacit)
5 Activity: Training the personnel on both sides to regularly use the available tools for knowledge exchange.
Knowledge transferred:
Project Knowledge
6 Activity: Regular meeting between the outsourcer and the outsourced team, at both the site.
Knowledge transferred:
Project Knowledge
headquarter for an intensive knowledge transfer concerning many aspects of the project, ranging from domain knowledge to –who knows what- knowledge. When the latter phase it’s completed, usually lasting between two and three weeks, the team moves back to the offshore location together with one or more key-project leader(s) from the headquarters. The project leader(s) will accompany the outsourcing launch period, providing support to the new team as well as transferring a large part of the tacit knowledge inherent the project. In order to maintain the knowledge between the two locations updated and foster the knowledge transfer, the personnel is trained and stimulated to use the tools in place. The last step consists of a continuous process repeated overtime aiming to maintain updated the onshore and offshore parties concerning the project knowledge.
13.5 How culture and trust matters in knowledge transfer Culture and trust are topics widely covered in the literature in relation with Knowledge Management and Transfer. According to the model of Lee et Al. (2008), the success of an offshore initiative is significantly related to the level of knowledge transfer. The model assessed the existence of a key factor, mutual trust between the two parties involved, which directly influences the level of knowledge transfer. Therefore, in order to achieve valuable result out of an offshore initiative there is a need to have a high initial trust, especially from the offshore part. Otherwise, the knowledge transfer would be limited and since most of the value creation lies on knowledge sharing there would be less reason to begin an offshore initiative.
There are various aspects of Culture to be taken in account that can directly affect a positive knowledge transfer. National culture is one of them, is part of every society and is characterized by a strong persistency. One of the most known models on cultural orientation is Hofstede’s (1983) four dimensions of cultural distance. The model presents four dimensions that typically characterize a culture namely individualism versus collectivism, power versus distance, uncertainty versus avoidance, and masculinity versus femininity. However, this chapter will not dive on this part but focus on the cultural challenges that can be encountered in running a distributed software product development.
Carmel & Tjia (2006) point out that the software world is less affected by cultural problem compared to other offshored businesses. One of the main reasons has to be researched on the software engineers’ common professional culture, the so-called computer subculture, which is globally shared. However even if this sub-culture is highly shared, the national culture still dominant on aspects such as deep values and beliefs. Desouza et al. (2006) suggest to tackle the diversity characterizing each culture, with a gradual approach, which proved to be more effective compared to an imposed unified culture.
During the interviews, culture and trust have been mentioned as of concern from the beginning of the offshore initiative, however it emerged that a large part of the respondent did not suffer such a strong impact as would have been expected. This could be indicator of shorter culture distance between Western Europe and Central Europe compared to the Asiatic one, which have been subject to more frequent studies. Furthermore, a large part of the companies interviewed expressed high satisfaction about their existing relationship with the organizations
offshore, especially concerning the personnel, who usually demonstrated a high commitment towards the task assigned. Commitments, implies proactive participation in the software development as well as dedication to the tasks assigned.
13.6 KM Tools Organizations nowadays have to deal with a large amount of knowledge of many different types as previously mentioned in section 2, therefore the real implementation of a Knowledge Management strategy also require the support of technological tools (Lindval et al., 2003). Technology allows to easily store, retrieve, search and categorize knowledge, without overlooking a fundamental feature for companies with multiple locations that is the possibility to share knowledge through the distance.
The knowledge items can present themselves in various formats, from audio files to videos as well as written documents up to pictures. From here the necessity to identify the solution that best fit the specific organization’s knowledge.
Lawton (2001) illustrates the technologies that should support the various type of knowledge as presented in figure 2. Lindvall et al. (2003) list the technologies useful to support KM, namely “authoring, indexing, classifying, storing, contextualizing and retrieving information, as well as for collaboration and application of knowledge.”
Figure 17 - KM Architecture Model: adapted from Lindvall et al. (2003)
The existence of a wide number of technologies require a more in depth analysis, therefore the most common solutions available on the market are presented categorized by type of knowledge supported. The information reported below has
been retrieved partly from the work of Lindvall et al. (2003), the tools producing companies’ websites as well through the interviews.
13.6.1 Document and content management
In knowledge management documents represent a large portion of the explicit knowledge belonging to an organization. Documents serve to create new knowledge as well as to reuse successful solutions described in it. Furthermore, these systems might be seen as very useful to identify tacit knowledge, because of the possibility to track the experts on specific fields based on the number of publication an author have written concerning a certain topic.
One of the basic features of documents management system is to provide high availability and easiness of access from every location. Moreover, in a distributed environment it is of critical importance to easily identify the document version. Therefore, these are the least features needed on a document and content management system.
An example of this kind of tool is Microsoft SharePoint, which is available in two versions depending on the number of users supported. Several of the interviewed companies implement this tool to manage documents in their organization.
Hippo CDM (Compound Document Management) is an open source document management focused on supporting technical documentation, namely manuals, guidelines and specifications, procedures, instructions and interactive electronic technical documentation. This product allows having a centralized technical documentations repository, easily accessible from everywhere concurrently by different users; characteristics which drove Levi9 to adopt it.
13.6.2 Collaboration services
In distributed environment one of the major needs is the communication among the different offices, which are often located far from each other and on different time zone. The knowledge usually exchanged through this type of tools is tacit. These tools can be simple instant messaging (IM) software or a very sophisticated video-audio environment with shared workspace that allows the parties involved in the project to have a fully featured virtual meeting.
The functionality required to this category of tools is to support a computer based communications. In the software industry, organizations that have offshore activities use tools that allow concurrent co-authoring of documents over the distance. One of these products is Groupsystems, which offers same-time, same-place meetings capability.
13.6.3 Expert Networks
Expert networks are those technologies enabling people to easily get in contact and locate expertise in a geographically distributed organization. A typical tool is a forum where people inquire the community to find solutions to a problem.
Expert networks represent one of the types of software tools that support tacit knowledge transfer, “acknowledging that most knowledge cannot be made
explicit and stored in a computer, but will reside in the brains of experts” (Lindvall et al., 2003).
13.6.4 Knowledge Portals
Inside the large majority of the organizations the personnel have to operate with different software, managing an equal amount of different knowledge (inventory levels, customers orders, sales results, financial data). A solution to integrate all this information and knowledge using a single gateway is to implement a so-called knowledge portal that allows employees to access them through one common interface.
One of the features commonly available on these tools is the possibility for the organization to filter the content visible in the system based on the role of the user.
13.6.5 Customer Relationship Management Tools
Customer relationship management (CRM) tools are probably one of the most known product on business environments. CRM software represents a widely used tool to store knowledge concerning the relationship between an organization and its customers.
CRM products are available in two main forms, usually integrated, that provide the customer with self-support tools, typically using online services and on a second form used from the help-desk personnel to support the customers.
CRM have a great potential to store reusable knowledge, coming from recurrent common questions arising from the customers. This knowledge if leveraged properly can be very useful for new personnel, who may lack enough experience about the company processes and product, as well for the current personnel looking for problem solutions.
Support through self-help is becoming a necessity to solve recurrent problems and allows the customers to be always updated on the status of their inquiries or about the ordered product. The service is provided through a website, which often support live chat with personnel from the help-desk or software systems capable of answering frequently asked questions (FAQ).
The products available on the market space from fully integrated suites of products to single product dealing with a single aspects of a CRM. Among the suite, Siebel offers a product that supports sales and marketing, call-center and services, the partner relationship, and employee relationship management.
13.6.6 Competence management
Competence management is part of the category of tools created to deal with tacit knowledge assets. Organizations need to create and continuously update knowledge maps, which serves to easily locate people who have the right knowledge and leverage it.
This is even more significant for large organizations and especially operating in different locations because people often don’t know each other.
The knowledge managed by the system, is explicit since it contains the knowledge mapped to the employees. This allows the company to quickly and effectively have a list of knowledge present inside the company and who posses it.
13.6.7 Product Management
In the software industry the product is itself knowledge, hence there is need to manage and store it extremely carefully. Consequently, this necessity created a large market for software products that allows managing the software through its lifecycle, spacing from open source solutions to commercial one.
TestLink is an open source solution that allows the creation and management of test cases as well as an overall planning. The major features of this tool are the test tracking together with a reporting tool for them.
WiKis are also largely used inside software houses with the most different scopes. At some of the company part of the survey it’s used as a repository for all the project documentation beside the source-code, whereas at Levi9, it is used to manage users’ stories.
JIRA is a tool widely used among the companies interviewed in order to track bugs and issues. Here the organization usually gather all the knowledge concerning the matter and allows the customer to monitor the bug fixing. Furthermore, this tool creates report and statistics in order to monitor the issues.
13.6.8 Source code repository
A source code repository is a place where the source code of software product is stored and shared among different development teams. The system can be available intra-organization or inter-organization. Among the main features there are the code classification, the authorship and most important the code versioning.
CVS is one of the most known tools for code repository, which is a new GNU project, often used in the open source community. However, this product has now been gradually replaced by SVN, which is still an Open Source product.
Next to these various solutions that are often strictly targeted to a specific type of knowledge, the market offer solutions that cover all the company functions as well the knowledge generated there. One of these products is E-Synergy of Exact Software, which is presented in section 6.
13.7 Case Study: E-synergy at Exact Software – state of the art of a Software Knowledge Base (SKB)
The case of Exact Software (ES) presents a state of the art knowledge supporting tool implementation.
ES is a Dutch company active in the market of enterprise resource planning (ERP) software with an established international customer base of over 160000 customers. Since its foundation the company has been growing steadily from 5 employees in 1984 to 2750 people nowadays, this required during the last 10 years to look at offshore locations for highly qualified people due to a systematic shortage in the home country, the Netherlands. At the moment the largest offshored location of operation is Kuala Lampur (Malaysia).
The company back in 1998 was utilizing isolated systems to support the various processes and knowledge sharing through the company. However, ES was far from an optimal situation, experiencing various problems within each single system. The most frequent problem encountered was the duplication of entries inside the different systems, resulting on frequent data inconsistencies. A second frequent problem at ES was the management of deliverables, which was not done explicitly resulting in delaying project deadlines and producing incomplete deliverables. A third problem was the need to have worldwide concurrent access to the software repositories systems 24 hours a day. Last issue originated by the global presence of offices all around the globe, which proved to require higher visibility of the information and knowledge available through the all company. All these issues dramatically impacted the company business performance and effectiveness. ES found a solution, introducing its own Web-based product called E-Synergy.
E-Synergy is a front-office application that provides organizations wide with financial information, multi-site reporting, and relationship and knowledge management capabilities. Figure 3 depicts the interfaces of access to the system, as well as the seven modules that compose the software. E-Synergy is based on the One-X strategy, which aims to provide one single data source for all the ES products, realizing a tight integration among the various products and ensuring consistency of the data. The PDM module manages the conventional products, the CRM module stores information about customers, while project, workflow modules provides a subdivision of the work among the employees.
E-Synergy was concurrently introduced at Exact while released on the market, and thanks to a careful planning of the migration from the old system this required just couple of weeks to be fully operative. After a slight initial resistance of the users, the quickly became accustomed to the new system. The successful implementation of the system derived from a really strong support from all the management team, in particular the CEO, that even introduced a catch-phrase, which clearly synthesize the approach of Exact, that was: “If it is not on E-Synergy, it doesn’t exists.” Remarkable was the reaction of one of the employees at ES, just after couple of months after the implementation, who said:
“We would never like to go back to the previous situation, this system is much better.”
The benefit achieved by ES using E-Synergy includes an improved time to market, since all the requirements and information needed are easily accessible to all personnel at any time from any location of the company, speeding up the development process. Furthermore, all the stakeholders involved can easily monitor the progresses of the projects.
Figure 18 - Abstract Architecture of E-Synergy
The availability of a centralized SKB through which all the knowledge of the company is routed allows them to share company-wide the employees’ knowledge and easily locate it inside the company, using a tool called Expertise search. Furthermore, it allows to consistently and effectively run a distributed company since the updated knowledge is constantly and continuously available.
The effectiveness of E-Synergy is supported by a long track record of employees that left Exact and lately have been promoting the introduction of ES in their new working environment, aware of the valued added deriving from its implementation.
13.8 Case study: Acision experience with a troublesome project transfer. The case study about Acision presents how poor Knowledge Management can impact on the service offered by a company, who is a leader in its market. Acision is the world’s leading messaging company, providing solutions for mobile phones operators. Currently serving 300 customers throughout the world, across all the 6 continents. The company is also active on the business of mobile Internet browsing, as well as in charging solutions for prepaid services.
Acision –at that time Logica CMG - faced major difficulties, when the Internet bubble burst in 2000. The company had to quickly restructure itself, closing down offices and relocate people to survive at the growing crisis at that time. However
the situation could have been simplified and smoothed by the existence of a KM in place, with defined procedures and some IT tools supporting the process.
Acision pushed from the strong pressure rising from the markets, was in extreme urgency to cut costs and rationalize its activities, and the management had the opportunity to sell one of the offices with the only constraint to do it immediately. This resulted in the decision to transfer all the products to a different office, however without holding the person acknowledged about the product, due to lack of a formal knowledge mapping that could have helped the process of selection. The project was transferred without any plan leaving the new team without any reference and guidance. This had further consequences affecting at last Acision customers, who experienced delays on product support and caused a partial loss of trust from some customers. Here the existence of KM inside the company could have clearly supported the migration process, lowering the issues for the company and minimizing the repercussion on the company’s customer.
Since then Acision started to invest in KM and disseminate the culture of knowledge sharing inside the company.
13.9 Conclusion In this chapter Knowledge Management has been defined and investigated to the extent it’s strategically relevant in distributed product software development. The life-cycle phases of product software have been widely covered, highlighting the knowledge involved in each phase and the most common transfer means used. A best-method aiming to effectively transfer knowledge about an existing project is proposed, based on the most common and successful experiences from the interviews at the companies. Then an in-depth investigation of the supporting tools available for knowledge management in a distributed product software environment is presented. The validity of the knowledge transfer issues is augmented through two cases studies reporting the positive and negative implication deriving from a good and a poor implementation of Knowledge Strategies.
Concluding, the chapter highlights the peculiarity of software development, as a knowledge intensive activity. This call for the need of having a formal KM in place inside the company, in order to effectively exploit and preserve knowledge, especially in distributed environment where distance can be a great barrier to knowledge transfer, if not properly managed. Since, knowledge is a critical assets for the organization, its proper management enables the organization to be more agile, improving its responsiveness to mutated market conditions. Therefore, organizations should acknowledge KM importance, with investments and not the most widely diffuse cost cutting strategy.
Concluding lessons
o A KM allows the company to be more reactive to change inside and outside the organization.
o Knowledge is one of the most important assets of the organization, therefore its strategic management can be of enormous value added to the company performance.
o Knowledge Management in distributed environment is a key element for the success of a project.
o Knowledge Management allows leveraging and reusing the knowledge existent inside the organization.
13.10 Literature Argote, L. (1999). Organizational Learning. Creating, Retaining and Transferring Knowledge. Norwell, MA: Kluwer Academic Publishers.
Argote, L. (2002). Organizational Learning: Creating, Retaining and Transferring Knowledge. Boston: Kluwer Academic.
Carmel, E., & Tjia, P. (2006). Offshoring Information Technology - Sourcing and Outsourcing to a Global Workforce. Cambridge: Cambridge University Press.
Desouza, K. C., & Evaristo, J. R. (2004). Managing knowledge in distributed projects. Communications of the ACM, 47(4), 87-91.
Desouza, K.C., Awazu, Y., & Baloh, P. (2006). Managing Knowledge in Global Software Development Efforts: Issues and Practices. IEEE Software, 23(5), 30-37.
Ernst, D. & Kim, L. (2002). Global production networks, knowledge diffusion, and local capability formation. Research Policy, 31, 1417–1429.
Hansen, M. T., Nohria, N., & Tierney, T. (2005). What‘s Your Strategy For Managing Knowledge? Knowledge Management, 77(2), 106-116.
Hofstede, G. (1983). National Cultures in Four Dimensions: A Research-based Theory of Cultural Differences Among Nations. International Studies of Management and Organization, 8, 46-74.
Herbsleb, J.D., & Mockus, A. (2003). An Empirical Study of Speed and Communication in Globally Distributed Software Development. IEEE Trans. Software Eng. 29(6), 481-494.
Lee, J.N., Huynh, M.Q., & Hirschheim, R. (2008). An integrative model of trust on IT outsourcing: Examining a bilateral perspective. Information Systems Frontiers, 10(2), 145-163.
Lawton, G. (2001). Knowledge management: ready for prime time?. IEEE Computer, 34 (2), 12-14.
Lindvall, M., Rus, I., & Sinha, S.S. (2003). Software systems support for knowledge management. Journal of Knowledge Management, 7 (5), 137-150.
Nonaka, I. & Takeuchi, H. (1995). The Knowledge Creating Company. Oxford: Oxford University Press.
Oshri, I., van Fenema, P., & Kotlarsky, J. (2008). Knowledge transfer in Globally Distributed Teams: The Role of Transactive Memory. Information Systems Journal, 23 (1-2).
Jansen, S., Ballintijn, G., Brinkkemper, S., & Nieuwland, A. (2006). Integrated development and maintenance for the release, delivery, deployment, and customization of product software: a case study in mass-market ERP software. Journal of software maintenance and evolution: research and practice, 18, 133–151.
Perry, D. E., Staudenmayer, N.A., & Votta, L. G. (1994). People, Organizations, and Process Improvement. IEEE Software, 11(4), 36-45.
Rest, E. van (2006). Decision-Making in Offshoring from a Knowledge Perspective; Illuminating a blind spot. (Master dissertation, Technical University of Eindhoven, 2006). Retrieved from http://www.platformoutsourcing.nl/artikelen/index.php?act=dwnl&id=95
Rottman, J.W. (2008). Successful Knowledge Transfer Within Offshore Supplier Networks: A Case Study Exploring Social Capital In Strategic Alliances. Journal of Information Technology, 23, 31–43.
Rus, I., & Lindvall, M. (2002). Guest Editors' Introduction: Knowledge Management in Software Engineering. IEEE Software, 19(3), 26-38.
Walz, D.B., Elam, J.J. & Curtis B. (1993). Inside a software design team: knowledge acquisition, sharing, and integration. Communication of the ACM, 36(10), 63-77.
14 Managing People in a Distributed Development By Ed’son de Pary
The interest for offshore is growing. The number of organizations distributing their software development processes worldwide aiming at heightened profit and productivity as well as cost reduction and quality improvements keeps increasing. A large number of western firms are conducting IT-activities in countries such as India, Russia, China and many other East European countries. Because the number of books on this topic is limited, some books like that of Erran Carmel and Paul Tjia (Carmel E. et al., 2005) and some few other authors shade some light into some innotive clues to carryout a successful offshore project.
The decision to source software development to firms in low-cost countries is looked at frequently in simple economic terms: it is cheaper, and skilled labour is easier to find. In practice, however, offshoring is loaded with difficulties. As well as the considerable challenge of controlling projects at a distance, there are differences in culture, language, business models, politics, and many other issues to contend with (Carmel E. et al., 2005).
In his Harvard Business Review article "IT Doesn't Matter", Nicholas Carr (2003) stoked a debate on the idea that IT has become a commodity: That IT has evolved to the point where it can be viewed as a cost centre to be controlled instead of an investment centre to provide market leadership (Carr, N., 2003). If an element of IT proves to be a true cost centre, and not a competitive advantage, then a logical approach is to find an outsourcer who specializes in that business and profit from economies of scale. The company can then save money through outsourcing and focus energy and invested capital on areas that are of strategic advantage.
Determining which areas of IT to outsource then becomes critical. As many firms have discovered, the benefits of getting offshoring right are too great to ignore (Porter, 1980). However, the decision to outsource may not be that simple.
This chapter however contends that software technology and offshoring is not as black and white as Carr suggested. The goal here is not to suggest the existence of the solution, but rather to propose some choices or best practices which managers might want use when faced with tough strategic decisions concerning the offshoring of software development This chapter further explains everything needed to know to put offshoring into practice, avoid pitfalls and develop effective working relationships. It covers a comprehensive range of important offshoring issues: from cost advantages to strategy, from service levels to cultural differences, from country comparisons to the marketing of offshore services.
Laying the foundation will kick off this chapter, followed by change management and offshore governance to conclude this part of the chapter.
14.1 Laying the foundation Once the decision of what areas of your organization are candidates for and the type of outsourcing that best suits your business goals is made, the first step of building that client-vendor relationship is the contract. As the basis of any
outsourcing arrangement, the contract is going to play a central role in relationship to come between client and service provider. While the contract will always remain just a piece of paper that in and of itself will not get the work done, insure against failure or guarantee success, it will define how the client is going to work with the external service provider. The contract will provide the guidelines, stepping stones and structure that people will use to make the relationship work (Kern, 1997).
However, the contract is only the beginning. The importance and spirit of the outsourcing arrangement must filter down to the employees in the channels performing the day-to-day work.
As often happens at the beginning of an offshore arrangement, a great deal of tension may loom over the organization. Employees might feel that their jobs are at risk because of an outsourced project, and rightly so. Associates may have been laid off or their jobs transferred to the vendor as part of an offshore arrangement. Employees’ who formerly worked side-by-side under the same management and rules, might now still work together, but report to entirely separate management hierarchies. Associates may also be charged with working with others across geographic regions or languages. Because of this, jealously, competition and bitterness are only some of the emotional barriers that may provide obstacles to the harmony sought between client and vendor.
Williamson (1979) believes that individuals also have only a limited capacity to process and store information, and as such, can, and do, choose what information to share with others in what he terms as “opportunistic”, or self-interest-seeking behaviour. Further, Emerson (1972) suggests that “in economic theory, decisions are made by actors not in response to, or in anticipation of, the decision of another party but in response to environmental parameters.” Given that a new offshore relationship may be cause for concern among staff, be seen as unwanted, or even traumatic, organizations should keep in mind that the contract alone cannot guarantee a successful relationship between its employees and the vendors.
Because of the inherent tension in a new offshoring relationship, one of the challenges that every organization seeking to incorporate offshore into its business strategy is to do so in such a way that fosters an atmosphere where individuals are encouraged to get beyond simply following the letter of the contract and exchanging information on a limited or required basis and move to acting in the spirit of the contract and to a place of voluntary exchange of information (Hakansson, 1982).
Finally, one of the most dangerous aspects of an offshore contract and what often leads to the most conflict between outsourcer and vendor is what happens when things don’t go as planned; Since we all lack the ability to see into the future, how uncertainty is dealt with in the contract, or the inevitable incompleteness of the contract, can have a significant impact on an offshore arrangement. It was also identified by Nam (2003) as an issue as important to deciding whether or not to outsource as the IT organizational context and processes that are to be outsourced themselves (Nam, 2003).
14.2 Change management Organizational change management is the process of developing a planned approach to change in an organization (Wikipedia.org, 2008). An effective Change Management program maximizes performance at implementation by minimizing disruption and accelerating the acceptance of change. The discipline of change management deals primarily with the human aspect of change, and is therefore related to pure and industrial psychology. Treating change management as a process, we can characterize it in phases (Figure 1).
Figure 19: change management (Massachusetts, 2004)
-Phase 1: Endings (contact to awareness):
Every transition begins with an ending, a loss. When things change, people leave behind the way things were, and the way they were in the previous situation. They may be left searching for a new way to define themselves.
-Phase 2: The Neutral Zone (awareness to understanding)
The neutral zone is a confusing in-between state, where people are no longer who and where they were, but are not yet who and where they're going to be. Although the neutral zone can be distressing, it also provides many opportunities for creative transformation. During this phase, the design and implementation of the project are somehow clarified.
-Phase 3: New Beginning (acceptance to various adoptions):
A new beginning can only happen after people have let go of the past and spent some time in the neutral zone. In this phase, people accept the reality of the change and start to identify with their new situation. In this phase, the results of the change management are implemented and with the only concern at this point being to improve the acceptance level of the people concern by the change.
In most cases, change management is characterized by the FUD (Fear – Uncertainty – Doubt) concept (Giffin, G. 2006). This concept can in most cases
be countered by a well oiled strategy which is characterized by the following issues:
• Acknowledge that not everything is known or decided.
• If you don’t have the answer to the question, know how and when you will.
• Know how everyone will be involved in the process of creating certainty.
• Have a solid plan and demonstrate that you are following it to build confidence.
• Counter balance FUD with visible competent leadership.
• Some key elements that leads to change management success
• Enable and sustain transformation
• Build trust, provide encouragement
• Provide participatory involvement, develop buy-ins
• Engage staff in dialogues - be responsive to questions and concerns
• Model positive behaviour
• Over-communicate
14.3 Governance Executive sponsorship of offshoring initiatives is a key to successful development, delivery and deployment of projects and programs. Offshoring is strategically important and challenging, and requires strong governance. Most firms establish a steering committee from the very beginning to oversee initial deployment and on-going operations (Gentle, C. 2004).
The key dimensions of offshoring governance include:
• Definition of a Service Level Agreement: This could be between an offshore and onsite team, or the client and the vendor.
• Program Management: This could include establishing a formal offshoring Program management office
• Transition Management: Includes strategies and tactics for transitioning an organization towards becoming a strong offshoring player.
14.4 The Offshore Transition
Figure 20: Offshore Transition model (Mohan, K. 2006)
The offshore transition includes strategies and tactics for transitioning an organization towards becoming a strong offshoring player. Transition is also often the first stage wherein project bottlenecks and problems are experienced and resolved. The performance and stability of any offshore outsourcing engagement is often dependent on how well the transition is managed. The transition period is perhaps the most difficult stage of an offshore project, taking anywhere from three months to a year to complete.
Transition management is defined as the detailed, desk-level knowledge transfer and documentation of all relevant tasks, technologies, workflows, and functions. The major activities in this stage are knowledge transfer and ensuring a working project wide technical infrastructure. The objective of this stage is to make sure that the offshore provider is able to continue the project successfully offshore.
In order to acquire necessary project knowledge (e.g. domain, business-process, tool, or environment knowledge), offshore personnel may have to be trained by the customer. For this purpose, employees of the offshore provider visit the customer's organization on-site in many cases, collecting information and knowledge that they take home to disseminate among their colleagues in the project.
14.5 People Management An organization has real incentives to keep their own human resources happy and appreciated. Low morale has an adverse effect on productivity and the overall success of an organization. If employees start to suspect that their jobs are in real danger of being replaced that could lead to productivity losses, resentment
and rebellion. Employees who worry about their job stability would not be able to direct all their attention to their work load. Also, it is in the best interest of an organization not to lose those people who are some of the organization’s greatest assets because they feel their jobs are insecure. Also, there could be real problems if there is companywide resentment and rebellion as a result of an offshore project. To avoid these problems an organization must communicate effectively with their employees.
Field and Keller (1998) identify people management as “the most important element of project management” and further state that project management is about “working with people. It is people who get things done, not objectives, not plans, not machines and not schedules, though all of these are important” (Field, M. et al, 1998).
Turner (1999) states that for managers to be able to deliver a project successfully they must be able to manage the project team and the individuals within that team (Turner, 1999). People management is a process and should be studied like any other processes.
Employee recruitment is crucial, people are one of the most important resources for organizations (40-60% of costs), No personnel process is more important than the employee selection process; If you hire the wrong people, you may never be able to recover.
Motivation is one of the key elements of this key process. Make sure to control the work and not the workers, always explain the purpose of orders, design the job to be done, people are no robots, install a two-way communication process, encourage a career development process and stable employment.
Self-directed work teams can sometimes be crucial to the success of a project. Highly trained group of employees who are fully responsible for producing a set of work products.
14.6 Organization behaviour The roots of studies in organization behaviour can be traced back to work done in the late 19th and early 20th century by Frederick Taylor (Roethlisberger,F.J. et al, 1939). Taylor attempted to analyse the most productive way of doing manual tasks. The workers were then trained to do the workin that way. Taylor had three basic objectives:
To select the best person for the job, to instruct them in the best method and to give incentives in the form of higher wages to the best workers. Taylorism is often represented as crude and mechanistic. However, a concern for identifying best practice is valid. In the world of software development, the growth of structured methods is an example of an emphasis on best practice.
14.6.1 Selecting the right person for the job
Many factors such as the use of software tools and methodologies, affect programming productivity. However, one of the biggest differences in software development performance is between individuals. Looking for the best people for an offshore job, project managers might face some tough choices: is an experience
programmer better than a new graduate? It is dangerous to generalize but looking at behavioural characteristics? The American researcher Cheney (1984) found that the most influence on programmer productivity seemed to be experience, mathematical aptitude seemed to have a weak influence in comparison.
A project manager will want staff which can communicate well with each other and with those in their external working environment. Unfornutanatly, the American researchers Couger and Zawacki (1979) found that information system (IS) professionals seemed to have much weaker ‘social needs’ than people in other professions. They quote Gerald Weinberg: “ if ask, most programmers probably say they prefer to work alone where they wouldn’t be disturbed by other people.” We see many who are attracted to writing software, and are good at it, but do not make good managers later in their careers.
14.6.2 The recruitment process
Project leaders often have little choices about the people who will make up their team in an offshore project; they often have to do with material that is at hand. Recruitment is mostly an organizational responsibility; the person recruited might over a period of time work in many different parts of the organization, it doesn’t matter whether the job is offshore, nearshore or an onsite job. However, for offshore projects some emphases must be taken more seriously than in other jobs.
Meredith Belbin (1981) usefully distinguish between eligible and suitable candidates. Eligible candidates have a Curriculum Vitea (CV) which shows, for example, the right number of years in some previous post and and the right paper qualifications.
Suitable candidate however, can actually do the job well. A mistake is to select an eligible candidate who is not in fact suitable. Suitable candidates who are not officially eligible can, on the other hand, be ideal candidates as once in post they are more likely to remain loyal. Belbin suggests we should try to assess actual skills rather than past experience and provide training to make good minor gaps in expertise. It seems that policies that avoid discrimination on the grounds of race, gender, age or irrelevant disabilities can be not just socially responsible, but also a shrew recruitement strategy.
14.7 Recruitment process case study 1 This case study is taken from the book of Ian Sommerville (2006). In his book, Sommerville isllustrates the proces of selecting people for a specific offshore project.
Alice is a software project manager working in a company that develops alarm systems. This company wishes to enter the growing market of assistive technology to help elderly and disabled people live independently. Alice has been asked to lead a team of 6 developers than can develop new products based around the company’s alarm technology. Her first role is to select team members either from software engineers already in the company or from outside. To help select a team, Alice first assesses the skills that she will need: These are:
• Experience with existing alarm technology as it is reused
• User interface design experience because the users are untrained and may be disabled and hence need facilities such as variable font sizes, etc.
• Ideally, someone who has experience of designing assistive technology systems. Otherwise, someone with experience of interfacing to hardware units as all systems being developed involve some hardware control.
• General purpose development skills.
The next stage is to try and find people from within the company with the necessary skills. However, the company has expanded significantly and has few staff available. The best that Alice can negotiate is to have help from an alarm expert (Fred) for 2 days/week. She therefore decides to advertise for new project staff, listing the attributes that she’d like:
• Programming experience in C. She has decided to develop all the assistive technology control software in C.
• Experience in user interface design. A UI designer is essential but there may not be a need for a full-time appointment.
• Experience in hardware interfacing with C and using remote development systems. All the devices used have complex hardware interfaces.
• Experience of working with hardware engineers. At times, it will be necessary to build completely new hardware.
• A sympathetic personality so that they can relate to and work with elderly people who are providing requirements for and are testing the system.
This case study illustrates some key points and difficulties project and team leaders come across when trying to recruit or manage their human resource. Managers in companies might not find it funny to lose people to new projects far away, part-time involvement might be inevitable. Skills such as User Interface design and hardware interfacing are in short supply.
Recent graduates may not have specific skills but may be a way of introducing new skills. Technical proficiency may be less important than social skills. However, to standardize and facilitate the task to the team leader, the following as to be prepared:
Create a job specification - Advice is often needed as there could be legal implications in an official document. However, formally or informally, the requirements of the job should be documented and agreed.
Create a job holder profile - The job specification is used to construct a profile of the person needed to carry out the job. The qualities, qualifications, education and experience required would be listed.
Obtain applicants - Typically, an advertisement would be placed, either within the organization or outside in the local paper or on the Internet. The job holder profile would be examined carefully to identify the medium most likely to reach the largest number of potential applicants at least cost. For example, if a specialist
is needed it would make sense to advertise in the relevant specialist journal or forum. The other principle is to give enough information in the advertisement to allow an element of self-elimination; by giving the salaries, location, job scope and any essential qualifications, the applicants will be limited to the more realistic candidates.
Examine CVs - These should be read carefully and compared to the job holder profile. Nothing is more annoying for all concerned than when people have CV’s which indicates clearly they are not eligible for the job and yet are called for interview.
Interviews - Selection techniques include aptitude tests, personality tests, and the examination of samples of previous work. Any method most test specific qualities detailed in job holder profile. Interviews are the most commonly method. It’s better to make multiple interviews with the applicant, with each of them carried out by not more than two interviewers, because a great number reduces the possibility of follow-up questions and discussion.
14.7.1 Instruction and members introduction best practices
When new members of the team are recruited, the team leader will need to plan their introduction into the team carefully. Where a project is already well under way, this might not be easy. However, the effort should be made. It should pay off as the new recruit will become fully effective member of the team more quickly.
The team leader should be aware of the need to assess continually the training needs of the team members. Just as you formulate user requirements before considering a new system, and a job holder profile before recruiting a member of staff, so a training needs profile ought to be drawn up for each staff member when considering specific courses.
14.8 Culture Hofstede (2003) suggested that culture can be defined as “civilisation” or “refinement of the mind” and the results of such refinement may be seen in education, art and literature (Hofstede, 2003). He believes that this is culture in its narrow sense. He defines culture more broadly as “mental programming” and suggests that culture is a catchword for all the patterns of thinking, feeling, and potential acting which are learned throughout a person’s lifetime. Hofstede also includes “the ordinary and menial things in life: greeting, eating, showing or not showing feelings, keeping a certain physical distance from others, making love, or maintaining body hygiene” in the broader definition of culture. It is this broader definition of culture that is used throughout this chapter.
According to Hofstede’s study, any organisation should first conduct cultural analysis on the local culture and provides this information to the remote team prior to mobilisation. This process is particularly important in the case of inexperienced or new team members.
A great deal of conflict has occurred on projects where the project manager has failed to take into consideration a remote site infrastructure and how to integrate different cultures. The project manager should consider how to integrate different
cultures on site in order to achieve a united team and improve the performance of the project. The remote team and especially new members must be educated on how to cope with cultural shock. In this respect, past experience and knowledge should be used to educate inexperienced team members. Although language training is not specifically requested or suggested as a requirement, such language training may assist remote team members to deal more effectively with cultural differences and avoid conflict.
The following is a summary of recommendations to manage cultural issues more effectively (Krishna, S. et al. 2004):
-Provision of cross-cultural training: Cultural sensitivity training and awareness.
-Project briefings: Implementation of comprehensive project briefings to include information on local cultural requirements and cultural differences as well as guidelines on how to cope with cultural shock.
-Manage cultural integration: A project manager should consider how best to integrate the different cultures on a project and give due consideration to remote site infrastructure.
-Provision of language training: Basic language training should be provided to assist the team in communicating with local cultures.
14.9 Motivation and reward An important role of the offshore project manager is to motivate the people working on his project. Motivation is a complex issue but it appears that there are different types of motivations applicable to specific situations based on basic needs (e.g. food, sleep, etc.), personal needs (e.g. respect, self-esteem) and social needs (e.g. to be accepted as part of the team).
Several theories of motivation are helpful in order to highlight some of the difficulties of motivation in a remote project site context. Maslow’s (1943) hierarchy of needs (Figure 6) proposes that an individual’s behaviour can be determined by their strongest need. Maslow’s hierarchy of needs model is represented by a pyramid and the bottom level of the pyramid signify the most basic needs. An individual would endeavour to move up the levels of need to the top of the pyramid, which represents the highest need. As discussed by Field and Keller (1998), Maslow suggests that as soon as one desire is satisfied, another appears.
Figure 21: Maslow’s Hierarchy of Needs (1943)
In practice, people are likely to be motivated by different things at different stages of their life. For example, salary increases, while always welcome, probably have less impact on the more mature employee who is already relatively well paid, than on the lowly paid trainee. Older team members might place more value on judgement and sense of responsibility. However, salaries level can be important to staff approaching retirement because the amount of pension paid might as well depend on it (Judge,T.A. et al., 1992).
Some individual differences in motivation relate simply to personality differences. Some staff members are just interested in their work and want to develop their work roles. While others simply see the job as way of earning a living.
14.10 Individual Motivation: case study 2 This case study is taken from the book of Ian Sommerville (Sommerville, 2006). In his part of the case study, a practical situation is pictured where motivation plays a central role.
Alice’s assistive technology project starts well. Good working relationships develop within the team and creative new ideas are developed. However, some months into the project, Alice notices that Dorothy, the hardware design expert starts coming into work late, the quality of her work deteriorates and, increasingly, she does not appear to be communicating with other members of the team. Alice talks about the problem with other team members to try to find out if Dorothy’s personal circumstances have changed and if this might be affecting her work. They don’t know of anything so Alice decides to talk with Dorothy to try to understand the problem.
After denying that there is a problem, Dorothy admits that she seems to have lost interest in the job. She expected a job where she would develop and use her hardware interfacing skills. However, she is basically working as a C programmer with other team members and she is concerned that she is not developing her interfacing skills. She is worried that she will find it difficult to find a job after this project that involves hardware interfacing. Because she does not want to upset the
team by revealing that she is thinking about the next project, she has decided that it is best to minimise conversation with them.
14.10.1 Methods of improving motivation
To improve motivation the manager might therefore do the following:
-Set specific goals: these goals need to be demanding and yet accepted by the staff.
-Involving staff in the setting of goals helps to gain acceptance for them.
-Provide feedback: Not only do goals have to be set, but staff has to have regular feedback about how they are progressing.
-Consider job design: Jobs can be altered to make them more interesting and give staff more feeling of responsibilities.
14.10.2 Managing groups in an offshore project
A problem with major offshore software project is that they always involve working in groups, and many people attracted to software development find it rather difficult.
Formal groups can be either departmental or seen on the company’s hierarchy diagrams reflecting the formal management structure, or task groups which carry out specific tasks.
Tasks groups are mostly used for offshore projects and might call on people from different department and would usually be disbanded once the task was completed.
14.10.3 Becoming a team
Simply throwing people together will not immediately enable them to work together as a team, especially when you have people from different cultures and background working to achieve the same goal. Group feeling develops over time; it is suggested by Tuckman and Jensen (1977) that teams go through five basic stages of development:
-Forming: the members of the group get to know each other and try to set up some ground rules about behaviour.
-Storming: conflict arise as various member of the group try to exert leadership and the group’s methods of operation are being established.
-Norming: conflicts are largely settled and a feeling of group identity emerges.
-Performing: the emphasis is now on the tasks at hand.
-Adjourning: the group disbands.
Sometimes, specific team building exercises can be undertaken. Some companies, for example send their management teams off on outdoor activities.
14.10.4 Group composition
Valuable research examined the best mix of personalities in a project team.
Belbin (1981) studied teams working together on management games. He initialy tried putting the most able people into one group. Surprisingly, these elite teams tended to do very badly, they argued a lot as a result important tasks were often neglected. Belbin came to a conclusion that teams needed a balance of different types of people.
-The chair: not necessarily brilliant leaders, but they must be good at running meetings, being strong, calm and tolerant.
-The plant: someone who is essentially very good at generating ideas and potential solutions to problems.
-The monitor-evaluator: good at evaluating ideas and potential solutions and helping to select the best one.
-The shaper: rather a worrier, who helps to direct the team’s attention to the important issues.
-The team worker: skilled at creating a good working environment, e.g. by resources and information.
-The resource investigator: adept at finding resources in terms of both physical resources and information.
-The completer-finisher: concerned with completing tasks.
-The company worker: a good team player who is willing to undertake less attractive tasks if they are needed for team success.
A person can have elements of more than one type. On the other hand, about 30% of the people examined by Belbin could not be classified at all! To be a good team member you must be able to time your intervention (e.g. not try to overwhelm the others in the team), be flexible, restraint and always keep in mind the common goals of the team all the time.
14.11 Group composition: Case study 3 This case study was taken completely from the book of Ian Sommerville (Sommerville, 2006), in it, factors of a group composition are illustrated, especially the fact that a group composed with people sharing the same motivations could be problematic in achieving the common goal.
In creating a group for assistive technology development, Alice is aware of the importance of selecting members with complementary personalities. When interviewing people, she tried to assess whether they were task oriented, self-oriented and interaction oriented. She felt that she was primarily a self-oriented type as she felt that this project was a way in which she would be noticed by senior management and promoted. She therefore looked for 1 or perhaps 2 interaction-oriented personalities with the remainder task oriented. The final assessment that she arrived at was:
• Alice – self-oriented
• Brian – task-oriented
• Bob – task-oriented
• Carol – interaction-oriented
• Dorothy – self-oriented
• Ed – interaction-oriented
• Fred – task-oriented
Alice is an experienced project manager and understands the importance of creating a cohesive group. As the product development is new, she takes the opportunity of involving all group members in the product specification and design by getting them to discuss possible technology with elderly members of their families and to bring these to the weekly group lunch. The group lunch is an opportunity for all team members to meet informally, talk around issues of concern and, generally, get to know each other.
The lunch is organized as an information session where Alice tells the group members what she knows about organizational news, policies, strategies, etc. Each team member then briefly summarizes what they have been doing and the group then discusses some general topic such as new product ideas from elderly relatives.
Every few months, Alice organizes an ‘away day’ for the group where the team spend two days on ‘technology updating’. Each team members prepares an update on some relevant technology and presents it to the group. This is an off-site meeting in a good hotel and plenty time is scheduled for discussion and social interaction.
Group cohesiveness can be influenced by factors such as the organizational culture and the personalities in the group. As seen in the case study above, cohesiveness could also be encouraged through social events, developing group identity and territory and explicit team building activities.
14.11.1 Communication within an offshore project group
In the context of offshore based human resource management, communication may be more difficult. There may be a lack of communication infrastructure at the offshore project site. This may mean that an employee is unable to communicate back to the project manager or his or her family or may only be able to communicate at certain times of the day or week.
Communication lines may also be distorted or unreliable. Such a situation may result in unclear and distorted messages being transmitted back to the project manager and colleagues and the offshore worker may not be able to get his messages across effectively. It may, of course, be possible to set up e-mail, fax and telephone lines. However these forms of communication from a remote employee to his base and project manager do not address the non-written or non-verbal
forms of communication as identified by Adair (1997), such as body language (Adair, 1997). According to Adair, “The basic system for communication is the human body; not only the organs of speech and hearing, but eyes and facial muscles, hands and arms, brains and in many respects the entire body. Body language, as it is now familiarly called, is something we all use and observe throughout our waking hours”.
Figure 22: Communication on different levels (FUTURELAB, 2007)
According to analyses made by Adair in offshore remote locations, intercultural communication training and language training are of benefit to a project and remote team members should be provided with this training to help them to communicate more effectively with local customers and employees. Without this training, the team will have to learn through experience and it will take a period of time before they learn all of the subtleties involved with communicating across cultures. The project team should also be made aware of key information involving the project and the organization. Therefore it is important that the project manager makes regular site visits to conduct team briefings to update the team. These team briefings will help to create and maintain a bond between the project manager and team, as well as providing social contact. The briefings will also ensure that a project manager is made aware of key information that would not have been conveyed to him remotely. The project manager has the opportunity to adapt his communication approach on remote based projects.
According the Adair, the followings should be taken into account, should a HRM wants to optimize its communication practices within the premises of an offshore project:
-Communication infrastructure: The project manager should ensure that adequate systems are in place to aid effective communication
-Intercultural communication and language training: This training should be provided to remote teams to help them to communicate more effectively with people from different cultures
-Team briefings: The project manager should make regular site visits to brief the remote team on key information and obtain key information from the team.
14.12 People evaluation Evaluating workers in an offshore project in these modern days doesn’t limit itself just at the performance level of the worker. Most project managers have various options when it comes to measuring individual and teams. Saks (2000) outlines three measurements entities:
Traits, behaviours and outcomes. In his research, Saks elaborates on above cited characteristics. Human resource (HR) practices may thus result in employees exhibiting key attributes, such as loyalty or commitment to the organization. Despite its popularity, making trait assessments is difficult because traits are not clearly defined entities. In contrast, the measurement of behaviour data focuses on what an employee does or does not do in the workplace. Examples of work-related behaviours include being absent from work, poor time-keeping and resigning from employment. Unlike traits, work-related behaviour can be observed and recorded with some reliability. The third approach is to measure outcomes, the things produced or accomplished during a specific period of time in the workplace. The advantage of measuring employee performance in terms of the ‘number of units completed’, the ‘accident level’ or ‘customer complaints’ is the apparent objectivity involved. Whether it is commitment to the organization or absenteeism, turnover, accident or grievance rates, the problem of deficiency and reliability must be dealt with.
Team working has become more common in managing offshore projects, as has interest in measuring team performance. Drawing on the work of Hackman and Oldham (1980) research suggests that team performance is strongly influenced by four input variables: team structure, team norms, team composition and team leadership; and by process variables, team working and team learning which affect team performance outcomes. The measurement of these input and process factors is not, however, well developed (Saks, 2000).
Team process refers to the behaviours that take place in the team (across individuals and across time). Although a review of all team process theory is outside the scope of this chapter, we should highlight two important concepts that help to clarify potential process indicators of team effectiveness. There seems to be ample evidence that how the team approaches the job to be done has important consequences for ultimate team performance, this being referred to as ‘work team strategies’ (Kline, 2002).
The second concept is that of team learning, as the amount of informal learning that takes place within a team appears to affect team outcomes (Kasl et al., 2000).
When defining team performance, researchers and practitioners are usually thinking in terms of how well the team has been able to accomplish certain team outcomes. In work organizations, team performance is conceptualized in terms of
efficiency, that is, accomplishment relative to the resources utilized, efficiency thus being an output to input ratio.
Banker et al. (1996), for example, studied the impact of work teams on labour productivity, which was measured as a ratio of the number of units produced to the total number of production hours. Their results indicated that labour productivity improved following the formation of work teams. Finally, when undertaking research on work team performance, or when team data are to be analysed, it is important to remember that the unit of analysis is the team, the sample size therefore being the number of teams involved in the investigation (Saks, 2000).
Individual employee and work team measures affect organizational performance. Researchers and practitioners have used a number of organizational performance measures, including labour productivity ratios, product and service quality, unit cost ratios, revenue productivity and ROI. Saks (2000) also points out that researchers frequently tend to rely on single indicators of performance, ignore the relationships between ‘multiple measures’, tend to ignore the fact that some measures of organizational performance, for example change in market share, take longer to materialize than, say, a change in employee behaviour, and use performance indicators across dissimilar workplaces with no regard for their appropriateness, thus rendering comparisons meaningless.
Given that work organizations exist in order to accomplish a goal(s), researchers have often conceptualized organizational performance in terms of goal attainment, four specific indicators reflecting this approach:
Profit-related indices, productivity, quality, perceptual measures of goal attainment. Profit-related indices or financial variables include percentage ROI. Labour productivity, a popular indicator, is usually defined as the quantity or volume of the major product or service that the organization provides and is expressed as a rate, that is, productivity per worker or per unit of time. Huselid (1995), for example, measured productivity in terms of sales per employee. Quality which usually refers to the attributes of the primary service or product provided by the firm. Bratton ( 2001) reported improvements in quality as a result of team working measured in terms of fewer complaints of unit defects from other teams. The airline industry conducts random surveys of passengers to obtain data on perceptions of quality of in-flight service.
The monitoring of performance data can of course be used as a surveillance tool. Finally, although ‘hard’ financial data are often used to measure organizational outcomes, researchers also use perceptual measures to quantify performance. Cully et al. (2000), for example, measured perceived workplace economic performance by asking managers to compare their own organizations in a particular area (for example productivity) relative to other organizations in the same industry, using a subjective scale ranging from ‘a lot above average’ to ‘a lot below average’.
The organizational outcome measures discussed here are important for at least three reasons. First, these are employee-related outcomes and as such they are most directly influenced by HR practices. Different rewards and training programs are, for example, likely to have some influence on most, if not all, of
the outcomes. Second, these outcomes (for example productivity, quality and employee unit cost) can influence the organization’s financial operational goals. Third, the outcomes can influence the individual psychological contract as well as aspects of individual behaviour and/or outputs.
14.13 Skill improvement The key of the learning organisation is teamwork. Effective teamwork allows all the members of the team to learn together and to set their own direction in line with the shared vision of the company.
Learning is no longer just about training. By placing learning in the centre of the business strategy, training is viewed as a strategic function that can transform a company into a high performance organization and apply targeted training to address skill deficiencies and assessment that measures performances.
For employers, training serves two major purposes:
First, it provides staff with the skills and knowledge technically required to perform their jobs competently and safely.
A second, related, objective of training is social: to secure employee cooperation with the specific set of working practices and relations into which they enter. In short, training is intended to produce a labour force which is both able and willing to work in accordance with employers’ expectations. This second objective is particularly relevant to the initial training of new recruits in inculcating the desired attitudes and behavioural norms in new staff. Employers use initial training to encourage new staff to shed their attachment to workplace norms acquired during any previous employment.
For established staff this objective may be less important because employers believe that workers have already learned the ‘appropriate’ behavioural characteristics. The problem with skill improvement in most organizations is the decision to what kind of training to give to the employees, and who has to pay for it.
In his seminal work, Becker (1964) drew the important distinction between general and specific investments in human capital. If the skills a worker acquires through on-the job training are purely general, he argued, the wage on the external labour market will reflect the full marginal product from this training (Becker, 1964). Thus, workers capture the entire return from their general human capital in a competitive labour market. On the opposite, training in perfectly specific skills has no effect on the worker’s productivity in other companies and the wage that an employee could get elsewhere would thus be independent of the amount of training he received. As a consequence, the return to specific human capital is shared between employees and their companies. Becker concluded that employees must bear all the costs of their general training whereas the costs of specific training are shared between workers and firms. This way, Becker uses his theory based on empirical evidence to indicate a framework that preserves its two main characteristics:
- The worker always receives the full return from general training.
- The worker obtains a share of the return (rent) generated by specific training.
The single difference lies in the fact that all types of human capital investment were not separately considered, but rather allow for both general and specific training to be provided at the same time. Once this possibility is taken into account, the sharp conclusion that companies should never pay for investments in general training no longer applies. Furthermore, this result does not rely on general and specific skills being complements in production (or training expenditures) as the previous analysis has shown.
Recent debate concerning the link between training and business performance has suggested that available evidence does not demonstrate a clear and unambiguous relationship between the two (Soskice, 1994). Moreover, it has been argued that the absence of such a link might scare off small employers from providing training. Such arguments, however, may be missing the point. Most employers feel that training did provide benefits for the business yet most do not attempt to measure the impact, at least in any formal sense. Qualitative data measured by Soskice showed that most employers based their opinions on observation of employees working and their achievements. Employers adopted such ‘rules of thumb’ almost universally. Judgements were not made on the basis of impacts on the bottom-line; indeed, employers felt these were very difficult, if not impossible, to make. Other evidence from this survey e.g. on the relative lack of importance attached to potential ‘informational’ barriers to training also suggests this argument has been overstated.
14.14 Conclusion The issue of software offshoring is currently controversial. Emotions and fear run on both sides of the issue, from “Offshore is costing local jobs” to “We have to go offshore to even remain in this industry.” The real question is not one of emotional intensity but one of business: Does software offshoring make sense?
It is also wise to consider the level of involvement and integration between the organization and the vendor. The more tightly coupled and aligned the business partners are, the more the relationship can benefit both parties. However, the larger the entity, the slower it moves. If part of an organization’s strategic advantage is responding quickly to changes in the market, the lack of flexibility inherent in large offshoring contracts may do more harm than good.
Soft costs should also not be forgotten: Ramp up time, knowledge transfer, human capital and the vendor selection process are all very real costs in the software offshore equation that should not be taken lightly. As organizations are in the process of making a strategic decision on offshoring, it is important to calculate the costs that are associated with the process. These costs can be calculated both as tangibles and intangibles. Decision makers in these organizations have to come up with tangible numbers to justify the investment associated with offshoring by using cost analysis metrics.
It is just as important to evaluate the intangible costs as the hourly rate stipulated in the contract. Ignoring the intangibles can often lead to failure of the process and huge tangible loss for the organization. Before a decision on outsourcing is
made, these factors must be taken into serious consideration to evaluate if the cost justifies the investment of resources.
Once a company has decided how to fit outsourcing into the picture and what it can outsource, it must consider the tough question of “what makes sense to outsource?” These elements can then be sent to an offshore provider. The elements of IT that remain then either cannot be outsourced or do not make sense to outsource; in other words, they are not mature, standardized products, and a company can still gain competitive advantage from them.
Human resource management is a valuable asset for the project in particular and the firm in general. Treating it as a project enables managers to structure the way it’s used and makes it productive for both the employer and the employees.
Offshore projects more than any others are most sensitive when it comes to the human resource projects, because of all the barriers they could come across on the verge of transforming ideas to products. When taken seriously, the results could be economical prosperity.
14.15 References Adair, J. (1997). Effective Communication. London , UK: Pan Books.
Becker, G. (1964). Human Capital. Chicago: The University of Chicago Press.
Belbin, R. (1981). Team Roles at Work. Oxford: Butterworth-Heinemann.
Bratton, J. A. (2001). Why workers are reluctant learners: the case of the Canadian pulp and paper industry. Journal of Workplace Learning, Volume:13 Issue: 7/8 , Page:333-344.
Cheney, P. H. (1984). Effects of individual characteristics, organizational factors and task characteristics on computer programmer productivity and job satisfaction. Information and Management Volume 7 , Issue 4 , Pages: 209 - 214 .
Cully, M., VandenHeuvel, A., Curtain, R., & Wooden, M. (November 2000). Participation in, and barriers to, training: the experience of older adults. Australasian journal on ageing, v. 19, no. 4, , pp.172-179.
Carmel E., T. P. (2005). Offshoring Information Technology -Sourcing and Outsourcing to a Global Workforce. Cambridge, UK: Cambridge University Press.
Carr, N. ((May) 2003). "IT Doesn't Matter,". Harvard Business Review, Vol. 81 No. 5, pp. 41-9 .
E Kasl, K. D. (2000). Team learning: A model for effectiveness in high performing teams. Team development .
Emerson, R. M. (1972). “Exchange Theory Part I and II,” in Sociological Theories in Progress. J. Berger, M. Zeldith, and B. , pp. 38-87.
FJ Roethlisberger, W. D. (1939). Hawthorne Works of of a research program conducted by the Western Electric Company. Chicago: Harvard Univ. Press.
Field, M. a. (1998). Project Management. Open University: Thomson Business Press.
FUTURELAB. (2007, August 14). Google.com. Opgeroepen op August 8, 2008, van Marketing & Strategy Innovation Blog: http://blog.futurelab.net/2007/08/3_most_frequently_asked_questi.html
Gentle, C. (2004). The Titans Take Hold. Deloitte Research.
Giffin, G. (July 13th-15th, 2006). Helping Organizations to Manage Change. 7th World Congres on the Management of E-Business , 1-25.
Hakansson, H. (1982). International Marketing and Purchasing of Industrial Goods: An Interaction Approach. Chichester, England: John Wiley and Sons.
Hofstede, G. (2003). Cultures and Organisations-Software for the Mind. Profile Books Ltd.
Huselid, M. A. (Jun., 1995). The Impact of Human Resource Management Practices on Turnover, Productivity, and Corporate Financial Performance. The Academy of Management Journal, Vol. 38, No. 3 , pp. 635-672 .
JD Couger, R. Z. (MIS Quarterly, Vol. 3, No. 3 (Sep., 1979)). What motivates DP professionals. In R. A. J. Daniel Couger, Motivation levels of MIS managers versus those of their employees (pp. pp. 159-170.). Minnesota: Management Information Systems Research Center, University of Minnesota.
JR Hackman, G. O. (1980). Work Redesign. Reading, MA: Addison Wesley Publishing Company.
Kern, T. (1997). The Gestalt of an information technology outsourcing relationship: an exploratory. International Conference on Information Systems , Pages: 37 - 58.
Kline, J. J. (26 Aug 2002). The Development of Human Resource Management in Quality Award Winning Governments. Journal of Organizational Excellence, Volume 21 Issue 4, , Pages 71 - 80.
Maslow, A. (1943). A Theory of Human Motivation. Psychological Review , 370-396.
Massachusetts University. (2004). Business Process Workshops, Preparing the Campus for Change. HEUG Conference , Session 10368 .
Mohan Babu K, P. (2006). Managing Offshore IT Outsourcing Projects. Enterprise Architect, Technology Consulting Group, Infosys , 1-16.
Nam, K. R. (2003). Outsourcing: A Two-Level Investigation of Information Systems Outsourcing. Communications of the ACM, vol. 46, Iss. 12 , 86-92.
Porter, M. (1980). Competitive Strategy: Techniques for Analyzing Industries and Competitors. New York: McMillian Publishing Co.
Rajiv D. Banker, J. M. (Aug., 1996). Impact of Work Teams on Manufacturing Performance: A Longitudinal Field Study. The Academy of Management Journal, Vol. 39, No. 4 , pp. 867-890.
S Krishna, S. S. (2004). Managing cross-cultural issues in global software outsourcing. Communications of the ACM, Volume 47 , Issue 4 (April 2004) , 1-66.
Sommerville, I. (2006). Software engineering: Update. UK: Pearson Education.
Saks H. Danie, H. S. ( 1980). Why Workers Want Unions: The Role of Relative Wages and Job Characteristics. The Journal of Political Economy,, vol. 88, no. 2 , 69-349.
Saks, A. (2000). Research, Measurement, and Evaluation of Human Resources. Toronto: Nelson-Thomson Learning.
Soskice, D. (1994). “Reconciling Markets and Institutions:The German Apprenticeship System". In L. L. (ed.), Training and the Private Sector: International Comparisons. Chicago: Univ ersity of Chicago Press, NBER conference volume.
TA Judge, R. B. (1992). The Effects of Work Values on Job choices and decisions. Journal of Applied Psychology,vol. 77, no3, cat.inist.fr , pp. 261-271.
Tuckman, B. W. (1977). Stages in Small Group Development Revisited. Group and Organizational Studies,Vol. 2 , pages 419-427.
Turner, J. (1999). The Handbook of Project-Based. McGraw-Hill.
Wikipedia.org. (2008).
Williamson, O. (1979). Transaction cost economics: The governance of contractual relations. J. Law Econ. 22 , 233--361.
15 Glossary Distributed Software Product Development (DSPD) environment: the division of labor by dispersing software development tasks among several remote development centers.
Incident: include failures, bugs, questions which are usually reported by the client to the help desk or detected automatically by the development team.
Issue: (also known as ticket or task) any reported incident or problem to the service and support team.
Maintenance transition management: the transition of the maintenance activities for the software products to the outsourced company.
Outsourcer: the (parent) company that outsource its operations to another company.
Outsourced maintenance: maintenance is outsourced to a third-party that performs the maintenance operations in collaboration with the outsourcing company.
Outsourced company: the company that perform operation as part of the outsource agreement on behalf of another company (outsourcer).
DPSD: Distributed Product Software Development
Explicit Knowledge: type of knowledge existing in written or symbolic form that is easily transferable.
Knowledge Transfer: activity of transferring knowledge from one recipient to another, that in a distributed environment are set distant from each other.
Onshore: it usually identifies the country where the organization’s headquarters is located.
Offshore: it is the location where an organization conduce all or part of its businesses.
Outsourcer: the term refers to an organization involved in a process of outsourcing a part or the entire creation of a software product.
Tacit Knowledge: type of knowledge, which is difficult to transfer and to be articulated because of its intuitive nature
BT - An acronym of “Business Tools”, which is software produced by Acision.
CM Synergy (www.telelogic.com/synergy) - A tool used to accelerate the release management, such as for the versioning system.
JIRA (www.jira.com)
Bug - issue tracking tool that is commonly used in software testing.
KPA - A term of different ‘Key Process Areas’ used by Levi9 for their software testing phases.
Outsourcing company - Dutch software companies who outsource their process in Central and Eastern Europe.
Outsourced company - Software companies in Central and Eastern Europe who are responsible to accomplish the projects delivered by Dutch companies under certain agreements.
OWASP (www.owasp.org) - Open Web Application Security Project, which is mostly used as the standard guidelines for security testing.
Subversion (SVN) - A version control used to maintain current and historical versions of files such as source code, web pages, and documentation.
Testing Method - A term used to distinct the black box and white box techniques compared to any other types of testing.
UAT criteria - These are criteria agreed between the company and its clients, which is used for the acceptance testing purpose.
Governance model - the way the outsourcer and its partner arrange the outsourcing relationship by the means of legal entities and contracts.
Opportunism - Self-interested behavior by a partner in order to gain an advantage over the other partner(s) in the relationship
Outsourcer - a company which is outsourcing activities to a 3rd party
Outsourcing Governance Model - The guideline for choosing an outsourcing governance model presented in this chapter. The model is based upon the Transaction Cost Theory
Partner Level - An indication of how close and intertwined an outsourcer is with an outsourcing partner. The partner levels are: commodity, provider, partner and advisor.
Provider - a company which is providing development services for 3rd parties.
Transaction Cost Theory - The theory originally presented by Williamson (1985) that deals with governance model selection by companies based on the costs involved in business transactions. The theory uses three factors of the transaction to weigh the transaction costs: uncertainty, asset specificity and recurrence.
Assessment: In the context of quality management, assessment means the act of determining the extent of compliance with requirements together with the specification of actions necessary to fulfil requirements for compliance.
Assurance: Assurance is evidence (verbal or written) that gives confidence that something will/will not happen or has/has not happened. (See also Quality Assurance).
Certification: Certification is a process by which a product, process, person or organization is deemed to meet specified requirements.
Measurement: the figure, extend, or amount obtained by measuring
Metric: a verifiable measure stated in either qualitative or quantitave terms.
Potential nonconformity: A potential nonconformity is a situation that, if left alone, will in time result in nonconformity.
Quality Assurance: An overview process that entails planning and systematic actions to ensure that a product or service conforms to established requirements.
Quality Control: a process for maintaining standards of quality that prevents and corrects change in such standards so that the resultant output meets customer needs and expectations.
Quality Improvement: is part of quality management focused on increasing the ability to fulfil quality requirements.
Quality Management: The execution of processes and procedures that ensures quality as an output from the development process.
Quality objectives: Quality objectives are those results that the organization needs to achieve in order to improve its ability to meet needs and expectations of all the interested parties.
Quality Planning: Quality planning involves the provisions made to achieve the needs and expectations of an organization’s interested parties and prevent failure.
Quality: The totality of features and characteristics of a product or service that bear on its ability to meet stated or implied needs.
Standard: A measure used to evaluate products or processes and identify non-conformance.
Requirements management - A process that aims at setting up a product requirements list by gathering, identifying and organizing requirements.
Requirements engineering – A cyclic process that involves requirements elicitation, specification and validation, and verification, to identify, document and validate user requirements, where the user is available to participate in the process.
Story - A reminder to have a conversation with your project stakeholders. User stories capture high level requirements, including behavioral requirements, business rules, constraints, and technical requirements outsourcing
Outsourcer - Company that outsources development tasks.
Offshore - In the situation of company A, Offshore is outsourcing in another continent and refers to their establishment in India.
Nearshore - In the situation of company A, Nearshore means within the continent and refers to their establishment in the Czech Republic.
