6 Distributed
Upcoming SlideShare
Loading in...5
×
 

6 Distributed

on

  • 465 views

 

Statistics

Views

Total Views
465
Views on SlideShare
465
Embed Views
0

Actions

Likes
0
Downloads
28
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

6 Distributed 6 Distributed Presentation Transcript

  • 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 Software Business and Engineering Institute Why distribute a software project? HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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) HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute Distributed Software Development   Project can be distributed by   Geographical location (~ offshoring)   Organizational boundaries (~ outsourcing) HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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) HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute Geographical distance Organizational distance Cultural distance HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute Benefits Geographical distance Organizational distance   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 HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute Challenges Geographical distance Organizational distance   Location   Command & Control   Time zones   Practices Cultural distance   Conventions   Assumptions   Language HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute NEARSHORING OFFSHORING HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute Allen curve (Allen 1978)‫‏‬ Probability of Communication at least once a week 30% 10% Distance 30 m HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute Challenges of Distribution (2/4)‫‏‬   Communication breakdown   Lack of communication richness   Cultural differences   Language barrier   Differences in terms used HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute How to reduce risk in distributed software projects? HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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) HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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… HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute Practices for managing distributed software project HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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. HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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.” HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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? HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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! HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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." HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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! HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute Summary HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute Geographical distance Organizational distance Cultural distance HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute 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! HELSINKI UNIVERSITY OF TECHNOLOGY
  • SoberIT Software Business and Engineering Institute Thank you. Questions? Tuomas Niinimäki tuomas.niinimaki@soberit.hut.fi HELSINKI UNIVERSITY OF TECHNOLOGY