Risk management in an open and distributed IT project community
What’s our challenge here?
Risk management is a common practice in industry. Indeed, the complexity of production chains and the dangerousness of certain environments must be analyzed and managed to guarantee the safety and performance of the system. In the field of Industry 4.0, risk management remains an essential exercise but can take different forms, in particular through the emergence of new digital tool capabilities, by the appearance of new project management methods (Lean, Agile, ...) and by the introduction of new technologies such as IoT and AI.
In the field of agile IT projects, risk management is costly and time-consuming, in particular for project managers. It requires a relatively significant human effort while in the agile context, the processes are supposed to be as lean as possible.
If in traditional IT projects risk management is complex, our open and distributed production context brings an additional layer of complexity that has led us to question the literature. We have found articles that propose strategies to automate certain phases of risk management in order to free project managers (Ozaly et al., 2017; Bilal et al., 2020). However, before wanting to automate risk management, it is necessary to identify the risks likely to appear as the project progresses (Bilal et al., 2020).
In a risk management strategy, the priority is therefore to be able to characterize the events likely to emerge during the life cycle of the project and capable of disrupting its smooth running. In a field relatively close to ours, Bilal et al. (2020) declined all the possible risks during the different phases of the software development project. The authors characterized 83 risk factors throughout the lifecycle of a project (see below for an excerpt of 19 risk factors for the coding / development phase). In addition to this census work, the authors also showed the criticality of each risk factor by calculating their probability of emergence and their impact on the progress of the project in the event of a confirmed risk. The proximity of the field of study to our field of digital IT solution development leads us to draw inspiration from this systematic characterization strategy by adapting the risk factors to our specificity.
In the article by Ozaly et al. (2017) the authors show that the risk factors in the agile context belong to different themes: human resources, the development process, the business environment (the context) and the technologies available in the information system. These thematic categories allow us to leave the specific area of software development in the article by Bilal et al. (2020) and gives us a macroscopic reading grid transferable to our field of activity.
However, identifying risks is only one step in the risk management strategy. From a risk management automation perspective, it is important to characterize what makes up the risk management strategy. Ozaly et al. (2017) show that risk management is based on risk assessment (risk identification / risk analysis / risk prioritization) and on risk control (risk planning / risk resolution / risk monitoring).
The authors show, through this breakdown of risk management, that a priori intelligent agents (in gray) can be implemented for the phases of risk identification, risk analysis, risk prioritization and risk monitoring. The results of the study show that the use of intelligent agents capable of participating in these phases of the risk management strategy considerably reduce (50%) the human efforts associated with manual risk management.
From Theory to Practice
In view of the literature and our problematic related to agile IT project management in a community and distributed production context, we were able to characterize the risks specific to our activity. From a methodological point of view, we have split the complexity of our activity into 14 axes and associated risks for each axis. In a perspective of continuous risk monitoring, we were able to characterize the risks: static risks (pre-existing, specific to the context of the project) and dynamic risks (evolving with regard to the progress of the project). In total, we have identified 158 risk indicators (88 static, 70 dynamic).
With the aim of monitoring the risks following the example of the theoretical advances of Ozaly et al. (2017) we have associated thresholds which are used to specify the level of associated risk for each indicator. This work allows us to feed the intelligent agent in order to facilitate decision-making and reduce human efforts. If we have for the moment succeeded in identifying, analyzing and monitoring the risks, we will work, in our next research cycle, on a digital acceleration of the monitoring to give only the essential information to the actors of the system and we will work on the expected answers. for each risk identified. From this dynamic risk assessment repository, it will be a question for us of designing a repository of good governance practices and sharing of responsibilities in the paradigm of an agile, open and distributed project community.
What’s next?
In the future, we will suggest & study an updated version of the Risk Management model (Ozaly et al. (2017)), which would be more relevant given our distributed context and the related challenges (Team Situation Awareness, Autonomous onboarding, Holacracy and related roles, Sense of belonging within the community, etc.).
This new model would add an additional process between the risk assesment and the risk controlling : risk awareness.
In other words : we often experience what we call a “Reality denial” (from “customers” mainly, aka people who are more at a strategic level, and don’t want (or simply cannot) understand what’s happening under the hood.
For example : A customer is asking for an insane delivery date on a given project. As an expert, you are aware that this is simply not humanly possible. But for some (both political & cultural) reasons, neither want you share this information, nor will the recipient want to hear such bad news (and its consequences). This chicken-egg problem often results in burnouts among those involved on the project. Not so cool…
This is typically a situation where
the risk assessment is OK
the risk control could be OK (well known solutions)
but the awareness among those involved in this “project community” is NOT OK
Here is the new model we suggest :
We will keep you posted if this new model helps… :-)
Acknowledgement
Special Thanks to Thibault Kerivel for this collaborative post.
References :
Odzaly, Edzreena & Greer, Des & Stewart, Darryl. (2018). Agile risk management using software agents. Journal of Ambient Intelligence and Humanized Computing. 9. 10.1007/s12652-017-0488-2.
Bilal, Muhammad & Gani, Abdullah & Haseeb, Misbah & Bashir, Nauman & Malik, Nadia. (2020). Risk Assessment Across Life Cycle Phases for Small and Medium Software Projects. Journal of Engineering Science and Technology. 15. 572-588.