Check risks in GA and report to EV ILVO (all WP Leads)

[RaduGiurgiu]

Check The critical risks associated with your WP, from the Grant Agreement (p32-33) - report any encountered risks to EV ILVO

If there are unforeseen risks - report to EV ILVO as:

• risk description
• mitigation plan
• which WP is involved

Continuous process

Critical risks & risk management strategy

Risk number	Description	Work Package No(s)	Proposed Mitigation Measures
1	Weak coordination with other relevant projects and initiatives (Medium/Medium)	WP7, WP5, WP6	An Engagement Plan will be developed in M3 and regularly monitored to adapt accordingly and avoid relevant issues.
2	Overlap in calls leading to competition and a multitude of systems instead of alignments between efforts (Medium/Medium)	WP2, WP4	Collaboration with known current and future projects such as the 2022-01-04, ..-05, ..06, ..07 calls, EJP SOIL, ORCaSa, PREPSOIL etc.(1.2.7) and regular meetings with REA to understand new possible alignment needs.
3	EUSO, EC, other stakeholders expecting too much of the data update frequency the platform can provide: if the data is not there it cannot be shared (Medium/Medium)	WP5, WP6, WP1	Clear communication and expectation management in use cases and user engagement based on presence of data and possible update frequency (detail in time and space). Dissemination of project progress and expectations in relevant EU Expert and stakeholder groups, JRC, EEA.
4	EUSO stops/scales back activities (Low/Medium)	WP4	Continue as a knowledge and data repository linked to ESDAC/others.
5	Delivery to JRC fails because it’s not considering the coming Data and AI Acts and the HVD act (Medium/Medium)	WP1	SoilWise will monitor closely the progress of the Data and the AI Act (under legislation process), the Open Data Directive, the Data Governance Act (applies from 24/9/23), the HVD, and adapt accordingly.
6	Data space technology is not available during the project (Low/Medium)	WP3, WP2	SoilWise implementation plan will adapt and use existing controlled access technology. In such a case, the design will take into consideration the future transition to data space technology when it becomes available.
7	Modelling becomes too complex (Low/Medium)	WP3, WP2	SoilWise will adopt a top-down approach with clearly defined granularity. It will be based on an extensive analysis of relevant materials to ensure its robustness and scalability.
8	Intended technologies for use in the SWR and tools do not deliver (Medium/Medium)	WP3, WP2, WP4	WPs 3, 4 and 5 are building on tested technologies that have proven to be mature and efficient. It will monitor closely the related progress and detect potential problems in time, suggesting other technical solutions.
9	Data availability is lower than expected (Medium/High)	WP5, WP4	WP2 will adjust the Rolling plan accordingly to enrich the data resources or to shift activities to the next development cycle.
10	Countries and other stakeholders not willing or able to standardise and expose their data and knowledge (Medium/High)	WP4, WP1	Attention in use cases and WP7 on business models and governance, added value for all users, smart algorithms, AI and user feedback mechanisms to balance the burden of standardisation between users and producers of data and knowledge.
11	Functionality expectations at stakeholders and EUSO that technology or users cannot sustain (yet) (Medium/Low)	WP3, WP2, WP4, WP1	Adoption of a modular approach and selecting the next best option in functionality with sufficient TRL and improve TRL of solutions that are promising.
12	The Repository’s functionalities are not appropriate for the needs of the target groups (Low/Medium)	WP3, WP5, WP2, WP4, WP1	SoilWise will use an iterative process with multiple co-design cycles (following the muti-actor approach) to ensure the Repository will fit the end users’ needs.
13	Lack of user engagement makes the repository less viable (Low/Medium)	WP6, WP1	WP1 will ensure the designed repository will support real users needs. WP6 will focus on user engagement and create appropriate business models, to ensure the repository’s sustainability.
14	IPR conflict between partners (Medium/Medium)	WP6	Early identification and monitoring of project results & effective IP management strategy will be coordinated by BIOS.
15	Identification of unrealistic schedules (Low/Medium)	WP7, WP1	Dynamically re-scheduling of project schedule and execution plan when a serious delay is identified in the course of the project.
16	Delays in the architecture design (Low/Medium)	WP3, WP2, WP4, WP1	The project follows an agile life cycle to prevent delays and deliver an MVP as soon as possible.
17	Personnel risk (e.g departures) (Low/Medium)	WP7	Allocation of human resources in various activities from different project partners, provision of documentation, adoption of an agile approach and use of open-source technology accepted by a broader community.

[DajanaSnopkova]

New risks (actual blockers for the development):

• Missing User stories Requirements and prioritization - WP1,WP2,WP3,WP4 - 10 functionality points were defined that replace these requirements and steer the development process for the first iteration. They are part of the backlog but need to be revised and broken down into smaller tasks, including the definition of done. Alternatively, each functionality point is supplemented by a few requirements from the existing user stories.
• Missing JRC requirements in Project Backlog - WP1,WP2,WP3,WP4 - Requirements are written in the Meeting Minutes (this is not very efficient, and there is a lack of clarity, communication and consolidation).
• Missing Product owners per SoilWise components - WP2,WP3,WP4,WP7 - Currently, people responsible for the components are considered the Product owners, but these are often developers or too technically involved people.

[RaduGiurgiu]

New risks (actual blockers for the development):

* **Missing User stories Requirements and prioritization** - WP1,WP2,WP3,WP4 - 10 functionality points were defined that replace these requirements and steer the development process for the first iteration. They are part of the backlog but need to be revised and broken down into smaller tasks, including the definition of done. Alternatively, each functionality point is supplemented by a few requirements from the existing user stories.

* **Missing JRC requirements in Project Backlog** - WP1,WP2,WP3,WP4 - Requirements are written in the Meeting Minutes (this is not very efficient, and there is a lack of clarity, communication and consolidation).

* **Missing Product owners per SoilWise components** - WP2,WP3,WP4,WP7 - Currently, people responsible for the components are considered the Product owners, but these are often developers or too technically involved people.

Hi Dajana, thanks for adding these risks.

As specified in the description, the risks should come with a mitigation plan, too.

The first one is not a risk, it's a fact. A risk is that the user story requirements don't get translated into the development of technical components. It's a risk for iteration two, as this one is (almost) developed. And needs a mitigation plan.

The second one I can agree with, but it's also with a mitigation plan of having open communication with the developers from JRC which is in the works. However, is true that there is a risk that the JRC requirements are not captured in the development process.

As for the previous two, the third one needs a mitigation plan.

Risks need to describe potential future issues, not past ones. When reported, it needs to say if the risk materialized and explain if the mitigation plan was applied