Editing UNITA Agile Management Guide (section)

=2. Agile Project Management=

This chapter describes succintly the main procedures for agile management, with emphasis on agile meetings, and presents the available tools for the implementation of this methodology. It also devotes specific sections to critical elements of decision making, such as decisions, indicators, dependencies, deliverables, changes, issues ands risks.

==Agile Meetings Management==
===Generalities===
Organizing and running an Agile meeting effectively involves several key steps to ensure the meeting is productive, engaging, and valuable for the team. To stimulate participation, the recordings of the meetings should be used only under exceptional circumstances.

=== Important Steps ===

==== 1. Define the Purpose and Objectives ====

'''Purpose''': Clearly define the purpose of the meeting. It is important, when scheduling a meeting to know what it is for.  
'''Objectives''': Set specific goals for what you want to achieve during the meeting.

==== 2. Schedule and Frequency ====

'''Schedule''': Choose a time that works for all participants, considering the different time zones. You can use Datacloud to create Polls for the participants to vote on the best time and date, or you can use a meeting to decide the next one.  
'''Frequency''': Decide on the frequency of the meeting.

==== 3. Prepare the Agenda ====

'''Agenda''': Create an agenda outlining the topics to be discussed and the time allocated to each and share it with the participants beforehand.  
If there are documents that will be needed in the meeting — presentation, word documents, excel documents, etc. — be sure you share them, or the link to where they can be found, with the participants. It's important for the participants to have access to them before the meeting, so that they can read/analyse them previously, if necessary.  
'''Time-boxing''': Ensure each topic is time-boxed to keep the meeting focused and efficient.

==== 4. Assign Roles ====

'''Coordinator''': Designate someone to lead the meeting and keep it on track.  
'''Participants''': Clearly define who needs to be in the meeting and their roles. You can use the “Agenda” to mention the persons that should attend the meeting.  
'''Owners''': Clearly define who is responsible for an item/action/risk/decision.

==== 5. Run the Meeting ====

* '''Start on Time''': Begin the meeting promptly to respect everyone’s time.
* '''Stick to the Agenda''': Follow the agenda to keep the meeting focused and on schedule.
* '''Encourage Participation''': Ensure all team members have the opportunity to contribute.
* '''Facilitate Discussion''': The coordinator should guide the discussion to keep it productive and relevant.
* '''Capture Notes''': Document key points, decisions, and action items during the meeting. This will help you after to write the minutes of the meeting.

==== 6. Measuring Attendance ====

'''Track Attendance''': Use a method to record who attended the meeting. This can be done manually or through digital tools.  
In BBB rooms you can download the list of attendees from the gear button on top of the users column on the left side of the screen.  
In the “Minutes” Template you will have a table to confirm the presence of the participants.

<blockquote>
'''Note''': In order for the information to be passed on to all the Universities of a project equally and for decisions and actions to be taken and decided, it is very important that at least one person, from each institution be present in a meeting.
</blockquote>

==== 7. Minutes ====

'''Distribute Meeting Minutes''': Share the meeting minutes with the notes, action items, risk that maybe were (or not) detected, and decisions, with all participants.  
Make sure you do not share it too late with the participants, otherwise, the risk of information getting lost or late actions can increase.

'''Action Items''': Ensure that assigned tasks are clearly documented and tracked.  
Also, when deciding the “Target resolution date” please make sure that it is feasible.

==== 8. Continuous Improvement ====

You can collect feedback from participants on the meeting’s effectiveness and areas for improvement.  
This way you can make adjustments based on it to enhance future meetings.

=== Agile Meetings ===

The AGILE Project Management Approach involves dividing into actions the activities of the project, breaking the project into phases or cycles, and emphasizing continuous collaboration and improvement through recurring meetings.

'''What is an action?'''  
The result of a breakdown of a general activity in specific and simple operations.  
It is part of an activity provided for, in the task, and should provide an explicit added value to stakeholders (e.g. students, staff, partners, etc.).  
Each action is described in the specification action sheet (see section Agile Tools).  
To define and detail an action, an explicit specification sheet exists, asking for the following information:

{| class="wikitable"
! Topics required !! Example
|-
| '''Title''' || Creation of the job description for each UO position.
|-
| '''Description''' || Job description sheets detail the different required positions and roles in the future UNITA Office. It constitutes the support for informing about and initiating the future recruitment process, the conditions of work and the expected objectives.
|-
| '''Deadline''' || Month 1
|-
| '''Required resources (workdays, human resources, services, budget, etc.)''' || 
* Human Resources  
* Services  
* Budget  
|-
| '''Concerned services''' || University management board (Rectors, VPs...); HR Unit  
Budget: evaluation of the budget dedicated to the recruitment operation and assessment of the salaries of the future team members.
|-
| '''Priority in terms of added value (compared to other actions)''' || Necessary action to initiate the constitution of the UNITA Office and thus, to implement and coordinate the UNITA activities.
|-
| '''Assignees (RASCI matrix): Who does What?''' || Determination of the staff involved in the action and assign them specific sub actions.
|-
| '''Status (workflow place, see next...)''' || 
|}

'''What is a Cycle?'''  
The working period between two meetings (maximum one month for UNITA).  
According to the workload and number of actions needed, the frequency of the meetings should be established.  
For example, for TT meetings, in order to take stock of the last cycle’s actions and to define/redefine new ones, it was agreed to have monthly meetings.  
In each meeting, previous actions can be revised, and other actions can be (re)defined and implemented for the next cycle, using the following table to help:

{| class="wikitable"
! New actions !! To Do !! In Progress !! To Review !! Done !! (Bin)
|-
| 
| 
| 
| 
| 
| 
|}

Let’s take a look at the following example:

* Before or during a meeting, a new action may be proposed and recorded in the '''New Actions''' column.
* If the Task Team validates the implementation of this action, its status changes to '''To Do'''. This means it is planned to be implemented during the next cycle.
* If the action is rejected, it is moved to the '''(Bin)''' column.

During the next meeting (and in every subsequent meeting), the Task Team will proceed with the following:

** A review of the actions listed in the '''To Do''' column. The status of each action is assessed and updated according to five possible outcomes:
*** '''In progress''': Action is partially completed.
*** '''Blocked''': Action is currently stuck for some reason.
*** '''Overdue''': Action is behind schedule.
*** '''To review''': Action is not feasible as originally defined.
*** '''Done''': Action is 100% completed.

** A refinement or adjustment of the new actions listed in the '''New Actions''' column. As previously described, these actions may be:
*** Accepted and moved to '''To Do''',
*** Rejected and moved to '''(Bin)''',
*** Recalibrated into smaller or redefined sub-actions.  
New actions can also address previously '''Blocked''', '''Overdue''', or '''To review''' items by redesigning, subdividing, or redefining them to optimize feasibility.

** Planning the priorities for the next cycle:
*** '''To Do''' actions are reviewed and prioritized accordingly.
*** The Task Team assigns responsibilities for each action based on its priority and the team’s available capacity.

=== Meeting Minute Template ===

Template for the meeting minutes can be found here:  
[https://datacloud.univ-unita.eu/index.php/apps/onlyoffice/710510?filePath=%2F4_Unita_Phase_I%2FUNITA%2FProject_docs%2FU_Templates%2FMeeting_Agenda_(Bodyname)_yyyymmdd.odt Click here to access the Meeting Minute Template]

==Agile Tools==
This section describes the main tools available for the UNITA community to adequately implement the agile project management methodology outlined in the management guide.

=== Open Project ===

[https://openproject.univ-unita.eu/login?back_url=https%3A%2F%2Fopenproject.univ-unita.eu%2F OpenProject] is the open-source project management software chosen by UNITA as its official software solution for the implementation of the agile methodology.  
It can be integrated as a third-party app in the Datacloud, linking files in the [https://datacloud.univ-unita.eu/ Datacloud] to project-related work and checking from the Datacloud which work packages in a project belong to certain files.

==== Who uses it ? ====

The tool has been configured according to the needs of the UNITA project.  
Task leaders and, where appropriate, project managers will be responsible for feeding, managing and monitoring the tool.  

For example, TTLs of the task 5-4 with the project manager of the university leading the task. In this case, UPPA.  
They will be responsible for alerting the relevant bodies and players as critical dates approach or when delays are noted.  
The task leaders and project managers will undergo hybrid training to learn how to use the software.

All UNITA members will be able to see the progress of UNITA phase 2 through OpenProject, but they will not be able to implement the software.  
OpenProject will simply be an information tool and they won't receive any training.

==== How to use it ? ====

Each work package, task, activity, and action will be implemented in the tool according to the criteria defined in the agile table.  
Each task leader and co-leader will be responsible for feeding the tool.  
They will enter all the information concerning:
* The start and end dates of the task, activity, action, etc.
* Expected deliverables
* Milestones
* A description of the actions and activities

To do this, they will use:
* The UNITA 2 project
* The general UNITA 2 glove and the gloves per [[Structural_Viewpoint|WP, Task]]
* The minutes of the various meetings ([[Governance Board|GB]], [[Management Committee|MC]], [[Structural_Viewpoint|WP]], [[Task Team Members|TT]], etc.)
* Any useful information

'''Example:'''  
Once all the information has been entered, everybody can monitor the progress of the project in real time using the tool and its various views.  
The role of the project managers will be to monitor the progress of the project and to warn of any delays.

==== Project views ====

OpenProject allows different visualizations of the actions into which a project is broken down.  
From a classical Gantt view, which is appropriate to check deadlines and interdependencies, to a Kanban board, more fitted to the agile approach, each view offers different, complementary insights to the project managers and project team.

'''Here is an example of these views:'''
# Agile board view (Kanban board)
# List view
# Gantt view

=== Agile Document Templates ===

==== Specification Action Sheet ====
* '''What''': This specification sheet provides a precise definition of the action. Every member of UNITA knows the ins and outs of the action.
* '''Completed by who''': The Task Team Leaders
* '''When''': The specification sheet must be drawn up before starting the action.

==== Models for Pre-minutes and Minutes of the Task Meeting ====
* '''What''':
** Each meeting must be prepared, in the form of pre-minutes.
** Minutes must be taken of each meeting.
* '''Completed by who''': The leaders of the meeting.
* '''How''': A template, in Word format, for taking minutes of meetings is available on the Datacloud.  
This template follows the guidelines of the AGILE method.

=== The RASCI Responsibility Matrix ===

'''The RASCI'''  
The Responsibility Matrix is a double-entry table which shows:  
* In the rows: the different phases and activities.  
* In the columns: the various actors involved.  
The specific roles attributed to the various actors involved in the same phase are shown at the intersection.

For each activity, it is not possible to indicate more than one '''Responsible''' and more than one '''Accountable'''.  
Rather, it is necessary to subdivide the identified activity until it is possible to trace the role '''R''' and '''A''' to one and only one of the actors involved in the process.

{| class="wikitable"
! RASCI !! Description
|-
| '''R''' || Responsible
|-
| '''A''' || Accountable
|-
| '''S''' || Supports
|-
| '''C''' || Consulted
|-
| '''I''' || Informed
|}

The roles that can be assigned for each activity are:

* '''Responsible''' – defines the person responsible for completing the activity. The abbreviation '''R''' must be assigned to a single subject. Having more than one person responsible for the same task increases ambiguity and the chances that the work will not be done correctly.

* '''Accountable''' – the person or persons responsible for supervising and approving the work being performed. This is usually a high-level person within the organization. The abbreviation '''A''' must also be assigned to a single subject.

* '''Supportive''' – the person or persons who provide operational support to carry out the activity.

* '''Consulted''' – are the subjects who must be consulted in order to obtain useful information for completing tasks or for improving the quality of the work itself. Communication with these subjects takes on a bidirectional nature in order to ensure proper follow-up.

* '''Informed''' – is the class of people who do not need to be actively involved in the project, but who nevertheless have an interest in its execution and must be kept informed.

The use of this tool is effective because it prevents the duplication of activities.  
Furthermore, the tasks between the actors are formalized in a clear and objective way.

=== Tools on Datacloud ===

'''Files''' :  
It is recommended that each task leader creates a shared folder in the task folder, where files upload will be possible.  
This will avoid email attachments.

'''Talk''' :  
It is recommended that each task leader creates a discussion using the Datacloud '''TALK''' tool.  
This will avoid numerous email exchanges that can be difficult to follow.

'''Collectives''' :  
This tool lets you create shared and collaborative documents online.  
More tools on the Datacloud guide: [https://datacloud.univ-unita.eu/index.php/apps/collectives/Datacloud guide]

== Escalation Process of Decisions ==

=== Managerial Decision-Making ===

The task team must work autonomously, but in constant coordination with the WP leaders and the Management Committee.  
Decisions on the development of tasks are taken within the task team.  
Questions that cannot be resolved by the task team are referred to the WP leaders for their arbitration.  
If arbitration is not possible and the question is of a managerial nature, the WP leaders will pass the question on to the MC.

One of the roles of the WPL is to refer questions to the MC only as a last resort.  
They must first and foremost seek a resolution within the WP.  
When communicated to WPL or the MC, problems must be well defined and always include possible solutions.

=== Political Decision-Making ===

Due to the transformative potential of UNITA and the deep impact of its structures and activities on the alliance members, some of the decisions made within the TT must be validated by the Vice Rectors-Presidents Boards who will act as delegates of the Governance Board.

This political approval not only affects certain decisions, but also some deliverables or milestones, as pointed out in the corresponding section.  
The WP co-leaders will handle the interaction with the [[VR/VP|VR/VP]] boards.

* Following the work of the task team, a need for a decision with political impact arises, with several alternatives.  
* This decision is submitted to the [[WP Co-Leaders|WP co-leaders]] by the [[Task_Team_Co-Leaders|TTL]], providing the necessary context.
* The [[WP Co-Leaders|WP co-leaders]] consult the [[VR/VP|VR/VP]] board assigned to the task, who make a decision either during a scheduled Steering Committee meeting (VR/VP board enlarged to WP and Task co-leaders) or asynchronously through a survey, in both cases arranged by the WP co-leaders.
* The decision made by the [[VR/VP|VR/VP]] board is communicated to the [[Task_Team_Co-Leaders|TT co-leaders]], so that they can include it on the agenda for the next task meeting.
* The decision is communicated to the [[Task Team Members|TT]], who resumes the work on the matter with a clear political guidance.

== Deliverables Production Workflow ==

=== Definitions ===

'''Milestones''' — Control points in the project that help to chart progress (kick-off meetings, steering committees, first draft of a survey, prototype, etc.).  
They may correspond to the completion of a key deliverable, which allows the next phase of the work to begin or is needed at intermediary points.

'''Deliverables''' — Outputs to be submitted to the EU (publication, leaflet, progress report, brochure, list, etc.)

=== Process ===

The process of producing, approving, and submitting a deliverable (optional for a milestone if it's in the form of a report/plan) follows the next steps, which are also summarized in the figure below:

==== 1. Drafting ====

The Task Team will work on the deliverable according to the timeline established in the corresponding Gantt chart.  
'''Deadline''': At least 40 days before the deadline for submission.

==== 2. Finalization, First Validation and Quality Review ====

'''WP Co-Leaders and VP/VR/Delegates Review'''  
Once the team deems the deliverable sufficient, it will be sent for review to the corresponding WP co-leaders, who will also seek approval from the Vice Rectors-Presidents Board assigned to the Task and communicate it to the TT co-leaders.  
'''Deadline''': At least one month before the final submission date.

'''Unita Offices and Quality Review (T1.3)'''  
Upon receiving approval, the deliverable must be sent for:
* Completion to the Unita Offices
* Quality review to Task 1.3

This group will check some compulsory aspects of the deliverable, as detailed in this document.  
'''Deadline''': At least fifteen days before the final submission date.

==== 3. Validation in MC and GB ====

In the corresponding Management Committee (MC) Meeting, the deliverable will be presented by the co-leaders of the Task.  
Acceptance or the need for revisions will be indicated, and TT leaders will inform the team about the status of the deliverable.  
'''Deadline''': No later than ten days prior to the final submission date.

==== 4. Submission to EU Commission ====

The Executive Coordinator is responsible for:
* Uploading the deliverable to the EU Portal
* Informing the TT and WP leaders accordingly, including TT1.1 co-leaders

'''Deadline''': Submission date

==== 5. Celebration in TT and Retrospective Analyses ====

The Task Team will reflect on the overall process based on the feedback received from the different agents.

== Indicators ==

Indicators are a critical element of project management, but also an important tool for the appropriate governance and management of the alliance overall.  

In the current second phase of UNITA, a lot of attention is paid to the transformative impact of the alliance within our universities, as well as among external local, regional, national and global stakeholders.  
A whole task (T 5.4) is devoted to this impact analysis, through the so-called '''Impact Observatory'''.  

A comprehensive UNITA '''Data Warehouse (DW)''' is being built to gather all relevant indicators and enable the impact analysis.  
The DW and the methodology of data collection, processing, storage, and analysis, will pilot and monitor UNITA Tasks, based on indicators, supporting the strategic, management and quality levels.

=== Types of Indicators ===

The project has defined a minimum set of '''official indicators''', whose collection and monitoring is a compulsory part of the project reporting to the EU.  
But beyond them, each Task Team (TT) must define, with the support and guidance of TT5.4, an additional set of indicators aimed at enabling the impact-oriented and data-driven strategy of UNITA.  
Each WP's Gantt chart includes a tab in which all these indicators should be correctly defined.

==== Official Indicators ====

Each project task is associated with 1 or 2 indicators (4 for task 5-1).  
These are the so-called '''official indicators'''.  
The list of these indicators is available in the section '''"UNITA Phase 2 Global Structure"'''.  

These official indicators must be:
* Defined by the task team
* Described in an indicator identity sheet
* Monitored continuously by the task team

Each month, the task team must submit its indicator by uploading the appropriate file to the '''UNITA Data Warehouse'''.

==== KPIs (Key Performance Indicators) ====

The European Commission requires tracking of some common KPIs through a section in the EU platform, which must be updated with the latest available data for each periodic report.

==== Communication EU Indicators ====

To collect these indicators:
* UNITO has designed an Excel file containing all the information required.
* This file helps partners to complete the EU platform.
* Each partner has designated a pair of people to fill in the information on the European platform.
* Each partner provides the information for its university on a monthly basis.

==== Internal Indicators ====

Each task team can choose other indicators, which will be called '''internal'''.  
As with official indicators:
* The task team must define and draw up an identity sheet for each internal indicator.
* The task team is responsible for monitoring them.

=== Guideline for Good Indicators ===

When defining indicators, the following guidelines can be useful:

* Have a reasonable and consistent number of indicators.
* Consider the relevance of each indicator.
* Have a clear and precise definition: define the terms exactly, the population concerned, the method of calculation, etc.
* Draw up an identity sheet for each indicator.

The figure below shows an example.

== Risks and mitigation measures ==

Risks and issues are different (source pmi.org):  
The key difference is an '''“issue”''' already has occurred and a '''“risk”''' is a potential issue that may or may not happen and can impact the project positively or negatively. We plan in advance and work out mitigation plans for high-impact risks. For all issues at hand, we need to act immediately to resolve them.

'''Examples of risks that can arise in the project are:'''
* suboptimal involvement of team members
* budget overrun
* deliverables not produced on time
* cyber attack to the IT systems

Agile Risk Management involves removing obstacles that impede the work progress of the project team members. Agile projects tend to be less risky by nature, for several reasons:  
* '''Collocated teams''': bringing the project team and the client together leads to better communication and less wasted time.  
* '''Simplicity''': the team should only concentrate on the minimum amount of work that needs to be performed. Wasteful processes should be eliminated.  
* '''Regular Reflection''': by continuously improving processes throughout the project, risk is exponentially reduced. Process improvements should be immediately implemented in the following iterations, ensuring that these same risks do not occur again in the project.

=== Risk management ===

Risk management aims to ensure that risks that might have a potential impact on project scope, time, cost, quality, risk, or stakeholder satisfaction are identified, assessed and a risk response strategy is planned.  
Risks are logged and followed-up in a Risk Log. In each TT meeting, the team must:
* check and update the status (to do, in progress, done) of previousuly assigned risks
* identify new risks (if any) and the affected area (Schedule, Budget, Resources, Quality, Reputation)
* assess their risk level
* assign them (RASCI) for resolution/mitigation by specific actions

The risk level will be calculated by the product of likelihood and impact using the following risk matrix:  
Depending on the risk level, a different respose strategy should be adopted:

{| class="wikitable"
! Risk level !! Response strategy
|-
| High || AVOID: take immediate action that will eliminate the risk in entirety. Depending upon the circumstances, you may need to change project scope, modify project plans, hire additional resources, or adopt different technical solutions.
|-
| Medium || REDUCE: take action that will minimize the potential impact of any given risk through the analysis and consideration of alternative solutions. You can alter detailed plans and schedules, and take specific actions to minimize the chance that a risk will occur. And, you can also develop alternate measures to be enacted should the risk actually occur (contingency measures)
|-
| Low || ACCEPT: acknowledge the risk, but decide that any actions to avoid or mitigate the risk can be too costly or time consuming. Or, it may just be possible that the risk cannot be avoided or mitigated in any meaningful way, and the benefits of the project far outweigh the risks. A low-effort mitigation measure can be proposed just in case.
|}

== Issues and mitigation measures ==

Risks and issues are different (source pmi.org):  
The key difference is an “issue” already has occurred and a “risk” is a potential issue that may or may not happen and can impact the project positively or negatively. We plan in advance and work out mitigation plans for high-impact risks. For all issues at hand, we need to act immediately to resolve them.

'''Examples of issues that can arise in the project are:'''
* There are disagreements on the interpretation of requirements;
* The WP task force has difficulties achieving the set goals (e.g. in terms of time, resources or quality);
* Non-conformities are identified by the WP task force or by other Stakeholders;
* Risks identified in the Risk Log occur, and thus risks change from potential problems to actual problems;
* External effects that influence the project in a negative way;
* Many other reasons.

=== Issue management ===

Issue management aims to ensure that issues that have a potential impact on project scope, time, cost, quality, risk, or stakeholder satisfaction are assessed and acted upon.  
Issues are logged and followed-up in a Issue Log. In each TT meeting, the team must:
* check and update the status (to do, in progress, done) of previousuly assigned issues
* identify new issues (if any) and the affected area (Schedule, Budget, Resources, Quality, Reputation)
* assess them in terms of priority
* assign them (RASCI) for resolution by specific actions

A priority level score is assigned according to the following list:

{| class="wikitable"
! Level !! Meaning
|-
| Critical || Immediate action required
|-
| High || Significant impact, resolve soon
|-
| Medium || Important but not urgent
|-
| Low || Minor improvement or enhancement
|}

As the following diagram shows, issue management follows the escalation process of decisions previously defined in the guide.

== Changes ==

Adopting the Agile perspective implies recognising and to welcoming the natural evolution of the project scope. As a project progresses, both the project team and the stakeholders gain a better understanding of the problems to be tackled and how to address them.  
UNITA 2 fully embraces this perspective, limiting the project planning to the activity level, and giving the TT's full freedom to develop these activities into specific actions. This way, all the benefits of incremental and iterative development, and of frequent feedback, will permeate through the project. The Agile methodology is also an excelent way to channel and profit from the enormous creativity and potential of a project team formed by hundreds of academics, students and staff.  
It may happen, however, that certain events require structural changes in the project, beyond the range of what can be tackled at the TT level with individual actions. These changes may arise as a consequence of, for example:
* changes in scope,
* new requirements,
* identified issues or potential risks,
* political decisions that affect the project baselines (scheduling, staffing or budget).

This sort of changes must be discussed and approved at the MC level. Thus, when they are proposed by a Task Team, the TT co-leaders will commnicate them to the WP co-leaders, who will bring the proposal to the MC. If the decision has a strategic or political potential impact, the MC will also seek the approval of the GB.

== Dependencies ==

Dependencies in project management are links between different activities of a project. Dependencies in UNITA should be managed by WP and TT co-leaders, with support from the local project managers, for the following purposes:
* identifying sensitive milestones in the project's timeline where dependencies may engender critical situations;
* avoiding delays or alterations in the results/ actions of one task due to conections to another task's results/ actions.
* avoiding parallel work in different teams for the same purpose;
* developing complementary actions that serve the bigger picture of our alliance's objectives where doubling an action may occur due to various reasons;
* ensuring clarity and collaboration among task teams' work, for a better understanding of the project's general objectives and the role of the Task objectives in this bigger picture;
* ensuring coherence in an experimental project in which actions may develop in unplanned directions, which may coincide.

Dependencies should be identified and tracked during the whole duration of the project. To that end, a specific tab is included in each of the WP's Gantt chart, following the model of the table below.  
There, each dependency is classified into one of the following categories:
# Finish to Start (FtS): Activity B can only start when Activity A is finished (sequential)
# Finish to Finish (FtF): Activity B can only finish when Activity A has finished (can run in parallel)
# Start to Start (StS): Activity B can only start when Activity A has started (can run in parallel)
# Requires: Activity A requires from Activity B budget, tools, expertise, information sharing

The table below allows to define the current status of the dependency, define possible related issues and propose solutions. This way, the TT can easily establish the specific actions with which the dependency will be handled.