Home » Distributed Web Development Risk – A Framework

Risk in web-development projects delivered by distributed development teams

The Risk Framework

The aim of this study was to deliver “a preliminary risk framework for distributed web development projects” as part of an MSc in Technology Management. This framework has been developed, giving project teams access to a clustered checklist of potential risks that can be reviewed prior and during work. As has been noted there is further development and research that could be done to this framework – hence it is positioned as ‘preliminary’.

Here are the primary risks drawn from the 120 item framework developed, see summary here.

Overall the finalised Framework consists of 108 discrete ‘Risks’ which are grouped into 25 ‘Risk Themes’. These in turn are grouped into 10 ‘Major Themes’ as follows:

  • Development approach and standards
  • Tools and software
  • Distance and time zone
  • Culture and language
  • Team building and management
  • Clients and their organisation
  • Communication
  • Third party team members
  • Financial and contractual
  • Project Management

This is summarised in the table below.

Major ThemeRisk ThemeRisksID
1. Development approach and standards1.1 Teams have differing approaches to software developmentDiffering definitions of when work is ‘done’1.1.1
Differing expectations around required quality of the final product1.1.2
Different expectations around future maintainability and extensibility of code1.1.3
Team members following different development methodologies and standards1.1.4
Lack of agreement / unfamiliarity with code libraries1.1.5
Unnecessary refactoring or rewriting of other teams code1.1.6
Variations in testing, automation, and test-case coverage1.1.7
1.2 Differences in how teams manage and measure software developmentIncompatible techniques or metrics for estimating work packages and completion1.2.1
Differences in measuring and reporting development velocity and overall progress1.2.2
Differing approaches to overall development workflow 1.2.3
1.3 Teams have different approaches to delivering codeDiffering deployment processes, tools, and post-deployment checks1.3.1
Different expectations around documentation scope and coverage1.3.2
2. Tools and software2.1 There are different development tools in use across the teamsDifference in development tools, repositories etc.2.1.1
Incompatibly between tools2.1.2
Governance and compliance overhead around tool use2.1.3
A need for teams to learn new tools2.1.4
2.2 There are problems with communication and knowledge sharing toolsLack of common instant communication platform e.g. Messenger2.2.1
Incompatible, poor quality or restricted video conferencing and screen sharing tools2.2.2
Partial coverage or unsuitable knowledge sharing tools2.2.3
Lack of, poor quality, or restricted document sharing repositories2.2.4
2.3 Infrastructure and IT policy issuesPoor network connectivity between teams or individuals2.3.1
Restrictive IT standards / policies driven by client or lead development party2.3.2
Management overhead for teams and individuals e.g. multiple passwords 2.3.3
3. Distance and time zone3.1 Impact of team members spread across multiple time zonesTime difference makes scheduling calls / meetings difficult3.1.1
Delay in responses to questions impacting time, cost and team motivation3.1.2
Time difference delays / restricting communication with clients3.1.3
Working across multiple time zones impacts team work life leading to fatigue and burn-out3.1.4
Lack of support from parent organisation for staff working across different time zones3.1.5
3.2 Impact of distance between team membersProblems getting key people together quickly to solve issues3.2.1
Restricted ability to get people in one place for project kick-off, briefings etc.3.2.2
Difficult to develop sense of ‘one-team’ when members haven’t met3.2.3
Calls with clients when teams are distributed makes it hard to present a ‘unified’ face 3.2.4
Staff on boarding is more difficult3.2.5
Poor connectivity or call quality in some regions impacts team3.2.6
4. Culture & Language4.1 Country impact on working hoursDiffering working days or times of working4.1.1
Differing national holidays across the team4.1.2
Religious festivals restricting working hours4.1.3
Differing local employment laws and policies4.1.4
4.2 Issues around multiple team languagesTeams working outside of their native languages4.2.1
Lack of a common team language4.2.2
Strong or unfamiliar accents impacts communication4.2.3
Poor language skills leading to misunderstanding or reduced communication4.2.4
4.3 Issues caused by differing cultural perspectivesNational culture influences behaviour and attitudes 4.3.1
Assumptions are made based on individual’s culture4.3.2
Differing non-verbal communication and meaning4.3.3
Attitudes to working outside of contracted hours4.3.4
Differing approach to organisation hierarchies e.g. questioning decisions4.3.5
5. Team building and management5.1 Problems building and maintaining a shared team cultureLack of shared vision and sense of one team5.1.1
Fear of change from some team members5.1.2
Hard to asses if remote staff are working efficiently5.1.3
Difficult to assess motivation and happiness of remote staff5.1.4
Differing or conflicting parent company cultures across teams5.1.5
Conflicts around where expertise sits in the team e.g. Java vs. AEM5.1.5
5.2 Issues around management of remote teamsLeadership team is elsewhere / not involved5.2.1
Project Manager is remote from team members5.2.2
Lack of clarity around line-management5.2.3
Reluctance to follow guidelines from other teams5.2.4
Poor or non-existent holiday cover5.2.5
Hard to ensure real involvement in remote calls5.2.6
6. Clients and their organisation6.1 Client related issuesClient remote from main team6.1.1
Client’s other commitments makes communication slow6.1.2
Client language or time zone issues6.1.3
Difficulty building relationship with remote client6.1.4
Harder to manage issues when client is remote6.1.5
Regular face-to-face sessions can be hard or impossible6.1.6
6.2 Client organisational issuesComplex organisational decision making process6.2.1
Organisational culture may not support distributed working6.2.2
Delays with steering committees or approvals6.2.3
Lack of support from organisation’s IT and security teams6.2.4
6.3 Issues when client’s provide development teamsClient development teams ‘become our clients too’ so are hard to manage even if less experienced6.3.1
Client’s organisational culture or approaches can affect development approach6.3.2
Client teams feel their opinion should carry more weight6.3.3
Client teams have internal escalation paths and ability to negatively promote the project6.3.4
7. Communication7.1 Issues communicating scope at the start of the project Time required to adequately brief the distributed team7.1.1
Communicating all aspects of project and development approach7.1.2
Ensuring full understanding of relevant project requirements7.1.3
7.2 Issues with on-going communicationCommunicating ongoing change7.2.1
Communicating progress to the Project team7.2.2
Team over-reliance on email communication7.2.3
Regular communication of change to the developers7.2.4
Communicating refined processes as the project matures7.2.5
7.3 Problems with team member communicationLack of face-to-face / social interaction builds weaker relationships between team members7.3.1
Differing understanding of the client / project priorities across distributed teams7.3.2
Need for increased documentation if teams don’t work collaboratively7.3.3
8. Third party team members 8.1 Issues when not all team members are working for same companyTeam conflicts of interest, especially when projects struggle8.1.1
Split of responsibilities can be unclear or disputed8.1.2
Lack of openness around issues or delays8.1.3
Competition for future work8.1.4
Finger pointing or blame deflection8.1.5
9. Financial and contractual9.1 Financial risk to projectNeed for increased management time9.1.1
Timesheet approval across teams, especially third-party members9.1.2
Billing and payment schedules if milestones missed9.1.3
Payments to contractors9.1.4
Financial mistrust between third-parties9.1.5
9.2 Contractual riskFlow-down of contracts9.2.1
Cross border legal issues9.2.2
Acceptability of use of third parties or contract staff9.2.3
9.3 Confidentiality and information security riskMaintaining information security / confidentiality9.3.1
Sharing of client and project data between sites and parties9.3.2
Cross border / organisation data transfer9.3.3
10. Project Management10.1 Need for increased PM timeIncreased complexity of team meetings 10.1.1
Additional communication overhead10.1.2
Financial reconciliation time sheeting, reporting etc.10.1.3
10.2 Complexity of managing distributed resourcesNeed to delegate to local PMs or leads10.2.1
No direct contact with developers10.2.2
Limited visibility into what other teams are doing10.2.3
Complexity if PM is in a different location to teams10.2.4
Complexity of managing staff not in same organisation10.2.5

This table may also be downloaded as an Excel file:


With regards to the core research question “does the use of distributed teams change the risk profile of web development projects…?” it can be seen that the participants do perceive a change in the risk profile when teams are distributed. This is seen by participants as overwhelmingly negative, in that risks are increased across all of the theme areas with particular emphasis on communication. Anecdotal comments from the participants around mitigation showed that many risks (particularly around communication) required extra meetings or additional time, and thus had a tangible effect on the project.

It could be argued in return that some risks can be reduced by the use of distributed teams e.g. financial risk reduced through cheaper hourly rates; or resource scarcity, which figured on studies for co-located teams (McDowall, 2005) but was not raised in this study. That being said, no-one raised either these or any other positive opportunities in these interviews despite being prompted that ‘risk is both opportunity or threat’ (OGC, 2009).

Looking at the two sub-questions, “if there are differences, are these new and unique items, or merely a matter of degree for existing items?” and “what items would a ‘distributed’ risk framework for web projects contain over and above those for a non-distributed team?”. Comparing these results with a previous risk framework (McDowall, 2005) it can be seen there are some common themes across both studies e.g. ‘team’ and ‘communication’, and that some risks are the same such as ‘client’s other commitments makes communication slow’ (6.1.2), and “complex organisational decision making process’ (6.2.1). Equally areas like ‘requirements Uncertainty’ which figured heavily in the 2005 study of co-located teams is not raised as an impacted risk in this study.

See initial summary here.