Summary Post on Collaborative Learning Discussion 1

In my initial post, I highlighted the importance of the method used by the article's authors under discussion. Root Cause Analysis is used to find common elements between the causes of failure being studied.

I also highlighted the software process improvement (SPI) concept, which aims to lower costs and reduce time to market while improving software quality. One of my fellow students agreed with the importance of this concept but added the existence of a content team within the organisation, as a condition for its implementation. Although I agree that a good software product has to balance efficiency, reliability and maintainability, what I understand from the authors is that the focus would be on improving the process as ways of working rather than restricting the final product to just being efficient. Having said that, I consider the recommendation for having a content team to be valid.

Based on my experience, the top reason for project failure is Chaotic environment. Another of my fellow students agreed with this and suggested improving communication to avoid this issue.

The example cases BSkyB and EDS CRM (chaotic environment) and Ariane 501 (lack of relevant skills) were also highlighted as correct examples of lack of communication and failure to understand specifications, respectively.

To summarise, I found the use of categories for project failure causes to be very beneficial as they allow us to organise them and then recognise them. This knowledge will help us to avoid them or mitigate them.

References

Lehtinen, T. O. A., Mantyla, M. V., Vanhanen, J., Itkonen, J. & Lassenius, C. (2014) Perceived causes of software project failures - An analysis of their relationships. Available from: https://mmantyla.github.io/Lehtinen_IST_2014_Perceived_causes_of_software_project_failures_an_analysis_of_their_relationships.pdf [Accessed 22 September 2023].

---

Unit 4 Seminar, Activity 2

Read the articles by Verner et al (2014) and Anton & Nucu (2020) and then answer the following questions:
1. What are the main risks that the authors identify?
2. Which of the frameworks discussed in the Unit 3 Lecturecast would you use to capture and categorise the risks?
3. Add a risk and a suggested mitigation to the module forum.

In the first article, the authors study global software development and the literature review about GSD, to discover if the systematic literature review can provide helpful advice on risk and risk mitigation to organisations that directly or indirectly deal with DSG.

The authors recognise that the primary motivations for GSD are to reduce the time-to-market and access more resources at a low cost, therefore, to gain or preserve competitive advantage. However, the authors also consider that these motivations would not be achievable without managing the risks through the software life cycle (SDLC).

The increase in complexity (due to the size of the projects and global development), increases risk. Here are included time, culture, organisational and distance between stakeholders. All these are summarised in deficient communication.

Other risks mentioned by the authors are coordination, control and infrastructure.

Answer 1

In different categories, and talking about GSD, the main risks are

• Vendor’s poor infrastructure
• Lack of project management skills to choose a vendor
• National, organisational, and cultural differences (loss of data, confusion, etc)
• Differences in processes, policies, and standards
• Lack of well-defined modules (issues with progressive integration)
• Language differences (misinterpretation of information)
• Lack of training in communication and collaboration tools
• Limited face-to-face-meetings (difficulties in building collaboration)
• Peoples management and conflict resolution

Most risks are related to Human Resources and project management skills. Within these, communication and collaboration appears as the most common risk.

Answer 2

The two frameworks I find relevant to categorising risk are

1. The Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE).
It allows organisations to identify and manage information security risks. Offers a broad method for evaluation that shows the assets that can be under threat. This relationship between assets-risk-vulnerabilities allows organisations to understand what is at risk and, therefore, design a mitigation strategy (Albert, et. al, 1999).

With this framework, a set of risks is produced and prioritised according to their impact and probability.

2. Factor Analysis of Information Risk (FAIR).
As an international standard, it offers a quantitative approach model for information security and operational risk (FAIR Institute, N.D.). It is important to understand cyber risks and operational risks from a financial point of view.

This framework provides a scalable risk model with a standard categorisation for information and operational risks.

References

Alberts, C., Behrens S., Pethia, R. & Wilson, W. (1999) Operationally Critical Threat, Asset, and Vulnerability EvaluationSM (OCTAVESM) Framework. Available from: https://insights.sei.cmu.edu/documents/1210/1999_005_001_16769.pdf [Accessed 30 October 2023]

FAIR Institute (N.D.) What is FAIR?. Available from: https://www.fairinstitute.org/what-is-fair#:~:text=Factor%20Analysis%20of%20Information%20Risk,operational%20risk%20in%20financial%20terms. [Accessed 30 October 2023]