Philips experiences in global distributed software development

About the paper:

1.This paper describes the experience of over 10 years of global distributed development at
 Philips, derived from about 200 projects.
2.Team coordination and communication, requirements and architectures, integration,
configuration management.
3.Subcontracting software development needs selection of suppliers, specification of the
work to be subcontracted and establishment and content of the contract.

Benefits of globally distributed development:
Shortening time-to-market cycles by using time zone differences ,
Improving the ability to quickly respond to local customer needs,
Allows organizations to benefit from access to a larger, qualified resource pool with the
promise of reduced development costs, and
Innovation:  mixing of developers with different cultural backgrounds may trigger new ideas.

Problems in globally distributed development:
1.Poor visibility and control of remote activities.
2.Inadequate communication, collaboration and coordination across individuals, teams, time-zones and projects.
3.Insufficient (or lacking) knowledge and asset management capabilities.
4.Language and cultural differences.
5.Trust factors.
6.Lack of shared contextual awareness.

Distributed development can be a purely ‘in-house’ (single company, multi-site)
activity or it can also involve customer-supplier relationships.

The problems encountered in Philips multi-site software development have been
grouped in the following categories:
1.Team coordination and communication
2.Managing requirements and architectures
3.Integration
4.Configuration management

Problems encountered for Team Coordination and Communication:

 Basic management capabilities were not present in teams,
 Dependencies between teams were not made explicit and managed,
 Acceptance procedures of mutual deliveries were not defined,
 Status of teams was not pro-actively checked,
 Escalation mechanisms were not defined,
 Learning curve was underestimated,
 Need for explicit communication was underestimated, and
 Loss of efficiency due to multiple teams.

Problems encountered for Managing Requirements and Architectures:
High impact of unstable requirements,
 No unified understanding of requirements and architecture was reached, and
 Architecture status was not managed.

Problems encountered for Integration:
Responsibilities were not assigned clearly and integration strategy and plan were missing.
 Integration effort and time were underestimated.
 Required knowledge and skills were not present in integration team.
 Integration was not centrally controlled.

Problems encountered for Configuration Management:
Not enough preparation time taken to set up CM infrastructure.
 Competent configuration managers were not available.
 Change management procedures were not defined.

Lessons Learned:
1.GDD has in practice been two to three times more costly compared to one-roof
 development.
2.Exchange of knowledge and practices are experienced.
3.Particular attention should be paid to the preparation and management of team
coordination and communication, requirements and architectures, and also integration
and configuration management.
4.GDD improves time-to-market and customer request response efficiency along with
access to greater and less costly resources.