WHERE2

Version D6.2

ICT- 248894 WHERE2 D6.2: Project plan and risk management Contractual Date of Delivery to the CEC: M3 Actual Date of Delivery to the CEC: 19.01.2011 Editor:

Ronald Raulefs

Author(s):

Ronald Raulefs

Participant(s):

DLR

Work package:

WP6

Estimated person months:

0.5PM

Security:

RE

Nature:

R

Version:

D6.2

Total number of pages:

23

Abstract: The Project Quality Management procedures outlined in this document address methods for quality control, quality assurance, and continuous process improvement applied for the WHERE2 project.

Keyword list: Project Plan, Risk Management, Quality Management

Disclaimer:

Page 1 (23)

WHERE2

D6.2 Version D6.2

Executive Summary The Project Quality Management procedures outlined in this document address methods for quality control, quality assurance, and continuous process improvement applied for the WHERE2 project.

Page 2 (23)

WHERE2

D6.2 Version D6.2

Authors Partner

Name

Phone / Fax / e-mail

DLR Ronald Raulefs

Phone: +49 8153 282803 Fax: +49 8153 281871 e-mail: [email protected]

Page 3 (23)

WHERE2

D6.2 Version D6.2

Table of Contents List of Acronyms and Abbreviations.............................................................. 5 1. Introduction ................................................................................................. 6 2. Quality Management ................................................................................... 6 2.1 2.2 2.3

Quality Objectives ....................................................................................................................... 6 Quality Management Organisation.............................................................................................. 6 Quality Assurance and Control Activity...................................................................................... 7 2.3.1 Providing an Effective Project Management Structure ....................................................... 7 2.3.1.1 Project Management Team ...................................................................................... 7 2.3.1.2 Project Steering Board ............................................................................................. 7 2.3.1.3 Work Package Leaders ............................................................................................ 9 2.3.1.4 Task Leaders.......................................................................................................... 10 2.3.2 Ensuring Effective Communication between Partner ....................................................... 11 2.3.2.1 Communications and Reporting ............................................................................ 11 2.3.2.2 Project Meetings .................................................................................................... 12 2.3.2.3 E-Mailing and Mailing Lists.................................................................................. 12 2.3.3 Ensuring an Effective Project Monitoring......................................................................... 13 2.3.3.1 Planning and Reporting to the EC ......................................................................... 13 2.3.3.2 Periodic Reports..................................................................................................... 13 2.3.3.3 Final Reports.......................................................................................................... 13 2.3.3.4 Deliverable Handling............................................................................................. 13 2.3.3.5 Approval Procedure ............................................................................................... 14 2.3.3.6 Internal Reporting .................................................................................................. 14 2.3.3.7 Action Items........................................................................................................... 15 2.3.4 Ensuring an Effective Document Review and Management............................................. 15 2.3.5 Corrective and Preventive Activities................................................................................. 15 2.3.6 Regular Review of Risk Assessment ................................................................................ 15

3. Risk Management...................................................................................... 16 3.1

WHERE2 Risk Management Planning...................................................................................... 16 3.1.1 Risk Categories ................................................................................................................. 16 3.1.2 Definitions of Risk Probability and Impact....................................................................... 16 3.1.3 Roles and Responsibilities ................................................................................................ 17 3.2 Development of Risk Register................................................................................................... 17 3.2.1 Risk Identification............................................................................................................. 17 3.2.2 Risk Analysis .................................................................................................................... 18 3.2.3 Risk Response Planning.................................................................................................... 18 3.2.4 Risk Monitor and Control ................................................................................................. 18

4. Risk Register ............................................................................................. 19 4.1 4.2 4.3

Technical Risks ......................................................................................................................... 20 Organisational Risks.................................................................................................................. 22 External Risks............................................................................................................................ 23

5. References................................................................................................. 23

Page 4 (23)

WHERE2

D6.2 Version D6.2

List of Acronyms and Abbreviations Term AI MoM PMT PSB WP

Description Action Items Minutes of Meetings Project Management Team Project Steering Board Work Package

Page 5 (23)

WHERE2

D6.2 Version D6.2

1. Introduction The Project Quality Management procedures outlined in this document address methods for quality control, quality assurance, and continuous process improvement applied by the German Aerospace Center (DLR) for the WHERE2 project. Furthermore, the Project Risk Management procedures applied for WHERE2 are described in this document. A proactive risk management, including risk management planning, risk identification, risk analysis, risk response planning and risk monitoring, is implemented to meet the quality objectives of WHERE2.

2. Quality Management The project quality management processes include the following: 

Quality planning – Identify which quality standards are relevant to the project and determine how to satisfy them. Define quality objectives and the quality management organisation.



Quality assurance – Apply the planned, systematic quality activities to ensure that the project employs all processes needed to meet requirements.



Quality control – Monitor specific project results to determine whether they comply with relevant quality standards and identify ways to eliminate causes of unsatisfactory performance.

2.1 Quality Objectives The basic quality objectives of the WHERE2 project include: 

Achieve technical goals described in [Annex] within budget



Achieve planned milestones and deliverables on time



Achieve a high impact of project results through high quality results and dissemination efforts

2.2 Quality Management Organisation The idea of quality management ranks high in the minds of the DLR staff. The board of director itself constitutes the quality board of DLR. It is supported by a permanent working group of quality management representatives from all business units of DLR. Both contract management and the Institute of Communications and Navigation send members to this working group. The DLR contract management process is ISO 9001 certified. It is in charge of all administrative matters concerning the project management process and experienced in execution of EU contractual and financial matters. The DLR administration has recently won the prestigious Speyer quality award. The WHERE2 Project Management Team (PMT) is responsible for ensuring that the activities required by the specified quality system are planned, implemented and controlled and their progress monitored. The PMT is led by the Project Manager. The Project Manager is supported by the Technical Manager and the Financial Manager of the Institute of Communications and Navigation of DLR. Furthermore, all WHERE2 partners are involved in quality management, in particular the PMT, the Project Steering Board (PSB) and the Work Package (WP) Leaders and Task Leaders designated in Section 2.3.1. The primary functions and responsibilities of the WHERE2 quality management are: 

Maintain awareness of the project product and service quality.



Notify the project manager in a timely manner about existing or potential quality-related problems.



Make recommendations regarding quality management policies, methodology, processes, procedures, and standards.



Develop supplemental quality management procedures and standards, as needed.

Page 6 (23)

WHERE2

D6.2 Version D6.2



Administer a quality-focused problem management process, including monitoring and reporting on the problem resolution process.



Plan, conduct, and monitor the performance of activities.



Review project deliverables, and conduct reviews on delivered project documentation.



Establish processes and procedures to perform quality management activities.



Report findings to the project management team and identify corrective actions related to the product and process verifications.

2.3 Quality Assurance and Control Activity 2.3.1 Providing an Effective Project Management Structure 2.3.1.1 Project Management Team The project is led by a single entity, the Project Management Team (PMT), which is responsible for the running of the project and for providing an interface between the project, the European Commission, and the rest of the ICT programme. Given its role of project coordinator, DLR appoints its representatives forming the PMT (see Table 2.1), and three roles are defined: 

The Project Manager, who is the ultimate reference for the entire project. He has overall responsibility for the organisation, planning and control of the project as well as monitoring of the quality of the technical achievements. He is also the official contact point and interface with the European Commission and with the rest of the ICT Programme.



The Technical Manager, who assists the Project Manager in all tasks related to the project organisation, planning, control of the project as well as monitoring of the quality of the technical achievements. To ensure an always efficient management of the project, he will replace the Project Manager should the latter be unavailable for long periods of time.



The Financial Manager assists, supports and advises the Project Manager in all tasks related to legal, financial and contractual aspects of the project. Table 2.1 DLR staff involved in WHERE2 Quality Management Role

Name

Contact

Project Manager

Ronald Raulefs

Email: [email protected] Tel: +49 8153 282803

Technical Manager

Armin Dammann

Email: [email protected] Tel: +49 8153 282871

Financial Manager

Alexander Haidt (from 1.1.2011)

Email: [email protected] Tel: +49 8153 282851

2.3.1.2 Project Steering Board The Project Steering Board (PSB) is responsible for the successful completion of the project and the exploitation of its result. It is chaired by the Project Manager and consists of senior representatives, one per partner. The overall expertise of the board members covers all technical areas of the project (see Table 2.2). Furthermore, EC representatives will be invited as observer to the PSB meetings. The PSB supports the PMT in the administrative and technical decisions, as well as in the evaluation and planning of the main areas of the project. The role of the PSB includes the following: 

Monitor the progress of the project, including risk and quality management



Prepare the annual review



Update the work plan and select technical alternatives, if necessary



Take countermeasures to correct significant deviations from the work plan

Page 7 (23)

WHERE2

D6.2 Version D6.2



Approve significant changes of the work plan



Ensure the quality management of the project



Track and keep the costs within the defined budget



Resolve conflicts



Ensure compliance with legal and ethical obligations



Settle contractual matters Table 2.2 Project Steering Board Partner

Name

Contact

DLR

Ronald Raulefs

Email: [email protected] Tel: +49 8153 282803

AAU

Bernard H. Fleury

Email: [email protected] Tel: +45 99 40 86 29

ACO

Esther López Casariego

Email: [email protected] Tel: +34 942 764 400

CEA

Benoit Denis

Email: [email protected] Tel: +33 4 38 78 18 21

EUR

Dirk Slock

Email: [email protected] Tel: + 33 493008106

SIR

Yves Lostanlen

Email: [email protected] Tel: +33 223 480 561

UR1

Bernard Uguen

Email: [email protected] Tel: +33 2 2323 6033

IT

Jonathan Rodriguez

Email: [email protected] Tel: +351234377904

ITE

Damien Castelain

Email: [email protected] Tel: +33 2 23455840

SIG

Stavros Stavrou

Email: [email protected] Tel: +357-22-325240

UNIS

Yi Ma

Email: Y.Ma surrey.ac.uk Tel: +44-1483-689834

UPM

Javier Casajus-Quiros

Email: [email protected] Tel: +34915495700

UNIA

Witold Krzymien

Email: [email protected] Tel: +1-780-495780

HKC

Li Ping

Email: [email protected] Tel: + 852 2788-9574

TID

Jose Antonio Jiménez Holgado

Email: [email protected] Tel : +34 983367887

OTE

George Agapiou

Email: [email protected] Tel: +302106114663

UoA

Nancy Alonistioti

Email: [email protected]

Page 8 (23)

WHERE2

D6.2 Version D6.2

2.3.1.3 Work Package Leaders Each WP is led by a WP Leader (see Table 2.3). The role of a WP Leader includes the following: 

Responsible for the organisation of the work within the WP under his responsibility and for providing timely solution to any problem that may arise.



Establishes a WP Group comprising those members of the consortium directly involved in the WP.



Call for WP Group meetings when needed to review and progress the work.



Report periodically to the Project Manager on the status of the activities in the WP.



Ensure that all deliverables are prepared in accordance to the requirements for such documents and distributed in time. Table 2.3 Work Package Leaders Work Package

Name

Partner

Contact

WP1

Bernard Fleury

AAU

Email: [email protected] Tel: +45 99 40 86 29

WP2

Benoit Denis

CEA

Email: [email protected] Tel: +33 4 38 78 18 21

WP3

Dirk Slock

EUR

Email: [email protected] Tel: + 33 493008106

WP4

Esther Lopez

ACO

Email: [email protected] Tel: +34 942 764 400

WP5

Joaquim Bastos

IT

Email: [email protected] Tel: +351 234 377900

WP6

Ronald Raulefs

DLR

Email: [email protected] Tel: +49 8153 282803

Page 9 (23)

WHERE2

D6.2 Version D6.2

2.3.1.4 Task Leaders Since each WP is split into several Tasks, each Task is led by a Task Leader (see Fehler! Verweisquelle konnte nicht gefunden werden.), who assist the WP Leader in his management, control and reporting responsibilities.

Page 10 (23)

WHERE2

D6.2 Version D6.2 Table 4: Task Leaders

Task

Name

Partner

Contact

T1.1

Bernard Uguen

UR1

T1.2

Troels Pedersen

AAU

Email: [email protected] Phone: +33 2 2323 6033 Email: [email protected]

T1.3

Damien Castelain

MER

T2.1

Christian Mensing

DLR

T2.2

Marios Raspopoulos

SIG

T2.3

Igor Arambasic

UPM

T3.1

Joaquim Bastos

IT

T3.2

Tatiana K. Madsen

AAU

T3.3

Na Yi

UniS

T4.1

Armin Dammann

DLR

T4.2

Manuel Pezzin

CEA

T4.3

Marios Raspopoulos

SIG

T4.4

Esther Lopez

ACO

T4.5

Jose Antonio Jimenez Holgado

TID

T4.6

George Agapiou

OTE

T5.1

Joaquim Bastos

IT

T5.2

Ronald Raulefs

DLR

T5.3

Ronald Raulefs

DLR

T5.4

Joaquim Bastos

IT

T5.5

Damien Castelain

MER

Email : [email protected] Phone: +33 2 23455858 Email: [email protected] Phone: +49 8153 282878 Email: [email protected] Phone: +357-22-325240 Email : [email protected] Phone : +34 91 5495700 ext.4006 Email: [email protected] Phone : +351 234 377 900 e-mail:[email protected] Phone : +45 9940 8632 e-mail: [email protected] Phone +44 1483 68 4703 Email: [email protected] Phone : +49-8153282871 Email: [email protected] Phone : (33)(0)4 38 78 21 12 Email: [email protected] Phone: +357-22-325240 e-mail: [email protected] Phone +34 942 76 44 00 Fax: +34 942 76 44 03 e-mail: [email protected] Phone : +34 983367887 Fax: +34 983367564 e-mail: [email protected] Phone +30210 6114663 Fax: +30 210 6114650 Email: [email protected] Phone : +351 234 377 900 Email: [email protected] Phone: +49 8153 282803 Email: [email protected] Phone: +49 8153 282803 Email: [email protected] Phone : +351 234 377 900 Email : [email protected] Phone: +33 2 23455858

2.3.2 Ensuring Effective Communication between Partner 2.3.2.1 Communications and Reporting The information flow among the consortium is based mostly on Internet applications, e.g., E-mail, FTP, and web browsing. A common repository (BSCW Server) is implemented to contain and organise the document outcome of the project. This repository is accessible by the participants with authorised access.

Page 11 (23)

WHERE2

D6.2 Version D6.2

Major results will be made available with different degree of security depending on the criticality and the intellectual property rights of the consortium. A webpage for the project is created (www.ict-where2.eu) and updated in accordance with the evolution of the project. The coordination of the participants’ activities is based on exchanges of information, which are provided by the following means: 

Internal Management Report delivered every three month to the Project Manager by each participant and used by the coordinator to compile the Periodic Management Report.



Minutes of Meetings (MoM) approved by the Project Manager in occasion of all project and PSB meetings convened and chaired by a PMT representative.



Minutes of WP Group and Task Technical Meetings/Telephone Conference: The Project Manager can delegate WP or Task Leader to convey and chair dedicated progress meeting and to approve their minutes. The formal validity of the minutes starts from its distribution, within two days, of the meeting chair.



Technical Reports related to the list of Deliverables of any WP and are approved by the WP or Task Leader and the PMT.



Informal Communications are all other exchanges of information among the project participants. When in written form, they must include the Project and Technical Managers in the distribution list.

In general, all internal information is exchanged by E-mail. The minutes of all official meetings, including project representation (including PSB meetings, WP, Task and inter-WP meetings, inter-project meetings, internal coordination meetings and telephone conferences), are promptly distributed to all participants by the PMT. The PMT has established a project library for access by other participants and for the issue of information to external bodies as appropriate. This library has a formal numbering scheme for internal reports, programme deliverables, publications, and relevant reports from external sources. Whenever possible, project documents will be made available on electronic support in a non-proprietary format (e.g., PDF). 2.3.2.2 Project Meetings Physical project meetings take place approximately three to four times a year beginning with the Kick-off meeting from the 01.-02.07.2010 at Aalborg University in month 1. Objectives of the meetings are to discuss and present technical issues, overall project progress, and thus, identifying any divergence from the proposed work plan schedule. In such a case an action plan to ensure the project objectives has to be agreed in cooperation with the PSB. Project meetings are attended by: 

Project Manager



Technical Manager



WP Leaders



Persons, mainly carrying out work in the project period covered by the project meeting

Additional project meetings may be scheduled if necessary. For those meetings the project may make use of telephone conferences and internet meeting opportunities if possible. PSB/WP0 meetings will be held approximately 3 times a year and may be organized in conjunction (after or before) with project meetings. If possible, PSB meetings can be organised as telephone conferences or internet meetings. 2.3.2.3 E-Mailing and Mailing Lists Following E-Mail rules shall be considered: 

For all document distribution, a link to the BSCW Server project directory shall be used in order to keep the e-mail archives small.



The Mailing Lists should be used depending on the focus of the addressee.

Page 12 (23)

WHERE2

D6.2 Version D6.2

The following mailing lists have been set up for convenience:  [email protected]: This list comprises all people from the consortium involded in the WHERE2 project. 

[email protected]: This list comprises all people from the PSB.



[email protected]: This list comprises all people involved in WPx.

2.3.3 Ensuring an Effective Project Monitoring An effective and regular monitoring of the project activities is performed to ensure the conformance with the project plan by WP Leaders and the PMT. 2.3.3.1 Planning and Reporting to the EC Planning for the project is by consensus at both project and WP levels. For practical reasons, the responsibility for overall planning is delegated to the Project Manager and hence for detailed planning to the WP Leader as appropriate. Planning activities involving the interaction of the project with other bodies or ICT projects is under the responsibility of the Project Manager as first point of contact, who may delegate this responsibility to a team drawn from one or more project participants as appropriate. The following reports will be submitted to the EC in writing by means of registered mail with acknowledgement of receipt and will be also transmitted by electronic means (file formats will be MSWord compatible or PDF). 2.3.3.2 Periodic Reports The reporting period is a quarter of a year. The following periodic reports will be submitted shortly after the end of each reporting period: 

The Periodic Activity Report, containing an overview of the activities carried out during the reporting period, describes the progress in relation to the project objectives, the progress towards the milestones and deliverables set for the period, and any problems encountered and corrective actions taken.



The Periodic Management Report, containing a detailed justification of the costs incurred and of the resources deployed by each contractor linking them to activities implemented and justifying their necessity, the financial statements from each contractor and a summary financial report consolidating the costs of the contractors.



The Periodic Report on the Distribution of the Community’s Contribution, recording the distribution of funding to each contractor during that period.

2.3.3.3 Final Reports The following final reports, summarising the project’s activities over its full duration, will be submitted after the end of the project: 

A Final Activity Report, covering main aspects of the work, objectives, results and conclusions, including the publishable results of the Final Plan for Using and Disseminating the Knowledge.



A Final Plan for Using and Disseminating the Knowledge



A Final Management Report for the full duration of the project consolidating the claimed costs of all the contractors in an aggregate form covering the entire duration of the project, including the last reporting period.



A Final Report on the Distribution of the Community’s Contribution, consolidating the funding distributed to each contractor over the entire duration of the project

2.3.3.4 Deliverable Handling Deliverables are generated by the designated WP teams. Each deliverable will be prepared under the responsibility of the WP Leader, who will be charged with ensuring that all deliverables are prepared correctly and in time, after allowing sufficient time for comments and revision by all involved participants. Copies of the deliverable will be forwarded to the European Commission after approval and

Page 13 (23)

WHERE2

D6.2 Version D6.2

to all project participants by the Project Manager. If finally approved by all project partners and the EC, deliverables will be published via the project web site. 2.3.3.5 Approval Procedure In general, there are three types of documents produced in WHERE2: 

Publications



Standardisation/regulation contributions



Deliverables/information notes

Contributions from WHERE2 to international publications, conferences and workshops as well as standardisation/regulation bodies are from an approval perspective considered similar to deliverables: They shall be approved by the whole consortium according to a process described below in detail. Contributions to publications, conferences and workshops as well as journals are often preceded by the submission of an abstract to the organising body or programme committee. The initial submission of a paper or abstract to conferences or journals does not require approval from the WHERE2 partners. The submitting partner has to start the regular approval process in time (7 days) so that it is completed before the submission deadline for final papers or presentations. If the paper does not get the approval from WHERE2 partners, then the paper must be withdrawn, even if the paper has been accepted. Before a publication of such documents, a WHERE2 internal review process has to assure two issues: 

No violation of confidentiality or access rights of other partners



Clarifications of support or co-sourcing statement of other WHERE2 partners in case of contributions to standardisation/regulation bodies

Additionally, the general purpose of a review process is to improve the quality of the proposed text by eliminating errors or adding clarifications. All publications (including standards/regulations contributions) shall be listed on the public WHERE2 project webpage (www.ict-where2.eu/public_documents_papers.php) and shall be made available in pdf on the dedicated directory on the common repository. Approval Process: 

The contributions/publications are prepared in WHERE2 Work Packages in line with the contribution master plan and guidance.



Initial agreement on the contents is required inside the Work Package originating the contribution/ deliverable.



The agreed contributions are sent to each project partner for approval within 30 calendar days, using the following email-exploder: [email protected]



For all approvals electronic approval is preferred instead of physical meetings.



Contributions can only be prevented, WHERE2 the protection of another Party's Knowledge would be adversely affected by the proposed publication and/or, that the proposed publication includes the Confidential Information of another Party and the publication of such information would be contrary to the Legitimate Interests of that Party.

After approval of deliverables (and publications), deliverables are submitted to the Commission by the Project Manager and stored in the “Submitted deliverables” folder on the BSCW Server. If updates of Deliverables submitted to the Commission are deemed necessary they shall be labelled “version1.x” and stored on the respective WP deliverables folder. 2.3.3.6 Internal Reporting Internal activity reports are delivered every month to the Project Manager by each participant via the bscw server until the 5th working day of the following month. These monthly reports include a brief description of the work done in the respective month, deviations from the project work programme, and a reference to WP, Task or Action Items. These monthly reports are shared immediately with the WP leaders to allow shared access between the Project Manager and them.

Page 14 (23)

WHERE2

D6.2 Version D6.2

2.3.3.7 Action Items Action Items (AI) initiated during meetings or telephone conferences have to be recorded in the minutes of meetings with a detailed description and a sequential number. Each AI list record will contain: 

AI identifier / minutes reference



Brief description of action required



Actionee (Responsible company / person)



Due date



Status (Not Started – In Progress – Completed)

The actionee is responsible for ensuring that all responses are adequate for closing out the AI and the actionee shall inform the responsible person of the MoM about the progress of the action. The AI status update is performed by the responsible person of the MoM.

2.3.4 Ensuring an Effective Document Review and Management To ensure that WHERE2 documentation is completed to an adequate quality, in a timely manner and to ensure an effective document management, the following activities are performed: 

Use of a common repository (http://bscw.eurecom.fr/bscw/bscw.cgi/).



Use of document templates and conventions.



Thorough review of all documentation before release.



Project deliverables: Early publication of table of contents and regular publication of snapshots for a periodic review and assessment of the progress by the involved partners and the PMT.

The PMT ensures, by regular checks that these procedures are strictly adhered to in the project.

2.3.5 Corrective and Preventive Activities Action can be taken to increase the effectiveness and efficiency of the policies, processes, and procedures within the WHERE2 project. The quality assurance procedures are specifically designed to prevent that any output which is of an unacceptable standard. In the event that non-conforming items are identified, the reason for the fault shall be investigated. If necessary, preventive actions will be triggered in order that this known reason for fault will not be repeated. Potential reasons for non-conforming deliverables shall be detected and eliminated. The analyses of the process, service reports and related information shall be recorded for further investigations and improvements. All changes requests shall be addressed to the Project Manager.

2.3.6 Regular Review of Risk Assessment See Chapter 3 of this document.

Page 15 (23)

WHERE2

D6.2 Version D6.2

3. Risk Management Project risk management applied to WHERE2 includes the processes concerned with conducting risk management planning, identification, analysis, responses, and monitoring and control. The objectives of project risk management are to decrease the probability and impacts of events adverse to the project. Figure 3.1 depicts, in general terms, the overall risk management process that is followed in the WHERE2 project. Each of the risk management functions shown in Figure 3.1 are discussed in the following sections.

Risk Management Planning Output: Risk Management Plan

Develop Risk Register Risk Identification Risk Analysis Risk Response Planning Output: Risk register

Risk Monitor and Control

Output: Risk register (update)

Recommended preventive and corrective actions Requested changes

Update Risk Register Approved preventive and corrective actions Approved change requests Change Control

Figure 3.1: Risk management process.

3.1 WHERE2 Risk Management Planning Risk Management Planning is the process of deciding how to approach, plan, and execute the risk management activities in the WHERE2 project. The risk register ultimately contains the outcome of all risk management processes.

3.1.1 Risk Categories Risk categories provide a structure that ensures a comprehensive process of systematically identifying risks to a consistent level of detail. The risk categories may be revisited during the risk identification process. The risk categories for the WHERE2 project include: 

Technical risks



Organisational risks



External risks

3.1.2 Definitions of Risk Probability and Impact The risk analysis process requires that different levels of the risk likelihoods/probabilities and impacts are defined.

Page 16 (23)

WHERE2

D6.2 Version D6.2

For the WHERE2 project, the risk probabilities are categorized into four levels: 

Very Unlikely



Unlikely



Likely



Very likely

Furthermore, four impact levels of a risk are defined: 

Low Impact



Moderate Impact



High Impact



Unacceptable Impact

The risk impact is investigated in terms of three WHERE2 objectives: technical quality, cost, and schedule. Table 3.1 shows the definition of impact scales on these three objectives. Table 3.1 Risk Impact Matrix low

moderate

high

unacceptable

Technical Quality

Minimal or no impact

Reduction of one minor functionality

Reduction of one key functionality

Most project results are effectively useless

Cost

20% cost increase

Schedule

Not able to meet intermediate deadline. Deliverable or Milestone deadline not affected

Minor slip in Deliverable or Milestone deadline

Major slip in Deliverable or Milestone deadline

Cannot meet major project milestone

3.1.3 Roles and Responsibilities The WHERE2 Project Manager supported by the PMT is responsible for coordinating and monitoring all risk management activities. All individuals in the WHERE2 project team are involved in the identification, analysis, response planning, and monitoring of WHERE2 risks. The detailed roles and responsibilities for the different tasks are described in Section 3.2.

3.2 Development of Risk Register The risk register ultimately contains the outcome of all risk management processes. The risk register includes a list of identified risks together with their analysis and potential responses.

3.2.1 Risk Identification Risk identification is the first step in the risk assessment process. Risk identification can be done by reviewing documentation, gathering information, using checklists/questionnaires, or analysing the validity of assumptions on which the WHERE2 project is conceived. The risk categories defined in Section 3.1.1 provide a structure to identify risks in a systematic and effective way. Risks are identified by all individuals in the WHERE2 project team. Information is transferred to the Project Manager and a regular review of the risk register that includes the list of identified risks is performed during the project meetings.

Page 17 (23)

WHERE2

D6.2 Version D6.2

3.2.2 Risk Analysis Risk analysis is the evaluation of the identified risks to determine the likelihood/probability and impact of each identified risk and to establish a risk rating. The levels defined in Section 3.1.2 are used throughout the WHERE2 project. Risks with a high probability and/or high impact are identified as major risks that require particular attention. A quantitative analysis should be performed for the major risks, WHERE2 quantitative estimates on the probability, costs and time delays are given. All individuals in the WHERE2 project team shall inform the project manager about any event that implies a change in the risk assessment. A regular review of the risk register that includes the likelihood and impact of identified risks will be performed during the project meetings.

3.2.3 Risk Response Planning The approach to handle each significant risk will be developed after the project’s risks have been identified and assessed. There are essentially four techniques or options for handling risks: 

Avoidance - application of tasks to avoid the risk event



Mitigation – application of tasks to reduce the probability and/or impact of the risk to an acceptable level



Transfer – Transferring the risk simply gives another party responsibility for its management; it does not eliminate it. Transferring liability for risk is most effective in dealing with financial risk exposure.



Acceptance – If the identified risk is acceptable or no suitable response strategy has been identified, monitor and control this risk to ensure that the likelihood and impact remains on a low level.

For all identified risks, the various handling techniques should be evaluated in terms of feasibility, expected effectiveness, cost and schedule implications and the effect on the system’s technical quality and performance. The results of the evaluation and selection will be included and documented in the risk register. This documentation includes: 

Assigned responsibilities



Agreed-upon response strategies



Specific actions to implement the chosen response strategy



Budget and schedule activities required to implement the chosen responses



Their relationship to significant project activities/milestones



Recommended metrics for tracking the action



Residual risks that are expected to remain after the planned responses



Secondary risks that arise as a direct outcome of implementing the planned responses

The Project Manager, in close cooperation with the WHERE2 Project Steering Board and the concerned WP and Task Leaders, is responsible for developing and evaluating different risk handling strategies that are best fitted to the project’s circumstances. The selected strategies require approval by the WHERE2 Project Steering Board before being applied. The Project Manager is responsible for monitoring and controlling the performance of risk-handling actions.

3.2.4 Risk Monitor and Control The project work should be continuously monitored for new and changing risks. Risk monitor and control include the following tasks:

Page 18 (23)

WHERE2

D6.2 Version D6.2



Risk reassessment – Identification of new risks and reassessment of risks are often required. Risk reassessment is discussed in the WHERE2 meetings.



Technical performance measurement/accomplishments during the project execution are compared to the planned schedule of technical achievement.

Risk monitor and control results in an updated risk register and in recommended corrective and preventive actions. Risks are newly identified or reassessed by all individuals in the WHERE2 project team. Information is transferred to the Project Manager and a regular review of the risk register that includes the list of identified risks is performed during the project meetings.

4. Risk Register The following tables reflect the current state of the risk register. The risk register will be continuously updated during the project life. Figure 4.1 provides an overview of the current identified risks.

Figure 4.1: WHERE2 Risks: Overview.

Page 19 (23)

WHERE2

D6.2 Version D6.2

4.1 Technical Risks Risk 1.1 Description

Failing to define a precise and commonly accepted project contour Failing to define a precise and commonly accepted project scope and contour that defines scenarios to be considered and items to be developed.

Likelihood

Very Unlikely

Unlikely

Likely

Very Likely

Impact

Low

Moderate

High

Unacceptable

Action

Avoidance

Mitigation

Transfer

Accept

Response/ mitigation strategy

Through the review process and project meetings, a commonly agreed-on and clearly understood scope will be defined.

Risk responsibility

PMT and PSB

Risk 1.2 Description

Failing to define essential requirements 1) Failing to define requirements in a sufficient level of detail; 2) Failing to define requirements that match stakeholder desires.

Likelihood

Very Unlikely

Unlikely

Likely

Very Likely

Impact

Low

Moderate

High

Unacceptable

Action

Avoidance

Mitigation

Transfer

Accept

Response/ mitigation strategy

1) Consortium will liaise with other ICT projects. 2) A thorough literature review is done to include major previously defined and reviewed requirements. 3) T1.3 follows the standardization inputs from organizations like ETSI. WP1 participants (all)

Risk responsibility Risk 1.3 Description

Likelihood

Failing hardware platforms to demonstrate key algorithms Different hardware platforms will be enhanced to comply with the requirements. Hardware platforms can fail or be broken. Enhancements to the hardware platform are not significant enough. Very Unlikely Unlikely Likely Very Likely

Impact

Low

Moderate

High

Unacceptable

Action

Avoidance

Mitigation

Transfer

Accept

Response/ mitigation strategy

If the central unit of the cooperative positioning platform fails, only limited usability would be possible to show the joint effect of all platforms in realtime. Offline the processing could be performed by the active partners of WP2. A reduced set of demonstrations would be possible.

Risk responsibility

If single platforms fail the accuracy of the demonstrated scenario suffers or the demonstration fails totally. Here, multiple hardware platforms reduce the risk of total failure. Some partners work on a same access technology, and therefore, responsibilities can be transferred. Project Manager, WHERE2 partners involved in demonstration activities

Page 20 (23)

WHERE2

D6.2 Version D6.2

Risk 1.4

Failing to coordinate with related activities

Description

Failing to coordinate WHERE2 activities with related developments and missing to consider previous results and lesson learned.

Likelihood

Very Unlikely

Unlikely

Likely

Very Likely

Impact

Low

Moderate

High

Unacceptable

Action

Avoidance

Mitigation

Transfer

Accept

Response/ mitigation strategy

Ensure close collaboration with related activities including: 1) EC projects: contacts to other projects shall be established 2) Perform a thorough literature review and generating a list of activities WHERE2 has to keep track of.

Risk responsibility

PMT

Risk 1.5

Failing to meet technical and quality objectives

Description

Failing to meet technical and quality objectives, resulting in a low impact of the project results.

Likelihood

Very Unlikely

Unlikely

Likely

Very Likely

Impact

Low

Moderate

High

Unacceptable

Action

Avoidance

Mitigation

Transfer

Accept

Response/ mitigation strategy

Apply and continuously refine the processes defined in this Deliverable

Risk responsibility

Project Manager, all WHERE2 participants

Risk 1.6 Description

Unavailability of Radio Access Technologies for VHO in WP4 Failing to find Radio Access Networks or Radio adapters to perform the vertical handover in WP4. Very Unlikely Unlikely Likely Very Likely

Likelihood Impact

Low

Moderate

High

Unacceptable

Action

Avoidance

Mitigation

Transfer

Accept

Response/ mitigation strategy

The demonstration scenario defines two types of Radio Access Technologies (RATs); one for communication and one for positioning. This gives the flexibility to the partners to perform positioning using the Technology of interest (as defined in the Annex) whereas communication (IP connection and thereafter VHO) will be achieved using available technologies (e.g. WiFi, WiMAX or any other technology which will be available at the time). Project Manager, WP4 members

Risk responsibility

Page 21 (23)

WHERE2

D6.2 Version D6.2

4.2 Organisational Risks Risk 2.1

Non-availability or movement of key personnel

Description Likelihood

Non-availability or movement of key personnel involved in WHERE2

Very Unlikely

Unlikely

Likely

Very Likely

Impact

Low

Moderate

High

Unacceptable

Action

Avoidance

Mitigation

Transfer

Accept

Response/ mitigation strategy

A certain level of overlap in the key personnel expertise and background and the presence of many experienced and large companies in the consortium will permit to react to this risk with a minimal impact on the project schedule and organisation. Active spreading of knowledge within the WHERE2 project team has a high priority. Even multiple industry partners are involved, and would cope with the loss of a single one to deliver the key messages to the industry. Project responsible of all Partners

Risk responsibility Risk 2.2

Communication problems

Description

Communication problems in the WHERE2 team may arise since the project team is deployed over several locations.

Likelihood

Very Unlikely

Unlikely

Likely

Very Likely

Impact

Low

Moderate

High

Unacceptable

Action

Avoidance

Mitigation

Transfer

Accept

Response/ mitigation strategy

Efficient means of communication have been set up, including regular progress meetings, regular telephone conferences, mailing lists, WHERE2 repository. Identifying similar or complementary working fields to build small teams in each WP. PMT

Risk responsibility Risk 2.3

Underestimation of required effort

Description

The features needed to meet the requirements defined in Annex 1- Description of work may be beyond what the development team can deliver in the time available.

Likelihood

Very Unlikely

Unlikely

Likely

Very Likely

Impact

Low

Moderate

High

Unacceptable

Action

Avoidance

Mitigation

Transfer

Accept

Response/ mitigation strategy

1) Precise and realistic definition of the project scope 2) Continuously monitor the progress of the project, periodically review the scope of the project and assign levels of importance if needed.

Risk responsibility

PMT, PSB, WP and Task Leaders

Page 22 (23)

WHERE2

D6.2 Version D6.2

4.3 External Risks Risk 3.1

Dependencies of external strategic decisions

Description

Decisions that WHERE2 can hardly influence might affect the WHERE2 activities and/or impact the WHERE2 results. WHERE2 depends in particular on decisions made within the 3GPP/LTE joint undertaking.

Likelihood

Very Unlikely

Unlikely

Likely

Very Likely

Impact

Low

Moderate

High

Unacceptable

Action

Avoidance

Mitigation

Transfer

Accept

Response/ mitigation strategy

Promote the WHERE2 approach within the technical and scientific community.

Risk responsibility

All WHERE2 participants

5. References [Annex]

Annex I – Description of Work of Contract 248894 for “WHERE2 – Wireless Hybrid Enhanced Mobile Radio Estimators – Phase 2”.

Page 23 (23)