Deliverable 1.1 Description of Quality Management and Risk Processing Responsible partner: BOKU - University of Natural Resources and Life Sciences, Vienna Institute for Transport Studies
List of abbreviations MC WP Management Committee Work Package Table of contents 1 Content of this deliverable... 3 2 Project Governance... 4 3 Communication strategy... 5 4 General remarks concerning deliverables and publications... 6 5 Deliverables: Review process and timelines... 8 6 Risk management... 10 Annex... 11 List of tables Table 1: Project partner responsible to write and review the deliverables... 8 Table 2: List of identified risks... 10
1 Content of this deliverable This deliverable describes the Quality Management and Risk Processing -procedure applied in the project Guide2Wear. The part of this deliverable referring to Quality Management helps guaranteeing that all objectives of the project will be reached and all project results meet the requirements in terms of their content and quality. The Risk Processing -procedure allows identifying risks early, implementing appropriate measures to avoid a risk to get a problem by counteracting the risk or discussing opportunities to solve existing problems. A Quality Management is needed to define responsibilities and standards. The part of the deliverable concerning the Quality Management contains information and guidelines to ease, manage and control the quality of the day-to-day work. This document sets out the quality management practices and provides assurance that quality requirements are planned appropriately and measures are taken for protecting the smooth progression of the project. The Risk Processing -procedure is important since every project is subject to several risks. This applies even the more to scientific projects which have by definition unsecure results to a certain extent. Additionally, the risk increases with the number of institutions involved and when the scientific or professional background of the involved persons and institutions differs. Also their nationality might produce problems in term of the language. This deliverable lists certain risks that might occur during several project steps and explains how they can be handled.
2 Project Governance The number of tasks within the six work packages and the number of participants is limited. This allows for a slim management structure. The internal structure of the project consortium was fixed during the project kick-off. The project partners compose the management committee. It is responsible to make all project-relevant decisions. Within the WP1 Management, additional tools and procedures were defined based on the two aforementioned documents which allow an effective coordination within and between the project participants. Overall financial and project management is provided by the coordinator (Fraunhofer IVI). In addition to the daily business, the coordinator is responsible for troubleshooting, resolving conflicts and searching for solutions in cases where aspects overgrow the responsibility of the WP-leader. The project coordinator will be the main interface to the ERA-NET office. All partners are responsible to maintain the contact to the governmental funding agency and fulfil all country-specific requirements on their own. All project-relevant decisions will be made by the project management committee (MC). The MC consists of a representative of each partner. Meetings will take place in regular intervals of about six months during the project realisation period. The project coordinator will be the chair of the committee and the meetings. Decisions of the MC will be made as a majority-decision. Decisions will not be made if the majority of the MC-members is missing. Each member of the MC present or represented will have one vote. In case of a non-resolvable stalemate, the chair will have a vote which counts twice. In-between the committee meetings, the WP-leaders decide on every-day questions and give appropriate information to the coordinator. If essential questions or risks occur, the MC additionally meets in a phone conference organised by the coordinator. Not all partners are involved in all work packages. Thus, WP teams including all partners participating to a certain WP are created. Their activities will be managed by corresponding work package leaders. Their roles are designed to interlink, so that they are mutually supporting, and to provide an efficient information flow between the different elements of the project (WP, tasks, deliverables), and the different levels of management (overall project, WP teams, etc.).
3 Communication strategy To ensure the permanent overview on quality assurance activities and to guarantee an effective exchange of information different tools will be used within the project. The following communication strategy was set up: A contact list of all project partners with name, institution, telephone and e-mail address is available on the internal project platform and was directly sent to all project partners. The project website includes an internal platform for data exchange and joint documents. It is used for the exchange of information, data and literature. All official documents for administration, reporting and dissemination are placed on this platform. Each partner involved gets access rights by the coordinator to read, copy, upload and modify documents on the platform. The WP leaders are responsible for updating and maintain their WP folders. Meetings will be held continuously in order to ensure information exchange, to coordinate cooperation between work packages and partners and to identify and tackle problems in time. This includes MC meetings twice a year and WP meetings. MC meetings will be organised by the host and the project coordinator, WP meetings by the host and the responsible WP leader. WP meetings can be organised as single events, in connection to the MC meeting or as telephone conference. For all meetings, an agenda has to be sent by the project coordinator (MC meeting) or the WP leader at least one week before. The agenda has to indicate date, location and an overview of the topics to be discussed (including task number). The coordinator or the WP leader is responsible for writing the minutes and making them available for all partners. This ensures traceability of decisions and inform partners, who were not able to join a meeting, about the outcomes. Minutes shall include at least the names of participants and of the keeper of the minutes, date, time, duration and location. Additionally, the topics and problems discussed and the decisions made have to be summarized. Telephone conferences will be held, if necessary.
4 General remarks concerning deliverables and publications The authors are responsible for the content of each deliverable, report and publication. All reports should meet a set of requirements, namely completeness, correctness and punctuality. The content of the documents have to address all aspects related to the purpose of the research. The following criteria should be assessed during the review processes of deliverables and reports: Completeness and methodological framework soundness: The contents of the deliverables have to be reliable and should reflect the objective results of the study. All background information and quotations used in the reports should be appropriately documented in the reference list. Foreground information should be supplied clearly and should be easy to understand. Methodologies should be described in a comprehensive and complete way so that misinterpretation can be avoided. Accuracy: The document should provide information that focuses on the key issues and objectives of the research. It should be written in a way that takes into account the standards of its target audience. Depth: The document should provide in depth information that is needed for the objectives of the report. Structure: It is important that documents have a uniform appearance and structure. Therefore, it is necessary to use the template for deliverables. It will be provided to the partners on the internal area. This template specifies the structure, layout and appearance. Writing features: The language and writing features should have a good quality and the text should be easy to understand. Preferably the text should be checked by a native speaker before it is sent out or is published. Punctuality: For each deliverable the date of submission is defined. The author is responsible to enable the conduction of the review process as described in this manual before the date of submission. The deliverables are referenced after a clear and simple scheme. The file name is structured as follows including the project acronym, the deliverable number, the date of the last modification and the acronym of organisation doing the last modification. Once the deliverable was approved, the date and partners acronym can be deleted. Thus, this deliverable was named during the process of its development for example G2W_1.1_20141126_BOKU and is submitted as G2W_1.1. If a second version of a file is finalised within the same day, the second partner adds his acronym after the name of the first partners acronym. Official Project Deliverables should be structured as follows: First page including the project logo, the number and title of the deliverable and the name of the responsible institution Second page of each draft deliverable will be the review protocol (see below) List of abbreviations, table of contents, list of Figures and list of Tables Reference list Annexes
Further publications will be written in Guide2Wear. All aspects related to publications such as the procedures for informing partners about the publication, the contents that can be published and also the opportunities of further partners to join a publication are defined in the consortium agreement. These rules also refer to conference participations.
5 Deliverables: Review process and timelines All deliverables must undergo a review process before being submitted. A certain partner is responsible to write a deliverable. This partner can ask for support of other partners where appropriate. The WP leaders are responsible for the progress of the documents, written in the corresponding work package, their quality and delivery in time. After finalizing a draft version of each deliverable, one of the partners, who was not involved directly into the creation of the document, has to review the draft version. This partner has to send back feedback and recommendations on the deliverable to the responsible partner and the WP leader one week after the draft version was sent to him. Main steps of the reviewing process are: 1. The WP leader sends out the draft of the deliverable to the reviewing partner, at least two weeks before the deadline. 2. The reviewing partner sends back the reviewed deliverable with comments and the deliverable review report within one week. 3. The author of the deliverable applies the review comments; the author looks for an agreement with the reviewer concerning comments that are not applied. 4. The deliverable is send to the coordinator on the last working day before the deadline and is uploaded to the EPSS portal by the coordinator. Each second page of a draft of deliverables is the Review Communication Protocol. This will help to maintain the overview of the reviews. After completion of the final version of the deliverable, this second page can be deleted and the date of the creation of the deliverable should be added to the front page. The reviewer can give comments on several ways. Principle remarks, considerations and reviews are written in an extra document to be attached to the draft or in an accompanying mail. Direct remarks are given by inserting comments directly into the draft document or by adapting words in the track change mode. The following table shows all deliverables of the project Guide2Wear. Besides the number and the title of the deliverable, also the month of submission and the responsible partner are listed. Additionally, one partner is assigned to each deliverable, which is responsible for an internal review. All other partners will, of course, also check content and quality, but this specific partner has a particular role as first grade peer reviewer. Table 1: Project partner responsible to write and review the deliverables No. Title Month Autor Reviewer 1.1 Description of Quality Management and Risk Processing November 2014 BOKU Fraunhofer 6.1 Project Website November 2014 FACTUM Fraunhofer 6.2 Dissemination and exploitation plan November 2014 FACTUM VTI 6.3 Project Flyer December 2014 FACTUM All
3.1 2.1 Overview on functionalities of technologies for seamless travelling Analysis of wearable devices and relevance for travel January 2015 InnoZ BOKU March 2015 InnoZ CodeSyntax 1.2a Milestone Report March 2015 Fraunhofer All 2.2 2.3 Seamless travel: Customer requirements Exploration of data protection and privacy laws May 2015 VTI BOKU May 2015 FACTUM TML 6.3 Project Newsletter June 2015 FACTUM All 4.1 Prototype Definition and Specification July 2015 Fraunhofer FACTUM 1.2b Annual Report August 2015 Fraunhofer InnoZ 3.2 Impact assessment of technological interventions on mobility patterns December 2015 InnoZ VTI 6.3 Project Newsletter December 2015 FACTUM All 4.2 Prototype Software April 2016 Fraunhofer/ CodeSyntax BOKU 1.2c Milestone Report April 2016 Fraunhofer All 3.3 5.1 Overview on mobility patterns and requirements of lead users Handbook on user characteristics and user requirements for seamless travelling June 2016 InnoZ CodeSyntax July 2016 BOKU Fraunhofer 6.4 Final Conference July 2016 FACTUM All 6.5 Business plan July 2016 TML BOKU 5.2 Recommendations for organisational and legal improvement August 2016 FACTUM VTI 1.2d Final Report October 2016 Fraunhofer All
WP/Task Reporting partner Partner addressed Impact Probability 6 Risk management Risk management refers to the process of identifying a risk, pretending the risk to get a problem and solving a problem otherwise. A risk is defined as the fear that a project task cannot be conducted as planned in terms of its content, quality or timeline. The main risks that likely can occur within the project Guide2Wear were identified during the proposal stage. They are summarised in a list of risks (Table 2). Table 2: List of identified risks No. Keyword(s) 1 Lack of coordination 1 IVI, WP- Leader All High Low 2 Partner default All All All High Low 3 Under-resourced WP/Task/Partner All All All Medium Low 4 WPs delays All All All Low Medium 5 Mobility patterns cannot be detected from the automatic data collection 3 All BOKU, InnoZ High Medium 6 7 8 Prototype cannot be realized Lack of visibility of project achievements Low impact of projects output 4 All IVI Medium Low All All All Medium Low All All All High Low If the situation arises, that a risk gets a problem, the affected partner(s) has to initiate steps to solve the problem. He has to inform the WP leader and the project coordinator immediately by submitting the problem reporting form (Annex 1). By submitting the form, the problem gets official. The responsible WP leader, the partner reporting the risk, the coordinator and all partners affected build a task force in order to overcome the risk. No concrete procedure can be offered at this point since most problems call for a tailor-made solution. However, the project experience of all partners should set the consortium into the position to solve all risks and problems occurring.
Annex Annex 1: Form for problem reporting Keyword(s) Reporting partner Date of reporting Partner(s) addressed Impact Number of the risk reported Problem refers to WP/task Timeline to solve the problem Probability Problem description Recommended steps to solve this problems (Partner addressed/action)