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 Theme | Risk Theme | Risks | ID |
|---|---|---|---|
| 1. Development approach and standards | 1.1 Teams have differing approaches to software development | Differing definitions of when work is ‘done’ | 1.1.1 |
| Differing expectations around required quality of the final product | 1.1.2 | ||
| Different expectations around future maintainability and extensibility of code | 1.1.3 | ||
| Team members following different development methodologies and standards | 1.1.4 | ||
| Lack of agreement / unfamiliarity with code libraries | 1.1.5 | ||
| Unnecessary refactoring or rewriting of other teams code | 1.1.6 | ||
| Variations in testing, automation, and test-case coverage | 1.1.7 | ||
| 1.2 Differences in how teams manage and measure software development | Incompatible techniques or metrics for estimating work packages and completion | 1.2.1 | |
| Differences in measuring and reporting development velocity and overall progress | 1.2.2 | ||
| Differing approaches to overall development workflow | 1.2.3 | ||
| 1.3 Teams have different approaches to delivering code | Differing deployment processes, tools, and post-deployment checks | 1.3.1 | |
| Different expectations around documentation scope and coverage | 1.3.2 | ||
| 2. Tools and software | 2.1 There are different development tools in use across the teams | Difference in development tools, repositories etc. | 2.1.1 |
| Incompatibly between tools | 2.1.2 | ||
| Governance and compliance overhead around tool use | 2.1.3 | ||
| A need for teams to learn new tools | 2.1.4 | ||
| 2.2 There are problems with communication and knowledge sharing tools | Lack of common instant communication platform e.g. Messenger | 2.2.1 | |
| Incompatible, poor quality or restricted video conferencing and screen sharing tools | 2.2.2 | ||
| Partial coverage or unsuitable knowledge sharing tools | 2.2.3 | ||
| Lack of, poor quality, or restricted document sharing repositories | 2.2.4 | ||
| 2.3 Infrastructure and IT policy issues | Poor network connectivity between teams or individuals | 2.3.1 | |
| Restrictive IT standards / policies driven by client or lead development party | 2.3.2 | ||
| Management overhead for teams and individuals e.g. multiple passwords | 2.3.3 | ||
| 3. Distance and time zone | 3.1 Impact of team members spread across multiple time zones | Time difference makes scheduling calls / meetings difficult | 3.1.1 |
| Delay in responses to questions impacting time, cost and team motivation | 3.1.2 | ||
| Time difference delays / restricting communication with clients | 3.1.3 | ||
| Working across multiple time zones impacts team work life leading to fatigue and burn-out | 3.1.4 | ||
| Lack of support from parent organisation for staff working across different time zones | 3.1.5 | ||
| 3.2 Impact of distance between team members | Problems getting key people together quickly to solve issues | 3.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 met | 3.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 difficult | 3.2.5 | ||
| Poor connectivity or call quality in some regions impacts team | 3.2.6 | ||
| 4. Culture & Language | 4.1 Country impact on working hours | Differing working days or times of working | 4.1.1 |
| Differing national holidays across the team | 4.1.2 | ||
| Religious festivals restricting working hours | 4.1.3 | ||
| Differing local employment laws and policies | 4.1.4 | ||
| 4.2 Issues around multiple team languages | Teams working outside of their native languages | 4.2.1 | |
| Lack of a common team language | 4.2.2 | ||
| Strong or unfamiliar accents impacts communication | 4.2.3 | ||
| Poor language skills leading to misunderstanding or reduced communication | 4.2.4 | ||
| 4.3 Issues caused by differing cultural perspectives | National culture influences behaviour and attitudes | 4.3.1 | |
| Assumptions are made based on individual’s culture | 4.3.2 | ||
| Differing non-verbal communication and meaning | 4.3.3 | ||
| Attitudes to working outside of contracted hours | 4.3.4 | ||
| Differing approach to organisation hierarchies e.g. questioning decisions | 4.3.5 | ||
| 5. Team building and management | 5.1 Problems building and maintaining a shared team culture | Lack of shared vision and sense of one team | 5.1.1 |
| Fear of change from some team members | 5.1.2 | ||
| Hard to asses if remote staff are working efficiently | 5.1.3 | ||
| Difficult to assess motivation and happiness of remote staff | 5.1.4 | ||
| Differing or conflicting parent company cultures across teams | 5.1.5 | ||
| Conflicts around where expertise sits in the team e.g. Java vs. AEM | 5.1.5 | ||
| 5.2 Issues around management of remote teams | Leadership team is elsewhere / not involved | 5.2.1 | |
| Project Manager is remote from team members | 5.2.2 | ||
| Lack of clarity around line-management | 5.2.3 | ||
| Reluctance to follow guidelines from other teams | 5.2.4 | ||
| Poor or non-existent holiday cover | 5.2.5 | ||
| Hard to ensure real involvement in remote calls | 5.2.6 | ||
| 6. Clients and their organisation | 6.1 Client related issues | Client remote from main team | 6.1.1 |
| Client’s other commitments makes communication slow | 6.1.2 | ||
| Client language or time zone issues | 6.1.3 | ||
| Difficulty building relationship with remote client | 6.1.4 | ||
| Harder to manage issues when client is remote | 6.1.5 | ||
| Regular face-to-face sessions can be hard or impossible | 6.1.6 | ||
| 6.2 Client organisational issues | Complex organisational decision making process | 6.2.1 | |
| Organisational culture may not support distributed working | 6.2.2 | ||
| Delays with steering committees or approvals | 6.2.3 | ||
| Lack of support from organisation’s IT and security teams | 6.2.4 | ||
| 6.3 Issues when client’s provide development teams | Client development teams ‘become our clients too’ so are hard to manage even if less experienced | 6.3.1 | |
| Client’s organisational culture or approaches can affect development approach | 6.3.2 | ||
| Client teams feel their opinion should carry more weight | 6.3.3 | ||
| Client teams have internal escalation paths and ability to negatively promote the project | 6.3.4 | ||
| 7. Communication | 7.1 Issues communicating scope at the start of the project | Time required to adequately brief the distributed team | 7.1.1 |
| Communicating all aspects of project and development approach | 7.1.2 | ||
| Ensuring full understanding of relevant project requirements | 7.1.3 | ||
| 7.2 Issues with on-going communication | Communicating ongoing change | 7.2.1 | |
| Communicating progress to the Project team | 7.2.2 | ||
| Team over-reliance on email communication | 7.2.3 | ||
| Regular communication of change to the developers | 7.2.4 | ||
| Communicating refined processes as the project matures | 7.2.5 | ||
| 7.3 Problems with team member communication | Lack of face-to-face / social interaction builds weaker relationships between team members | 7.3.1 | |
| Differing understanding of the client / project priorities across distributed teams | 7.3.2 | ||
| Need for increased documentation if teams don’t work collaboratively | 7.3.3 | ||
| 8. Third party team members | 8.1 Issues when not all team members are working for same company | Team conflicts of interest, especially when projects struggle | 8.1.1 |
| Split of responsibilities can be unclear or disputed | 8.1.2 | ||
| Lack of openness around issues or delays | 8.1.3 | ||
| Competition for future work | 8.1.4 | ||
| Finger pointing or blame deflection | 8.1.5 | ||
| 9. Financial and contractual | 9.1 Financial risk to project | Need for increased management time | 9.1.1 |
| Timesheet approval across teams, especially third-party members | 9.1.2 | ||
| Billing and payment schedules if milestones missed | 9.1.3 | ||
| Payments to contractors | 9.1.4 | ||
| Financial mistrust between third-parties | 9.1.5 | ||
| 9.2 Contractual risk | Flow-down of contracts | 9.2.1 | |
| Cross border legal issues | 9.2.2 | ||
| Acceptability of use of third parties or contract staff | 9.2.3 | ||
| 9.3 Confidentiality and information security risk | Maintaining information security / confidentiality | 9.3.1 | |
| Sharing of client and project data between sites and parties | 9.3.2 | ||
| Cross border / organisation data transfer | 9.3.3 | ||
| 10. Project Management | 10.1 Need for increased PM time | Increased complexity of team meetings | 10.1.1 |
| Additional communication overhead | 10.1.2 | ||
| Financial reconciliation time sheeting, reporting etc. | 10.1.3 | ||
| 10.2 Complexity of managing distributed resources | Need to delegate to local PMs or leads | 10.2.1 | |
| No direct contact with developers | 10.2.2 | ||
| Limited visibility into what other teams are doing | 10.2.3 | ||
| Complexity if PM is in a different location to teams | 10.2.4 | ||
| Complexity of managing staff not in same organisation | 10.2.5 |
This table may also be downloaded as an Excel file:
Conclusions
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.
- Introduction
- Findings
- The Risk Framework