6 Distributed

SoberIT
Software Business and Engineering Institute

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

HELSINKI UNIVERSITY OF TECHNOLOGY

SoberIT

Why distribute a software project?


SoberIT

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)


SoberIT

Distributed Software Development
  Project can be distributed by
  Geographical location (~ offshoring)
  Organizational boundaries (~ outsourcing)


SoberIT

Distributed Project Types
Organizational
distance

Locally
2 or more Collocated distributed Global
organizations
inter- inter- inter-
organizational organizational organizational

Locally
Traditional distributed Global
1 organization
intra- intra- intra-
organizational organizational organizational

Geographical
Same Same Different distance
location country countries

(Paasivaara 2005)

SoberIT

Geographical distance Organizational distance

Cultural distance


SoberIT

Benefits


  Cost-reduction   Focus on core competencies
  Access to new markets   Access to competent labor
  Access to competent labor   Cost-reduction
  Follow the sun –
development
Cultural distance

  Access to new markets
  Access to competent labor


SoberIT

Challenges


  Location   Command & Control
  Time zones   Practices

Cultural distance

  Conventions
  Assumptions
  Language

SoberIT

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


SoberIT

NEARSHORING

OFFSHORING


SoberIT

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

30%

10%

Distance
30 m


SoberIT

Geographical distance - summary
Goals: Risks:
  Cost-reduction   Communication delays
  Access to new markets   Lack of awareness,
  Access to competent labor visibility
  Follow the sun –   Division of work
development   Language problems and
cultural conflicts
  Different business
conventions, legislation, …
Low risk = less benefits High risk = more benefits

Collocated Distributed in Nearshoring Offshoring
one country

SoberIT

Organizational distribution
Goals: Risks:
  Focus on core   Differences in practices,
competencies conventions
  Access to competent labor   Division of tasks
  Lower cost   Command & control
  Lack of visibility
  Contracts
  Conflicts of interest,
competition


SoberIT

Organizational distance

Broadness
of the task Broad

Transparent
Box Black
box
Independent
subcontractor
Resources teams
Small- managed by
scale the customer
Project
management
resposibility
Customer Subcontractor

Subcontractor uses Collaboration practices The subcontractor
customer’s process need to be defined uses its own process


SoberIT

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


SoberIT

  Communication breakdown

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


SoberIT

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


SoberIT

  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


SoberIT

How to reduce risk in
distributed software projects?


SoberIT

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)


SoberIT

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…


SoberIT

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


SoberIT

Practices for managing
distributed software project


SoberIT

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


SoberIT

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


SoberIT

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


SoberIT

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.


SoberIT

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


SoberIT

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.”


SoberIT

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?


SoberIT

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


SoberIT

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

SoberIT

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


SoberIT

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!


SoberIT

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


SoberIT

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


SoberIT

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."


SoberIT

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

SoberIT

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


SoberIT

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!


SoberIT

Summary


SoberIT

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!


SoberIT

Thank you.

Questions?
Tuomas Niinimäki

tuomas.niinimaki@soberit.hut.fi


6 Distributed

More Related Content

Similar to 6 Distributed

More from tuomasniinimaki

6 Distributed