UNITA Agile Management Guide

1. Introduction

The UNITA Agile Management Guide defines the operational functioning of UNITA. Updated from phase one of the project, it allows each UNITA contributor to work efficiently and in the respect of UNITA criteria. The new guide reflects UNITA's commitment towards agile management in the development and functioning of an open, participative and multilingual European University of border, rural and mountain regions. This guide is alive and can be modified according to the project needs. This document will be updated, if necessary, through the lifecycle of the project extending the information given, including relevant issues and changes in the project or procedures. Each time the document is updated, all partners will be duly informed about the updates and the changes made with respect to the previous version.

Context and objectives

Context and necessity

The updated Management Guide has beed developed considering that:

• The first phase of the European Universities Alliance UNITA (Nov. 2020- Oct. 2023) was concerned with initiating and setting up a functional framework for alliance cooperation, integration and governance from a managerial perspective. The alliance comprised 6 partner higher education institutions. As this was the initial phase, adjustments and changes were frequent in terms of role definition and allocation, management flows and interactions among responsible parties.
• The second phase of the EUA UNITA (November 2023- 2027, ongoing) is focused on deepening the integration of the alliance, consolidating it, while simultaneously extending it to 10 partner universities, 2 university associated partners and 1 partner in the form of our legal entity UNITA GEIE. The focus of this phase turns to seamless processes and agile approaches to management of teams and activities.
• UNITA's management does not refer solely to the projects which are central to our alliance, supported under the umbrella of the Erasmus+ European Universities Initiative, but also to what we have defined as the UNITA constellation of projects. This concept relates to complementary projects tackling specific matters of interest to our alliance in a more extensive manner while also being linked to the EUI projects of our alliance.
• The initial six founding partners of UNITA have created a legal entity under the form of a European Economic Interest Grouping, to which the new full partners will adhere in the second phase of the alliance. The UNITA Universitas Montium EEIG is a full partner of the current EUI project of the alliance. The role of the legal entity is to contribute to the alliance's sustainability.
• The UNITA Alliance enlargement from 6 to 13 partners requires a disciplined, efficient and transparent working method while avoiding useless formalities or unclear processes. Agile methodology for project management, with some adaptations, can provide an efficient working method and mindset for our challenging objectives in the next 4 years.

Objectives of the UNITA Agile Management Guide

1. Highlight the relevant managerial aspects of the alliance's EUI project, applicable as well to all UNITA constellation projects.
2. Set the rules and responsibilities of the partners for the purpose of ensuring a good quality and progress of the work envisioned in the UNITA actions.
3. Summarize all the required knowledge for an agile management of the project.
4. Contain all information related to the management structure, processes, documentation, collaboration tools to be used, reporting procedures, etc.
5. Develop a set of basic principles for the management of UNITA cooperation overall.

Relation to Other Project Documents

In the event of discrepancy between documents, this Management Guide is overruled by the Grant Agreement (s, valid for each project implemented by the alliance) including Annexes and the Consortium Agreement with possible addenda.

Agile project management in UNITA

The UNITA Alliance enlargement from 6 to 12 partners requires a more disciplined working method while avoiding useless formalities. To achieve this, UNITA decided to draw inspiration from an existing method: the PM AGILE method. This method, strongly influenced by the LEAN philosophy, encourages adaptive planning, evolutionary development, early delivery and continuous improvement. It encourages rapid and flexible responses to change. To understand the difference between an agile approach and a traditional one in project management, the iron triangle provides a clear explanation.

The iron triangle in project management

The difference between agile and traditional approach is that with a traditional approach, scope is fixed and won’t change, but the time and cost can change. This means that projects can often deliver late or over budget affecting quality negatively. In agile approaches, the pyramid is inverted. Time and cost are fixed (e.g., time-boxed short cycles called Sprints), but the scope remains variable and can change. This ensures quality remains stable by prioritizing high-value features within constraints. With some adaptations, it can provide an efficient working method and mindset for our challenging objectives in the next 4 years.

Key characteristics of Agile are:

• Focus on delivering value early and frequently. Decisions are based on what is known.
• Close collaboration between all parties involved. Continuous stakeholder involvement at all levels.
• Plans are created with the involvement of team members.
• Incremental development with short cycles.
• Scope management by continuous (re)prioritization of the Work Items. Embracing change, continuous learning and improvement.
• Just enough documentation and control.

This method aims to continuously improve and streamline all project processes.

What is AGILE for UNITA?

This type of project management encourages collaboration and continuous improvement. It is referred to as an agile team. AGILE consists of dividing the project into several phases or cycles, and the various project activities are broken down into several specific, simple and prioritised actions.

1. Definition of an AGILE TEAM

Agile teams work in a highly collaborative way, adopting the most effective communication techniques for their situation and striving to work together as closely as possible. The aim is to ensure that:

• Everyone feels part of the team, moving in the same direction.
• The team includes all the people needed to complete the task. An autonomous team must have the skills and knowledge needed to get the job done. Specialists may be called in if necessary.
• Each team member contributes according to his/her means. The team is made up of multidisciplinary members;
• The team is self-organised. The people best placed to plan and organise the work are those who actually do the work. This results in more accurate estimates, more realistic deadlines and greater team commitment to the plan;
• The team maintains a steady pace; everyone works closely together, avoiding discouragement.

2. Definition of an ACTION

1. An action may be defined as the result of a breakdown of a general activity in specific and simple operations, to be executed within one month, with a clear outcome.
2. An action is defined and detailed by an explicit specification sheet (cf the UNITA’s project management tools)

3. Definition of a CYCLE

1. Every month (at least), the task co-leaders plan, organise and coordinate a meeting with all the members of the task: the task meeting. A cycle is defined as the period between two task meetings. During this period, the team must work on the action(s) chosen at the meeting at the start of the cycle. At the end of the cycle, the actions are reviewed at the next meeting. Based on the progress made, the team then decides what action to take next: continuation, reorientation, stopping, etc. The team implements the decisions taken on the actions in progress during the next cycle.
2. A week before the task meeting, the co-leaders meet to prepare for the meeting and draw up the pre-minutes. They make these pre-minutes available to the task team members.
3. Depending on the actions to be implemented, they may decide to divide the work into sub-groups and schedule interim meetings.

Reference material

Although this Management Guide is self-contained, interested readers may deepen thier knowledge about Agile project management in the Agile PM2 guide, which extends and enhances the PM2 Methodology with Agile principles and practices.

Other bibliographic references: Articles in english to help you understand and go further

• *Agile processes: a unifying approach for the future of projects*. Casanova, P. (2013). Paper presented at PMI® Global Congress 2013—EMEA, Istanbul, Turkey. Newtown Square, PA: Project Management Institute.
• *The iron triangle and agile*. Nagappan, R. (2020). Available at: [1]
• *A Catalogue of Agile Smells for Agility Assessment* — Telemaco, Ulisses; Oliveira, Toacy; Alencar, Paulo; Cowan, Don. IEEE Access, 2020, Vol.8, p.79239-79259
• *A critical examination of recent industrial surveys on agile method usage* — Stavru, Stavros. The Journal of Systems and Software, 2014-08, Vol.94, p.87-97
• *AGILE SOFTWARE DEVELOPMENT: MODEL, METHODS, ADVANTAGES AND DISADVANTAGES* — Džanic, Amel; Toroman, Amel; Džanic, Alma. Acta Technica Corvinensis, 2022-10, Vol.15 (4), p.95-100
• *An evaluation of the degree of agility in six agile methods and its applicability for method engineering* — Qumer, A.; Henderson-Sellers, B. Information and Software Technology, 2008-03, Vol.50 (4), p.280-295
• *Challenges of adopting agile methods in a public organization* — Jouko Nuottila; Kirsi Aaltonen; Jaakko Kujala. International Journal of Information Systems and Project Management, 2016-01, Vol.4 (3), p.65-85
• *Collaborative agile learning in online environments: Strategies for improving team regulation and project management* — Noguera, Ingrid; Guerrero-Roldán, Ana-Elena; Masó, Ricard. Computers and Education, 2018-01, Vol.116, p.110-129
• *EVALUATION OF THE MOST USED AGILE METHODS (XP, LEAN, SCRUM): RELATED TO THE CONCEPT OF TOYOTA QUALITY* — Nathan-Regis, Bodje N'Kauh; Balaji, V. International Journal of Engineering Science and Technology, 2012-01, Vol.4 (1), p.23-23
• *Systematic Literature and Expert Review of Agile Methodology Usage in Business Intelligence Projects* — Wulandari, Hapsari; Raharjo, Teguh. Journal of Information Systems Engineering and Business Intelligence, 2023-11, Vol.9 (2), p.214-227
• *The Role of Psychological Safety in Implementing Agile Methods across Cultures* — Thorgren, Sara; Caiman, Elin. Research Technology Management, 2019-03, Vol.62 (2), p.31

Conference papers in english

• *Agile Methods: The Gap between Theory and Practice* — Conboy, Kieran; Eckstein, Jutta; Baumeister, Hubert. *Extreme Programming and Agile Processes in Software Engineering*, 2004, p.316-316
• *An Ideal Process Model for Agile Methods* — Visconti, Marcello; Cook, Curtis R.; Bomarius, Frank; Iida, Hajimu. *Lecture Notes in Computer Science*, 2004, p.431-441

Book

• *The Scrum Guide* — Jeff Sutherland & Ken Schwaber. Scrum.org; URL: [2]
• *Succeeding with Agile* — Mike Cohn. Addison-Wesley; November 2009. ISBN: 0321579364
• *Kanban: Successful Evolutionary Change for Your Technology Business* — David J Anderson. April 2010. ISBN: 0984521402
• *Essential Scrum: A Practical Guide to the Most Popular Agile Process* — Kenneth S. Rubin. Addison-Wesley Professional; 5 August 2012. ISBN: 0988262592
• *Lean vs Agile vs Design Thinking* — Jeff Gothelf. Gothelf Group; 2017. ISBN: 13:978-1541140035

Book in french

• *La boîte à outils de la conduite du changement et de la transformation* — Autissier, David; Johnson, Kévin J.; Metais-Wiersch, Emily; Moutot, Jean-Michel; 2019
• *La boîte à outils du chef de projet* — Maes, Jérôme; Debois, François; 2023

Website

• [3]

Youtube material

In english

• what is Agile ?
• Agile principles and values in five minutes
• How the agile methodology really works
• What is Agile Methodology?
• What is Agile Development Methodology?
• Introduction to PM2 Project Management Methodology WEBINAR
• Introduction to PM2 Methodology

In french

• L' Agile qu'est ce que c'est et pourquoi choisir ce mode pour conduire un projet ?

Agile leadership in UNITA

To be effective in agile project management it is not sufficient to provide a set of techniques and tools to the teams (the doing agile). It is even more important to develop an agile mindset to become agile leaders (the being agile). UNITA adopts and implement by proper training and coaching sessions the principles of agile leadership provided by the not-for-profit organisation Agile business consortium. The table below shows how the nine principles of agile leadership align with the key concepts of Communication, Commitment and Collaboration:

The Nine Principles of Agile Leadership under the 3 C's are fully described below:

Communication

1. Actions speak louder than words Agile Leadership is about not only driving and promoting change, it is also about being the change. Those who lead by example and actively engage in their own development, inspire people. This is through action rather than words; as Gandhi said, “Be the change you want to see”. Agile Leaders develop themselves to be humble and empathetic by demonstrating virtues such as compassion, kindness and care for their colleagues. Inspiring leaders work on themselves first before working on others.

2. Improved quality of thinking leads to improved outcomes Agile Leaders value high quality thinking which will result in meaningful action. Agile Leaders view problems from many different angles. They take input from those closest to the problem and this goes some way to ensuring that they are in touch with reality rather than relying solely on electronic information to inform their decision making. This also means allowing thinking time and focusing on the highest priorities at any given time.

3. Organisations improve through effective feedback Receiving feedback can often be perceived as a negative experience, so Agile Leaders lead the way by courageously soliciting meaningful, useful and timely feedback from peers and other colleagues. While requesting feedback is important, Agile Leaders take time to ensure that they are visibly responding to the suggestions made by their colleagues in order to close the feedback loop. Agile Leaders model giving effective feedback that is open, honest and respectful.

Commitment

1. People require meaning and purpose to make work fulfilling Agile Leaders focus on building and sharing a common understanding and purpose. There is a vision of change that is meaningful and applicable to the organisation. The work of the Agile Leader is to be aware of what is in the hearts and minds of their colleagues, and then to unify and align those values into inspired action.

2. Emotion is a foundation to enhanced creativity and innovation Agile Leaders inspire others to bring their best selves to their work. They understand that emotion is an important part of the human experience, and when individuals work with their emotions, they achieve more of their potential. Innovation and creativity rely heavily on respect that the Agile Leader encourages by being accessible, open, honest and transparent whilst expecting the same from others.

3. Leadership lives everywhere in the organisation Agile Leadership should permeate all aspects of an organisation or change initiative. Realising the leadership potential of all its people helps accelerate the organisation’s ability to learn and adapt. The work of an Agile Leader is to develop depth in the organisation’s leadership capability by providing opportunities for their people to lead. Mentoring tomorrow’s leaders in the principles and practices of servant leadership sows the seeds for the Agile culture to thrive.

Collaboration

1. Leaders devolve appropriate power and authority Agile Leaders recognise that people work best when they are enabled, engaged and energised. Empowering individuals is a necessary skill of the Agile Leader as they balance the emerging needs and tensions of the organisation. Agile Leaders recognise that empowerment is not an “all or nothing” concept. Instead, it is a continuum of leadership behaviour that responds to the current context for change.

2. Collaborative communities achieve more than individuals Agile Leaders build communities based on high trust, respect and meaningful working relationships. Their role is to provide those communities with all that they need to operate efficiently but then to let them function autonomously within their boundaries. The Agile Leader understands that forgiveness, positivity, generosity and gratitude are important parts of a healthy working environment. The healthy functioning of the group together with the preservation of psychological safety allow the Agile Leader to encourage learning and development whilst also balancing sustained output and performance for the benefit of the organisation.

3. Great ideas can come from anywhere in the Organisation People who are close to a problem usually have the best ideas about how to solve it. Agile Leaders allow themselves to be open to the influence and ideas of others, regardless of their status or position. To this end, the Agile Leader stops, listens and gives time to really hear the thoughts and ideas for improvement from their colleagues. Even if some ideas are not used, the Agile Leader encourages a continuous flow of creativity by helping people to understand which ideas were useful and which were not.

Feedback

Organisations improve through effective feedback

Receiving feedback can often be perceived as a negative experience, so Agile Leaders lead the way by courageously soliciting meaningful, useful and timely feedback from peers and other colleagues. While requesting feedback is important, Agile Leaders take time to ensure that they are visibly responding to the suggestions made by their colleagues in order to close the feedback loop. Agile Leaders model giving effective feedback that is open, honest and respectful.

Plan to give feedback

In this step, we’ll look at a method for thinking about how to plan what to say when you give feedback. This is the COIN feedback method (Carroll, 2018, p. 62). This method helps make connections between what you want to say in your feedback and what the recipient is looking for, as well as what the organisation needs. It presents four steps to giving effective feedback, as shown in the diagram below.

The COIN Feedback Method. Adapted from Mukherjee, S. (No date) *The COIN Conversation Model. Real-life Examples of Employee Feedback for Remote Teams*. [4]

The elements are as follows:

C is for connection and context

Try to establish what the recipient’s goals are in relation to the feedback conversation – what you want to deliver may not immediately fit with their requirements. For instance, if they want to know how to master a new skill, you need to connect the feedback to situations where you have actively witnessed them trying to work towards this target. To give context, you might say something like, ‘We have talked about you mastering a new skill in x, and last week I noticed you were starting to apply this in situation y‘ (if you don’t have a recent example, connect it to a past situation such as an earlier project). You can then start to link this to your feedback. Without establishing connection and context, you might find people become disconnected or confused by your feedback.

O is for observation

Here you make factual observations on someone’s work behaviour based on accurate and specific observations. If your observations are vague then this can lead to the recipient feeling confused or even ‘attacked’. Try to keep the observations ‘quick, accurate and to the point’ (Carroll, 2018, p. 63). You might say: ‘I noticed that you have not been to the last two morning standups and the project is due to go live next week’. The statement is based on fact and doesn’t seek to express a value judgement.

I is for impact

The impact of the behaviour you are feeding back on can be positive, negative or a hybrid of the two. Stick to the facts and help your team understand when their actions have negative effects. For example, you might say: ‘There were payments not paid on time to vendors on the project, which caused the project to fall behind. This had a negative impact on our relationship with the client.’

N is for next steps

At this point, you should collaborate with the feedback recipient to identify what action needs to take place, or what behaviours need to change or develop. Thinking about the future as part of your feedback can have a positive impact and help you get support from the recipient. For example, if a member of your team proposes a new tool for collaboration to help solve some of their time keeping and accountability issues, then you could say: ‘The idea of a collaboration tool is great and would help out the rest of the team. This will keep us communicating regularly and tasks will not be forgotten. When do you think you could demonstrate this to the rest of the team?’ (Carroll, 2018).

Tips for using COIN

The COIN steps are designed to help you provide objective information about what the person you are feeding back to is currently doing. It also gives you opportunities to collaborate on ideas about how things can improve in the future. The idea of this approach is that it ‘creates learning relationships and stimulates everyone’s desire for more feedback in your organisation’ (Carroll, 2018, p. 67). Carroll (2018) suggests that when giving feedback, you create a script in which you plan what to say around each of the COIN elements before giving your feedback.

Ideas for individual and team-based feedback

Often the word ‘feedback’ has instant negative emotional connotations for people based on their previous experiences. You may dread feedback rituals, and when this comes in the form of feedback that has been saved up for a long period of time, it can feel like an ambush rather than supportive. However, if feedback is carried out frequently, carefully and constructively, it can have a positive long-term effect on the recipient and on the culture of the team and the organisation.

Ideas for giving individual feedback

Giving individual feedback can often feel daunting, but remember that giving feedback is a two-way process. We must all learn to both give and receive feedback.

Here are some helpful hints when giving feedback. Make sure that:

1. You, as the feedback provider, are credible and trusted in the eyes of the recipient.
2. The feedback is conveyed with good intentions.
3. The timing and circumstances are appropriate.
4. The feedback is given in an interactive way, with a chance to raise questions.
5. The feedback message is clear.
6. The feedback is helpful to the recipient.

Used effectively, individual feedback will help people become more aware of their performance in the team.

Ideas for team-based feedback

Agile approaches to feedback encourage collaborative methods. Retrospectives are used by the team as a way to pause, consider their performance and discuss ways to continually improve. This technique is based on American writer and therapist Virginia Satir and colleagues’ work which explores the past in order to improve the future (Satir, Banmen, Gerber and Gomori, 1991). In a retrospective, four questions can be used to surface and communicate issues:

• What went well?
• What didn’t go so well?
• What have I learned?
• What still puzzles me?

(Source: Lyons and Waite, 2013)

Here are some further factors to remember when planning feedback:

• Make room in the plan: How often is it appropriate for your team to carry out this type of reflection?
• Action the learning: How will the learning from the feedback be fed into the next work phase? What needs to change?
• Deal with the issues: How can you solve the things that still cause puzzlement?
• Celebrate the successes: How do you recognise and reward team success?

It is important to remember that feedback is not about attributing blame. Both teams and individuals will be seeking feedback in order to gain awareness of themselves and how they are performing, and to use this for learning. Individual and team feedback should also be clear and ideally everyone should contribute.

One final model is the ‘rose, thorn and bud’ model

This is a simple, structured reflection which could be used when you are time poor (Gonzalez, 2020). Identify:

1. A rose: A highlight, success or small win.
2. A thorn: A challenge, or something you need help with.
3. A bud: A new idea or something you are looking forward to.

References

• Lyons, C. and Waite, L.M. (2013) ‘The four questions of a retrospective and why they work’, InfoQ, 3 June. Available at: [5]
• Satir, V., Banmen, J., Gerber, J., and Gomori, M. (1991) The Satir model: Family therapy and beyond. Palo Alto, CA: Science and Behavior Books.
• Gonzalez, A. (2020) A mindful way to reflect: rose, thorn, and bud. Available at: [6]
• [7]
• [8]
• [9]

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.

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.

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:

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:

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: 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

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 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 WP, Task
• The minutes of the various meetings (GB, MC, WP, 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:

1. Agile board view (Kanban board)
2. List view
3. 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.

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: 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 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 by the TTL, providing the necessary context.
• The WP co-leaders consult the 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 board is communicated to the TT co-leaders, so that they can include it on the agenda for the next task meeting.
• The decision is communicated to the 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:

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.