6 Distributed

SoberIT Software Business and Engineering Institute

HELSINKI UNIVERSITY OF TECHNOLOGY

T-76.5612 Software Project Management Spring 2010

6: Distributed Software Projects

Tuomas Niinimäki

Department of Computer Science and Engineering Helsinki University of Technology



Why distribute a software project?



Goals of distribution

  Cost reduction   Access to competent labor force   Presence in new markets   Around-the-clock / Follow-the-sun development   Focusing on core competencies

(Carmel 1999)



Distributed Software Development   Project can be distributed by

  Geographical location (~ offshoring)   Organizational boundaries (~ outsourcing)



Distributed Project Types

2 or more organizations

1 organization

Same location

Same country

Different countries

Geographical distance

Organizational distance

Traditional

intra-organizational

Locally distributed

inter-organizational

Global

inter- organizational

Locally distributed


Collocated

inter-organizational

Global


(Paasivaara 2005)



Geographical distance Organizational distance

Cultural distance



Benefits

  Cost-reduction   Access to new markets   Access to competent labor   Follow the sun – development

  Focus on core competencies   Access to competent labor   Cost-reduction


Cultural distance

  Access to new markets   Access to competent labor



Challenges

  Location   Time zones

  Command & Control   Practices


Cultural distance

  Conventions   Assumptions   Language



Geographical distance – near/offshore   Offshoring

  Globally distributed software development projects   E.g. in different continents, across multiple time-zones   Higher potential to leverage cost differences

  Nearshoring   Not going too far, e.g. in the same continent / time-zone   Reducing risk by having

 similar culture  business conventions   legal system   less geographical distance between sites



NEARSHORING

OFFSHORING



Allen curve (Allen 1978) ‏Probability of Communication at least once a week

Distance

30 m

10%

30%



Geographical distance - summary

Goals:   Cost-reduction   Access to new markets   Access to competent labor   Follow the sun –

development

Risks:   Communication delays   Lack of awareness,

visibility   Division of work   Language problems and

cultural conflicts   Different business

conventions, legislation, …

Collocated Distributed in one country

Nearshoring Offshoring

Low risk = less benefits High risk = more benefits



Organizational distribution

Goals:   Focus on core

competencies   Access to competent labor   Lower cost

Risks:   Differences in practices,

conventions   Division of tasks   Command & control   Lack of visibility   Contracts   Conflicts of interest,

competition



Organizational distance

Resources managed by the customer

Independent subcontractor

teams

Black box

Broad

Small- scale

Project management resposibility

Customer Subcontractor

Transparent Box

Broadness of the task

Subcontractor uses customer’s process

The subcontractor uses its own process

Collaboration practices need to be defined



Challenges of Distribution (1/4)‏   Coordination breakdown

  Difficult to divide tasks

  Geographical distance  Limits informal communication and face-to-face meetings  Traveling is expensive and time-consuming

  Time-zone differences  Around-the-clock development?  Limits face-to-face meetings and synchronous

communication  Problem solving, integration and testing is hard and slow



Challenges of Distribution (2/4)‏   Communication breakdown

  Lack of communication richness   Cultural differences   Language barrier   Differences in terms used



Challenges of Distribution (3/4)   Loss of “teamness”

  Lack of motivation/incentive to communicate   Lack of feedback   Lack of transparency

  Lack of trust  Fear, uncertainty, doubt  Company/Organization borders restrict information flow



Challenges of Distribution (4/4)‏   Organizational borders

  Roles and responsibilities?

  Differing processes, tools and working practices

  Lack of visibility  Context of work unclear  Information needs unclear  Forgetting or disregarding the informing of distant sites or

partners

  Lack of contacts



How to reduce risk in distributed software projects?



Risk from geographical distance   Reduce risks from geographical distance

  Travel enough  especially when problems   in the beginning of the project   in testing and integration phases

  Face-to-face communication essential for  Grounding of terms and concepts (= shared

understanding)  Informal communication  Teamness (= trust, togetherness)



Reducing risk from time zone difference   Reduce risk from temporal distance

  Working across time-zones reduces possibilities for communication

  Choose sites and partners preferably within same time-zone, if frequent communication is needed

  Use asynchronous communication   configuration management   testing tools   bug repository…



Reducing risks from cultural differences   Reduce cultural distance

  Bridgehead:  e.g. 25% of personnel onshore close to customer and  75% offshore

  Cultural liaison:  e.g. a native of India settled in Finland  serving as a cultural liaison with the offshore team in

India   Rotate management across locations to create awareness for

cultural diversity and how to cope with it



Practices for managing distributed software project



Visiting Engineer   Visits the collaboration partner (customer, subcontractor,

subsidiary)   Stays and works there for a longer period of time

  1 week – several months   Main task is to facilitate communication between sites

  Passing information and knowledge   Facilitates grounding (common concepts)   Creates contacts   Helps to solve problems (both technical and organizational)   Is available for face-to-face discussions



Frequent Deliveries   Especially beneficial in distributed projects

  E.g., weekly deliveries   Integration   Feedback from remote site, from customer

  Benefits   Creates transparency   Ensures understanding of requirements   Brings real check points   Avoids “big bang integration”   Gives instant feedback   Improves developer motivation



Frequent Deliveries   Delivery / Release cycles should be synchronized

  The same cycle length should be used by all sites

  Schedule for deliveries should be planned   Processes and practices for incoming deliveries   Resource allocation for evaluating the delivery

  Too frequent deliveries increase overhead   But may still be beneficial for e.g. risk management, quality



Example: Different Delivery Cycles

Company Alpha let their North American site deliver to us once every two months. We were required to deliver once a week. When we noticed that something was missing, we had to wait for two months.

We complained about that, and finally they changed to this same once-a-week delivery cycle, but it took all too long to do this change.

Two month delivery cycle was one of the biggest mistakes made in this project. Our bug fixing average times were somewhere between two and three months before the change.

Our scheduling was ruined. We got all the complaints because we were subcontractors.



Peer-to-Peer Links   Establishment of peer-to-peer links between organizations at

several levels   Improves communication   Enhances teamness

  Links can be created between named roles   Management level: Subcontracting   Project level: Project managers   Team level: Domain / Technology experts

  Proper and updated organization chart easily available   E.g. photos, roles and contact information at project’s web-

site



Example: Team level links‏ “As a project manager my task is to create the right contacts

between the developers, so that I don’t slow down the work and communication.

Instead, as soon as possible, the right persons will discuss directly, and I just follow that it is working and there isn’t problems.

When I meet the customer’s project manager and he introduces me to somebody [from the customer company]. When I find out that he works with certain module and that we have one person working with another [related] module, we arrange a meeting either through email, phone, or face-to-face. Then they can solve common problems together.”



Problem solving practices   Problem solving communication is even more important in

distributed projects than in collocated projects   Often neglected in the project planning phase

  Includes discussion related to   Requirements   Design   interfaces   technical environment   project context

  Lack of answers delays the project   Barrier to ask / motivation to answer?



Problem solving practices   The lack of answers delays the project

  Barrier to ask questions <-> motivation to answer?   Consumes time and resources!

  Solutions:   Problem solving responsible   Discussion forums   Direct contacts between developers (e.g., chat)‏   Workshops, camps

 Face-to-face problem solving  E.g. collocated integration and testing

  Building trust between teams and individuals



Sharing information   In a distributed project people get only the information you give

them

  Formal communication:   Make sure important decisions and other information is

shared efficiently   Make sure all sites have the access to relevant sources of

information   Make sure they know they have the access to information

  Tacit knowledge: “There is a lot of information at the corridors”   Do not expect anyone to know anything

 Make sure they know!   Context information helps to understand other messages



Sharing information   Practices:

  Inform in the beginning   Give reasons and background information   Regular meetings

 Weekly meetings, e.g. teleconference   Issue trackers, task trackers, repositories

 Various systems for managing changes and bugs  Can your subcontractor access?

  Peer-to-peer links in all levels of organization  Informal communication  Sharing project context



Monitoring and Giving Transparency   Visualize and communicate project status

  Follow-up in both directions   From the subcontractor to the customer   About project progress to the subcontractor

  Transparency is important   Team members at all distributed sites need progress

information -> a motivating factor   One site only managing and controlling the other can be

really annoying and demotivating  Open communication about problems and challenges both

ways!



Monitoring and Giving Transparency   Practices:

  Regular meetings  Who should attend which meeting?  Managerial & technical meetings?

  Progress reports  E.g., tasks done, open questions, problems, future

estimates

  Frequent deliveries and integration

  Peer-to-peer communication



Feedback   Subcontractors appreciate all feedback - also positive!

  A motivating factor   What kind of indirect feedback are you giving?   Do you listen to the subcontractor’s ideas?

  Practices:   Design and code walkthroughs   Lessons learned   Frequent deliveries



Example: Give Feedback "Sometimes I feel that this is like a black hole, we make [code], and send it somewhere. (...) If you haven't got any feedback for your work during the last half year, then you just start to wonder whether it is ok or not. Of course it is not, because when they start to test after that half a year, then you get the mistakes. It is difficult because you have already forgotten what you did a half year ago."



Building relationships   All communication affects relationship building

  Especially meetings in the beginning are important

  You cannot have too many face-to-face meetings  Travel!!  Use “visiting engineer” practice  Make visits from all sites possible

  Arrange a common kick-off   Whole project team, or for each sub-project   Both formal and informal agenda   Make it possible for people to interact and get to know each

other   Maintain relationships with subsequent team events



Building relationships   Alternatively other possibilities to meet, e.g.

  Steering group meetings at different sites  Provide context from all sites

  Trainings  hands-on training!  Pair programming‏

  Workshops, camps, planning and problem solving meetings   Practices:

  Give Faces   Kick-off   Trust building based on professional skill   Organization Chart



Example: Relationship Building We had difficulties to get our acceptance testing people to

understand that we are in the same boat [with our subcontractors] and it is no use to be enemies.

The reasons behind might be that when these developers get a delivery and it is not functioning perfectly well, and they know that it is not made by their friends here, but by someone living in Turkey and trying to do it as cheap as possible.

And that was the reason why testing was delayed here, because it was not motivating.

In this project we learned a lot about communication and how much it actually helps to see those subcontractor’s faces. It was difficult to believe it beforehand!



Summary




Cultural distance



Lessons learned   Distributing a software project does not make it easier to

manage   If you don’t know how to do the software yourself, it’s

probably not worth it distributing the work   It takes time

  to reach the goals: e.g. cost savings, building up competencies

  It takes more time   Communication delays and overhead   Sharing knowledge and competence   Motivational issues

  Communication is the essential key to success!



Thank you.

Questions?

Tuomas Niinimäki

[email protected]

6 Distributed

Documents

soberit software business

soberitsoftware business

engineering institutet

competent labor access

new markets access

competent labor costreduction

core competencies access

geographical location