cordis | european commission - d27 quality plan v3 final · 2016-05-31 · d27 v2 – detailed task...

..........

. .

Deliverable

27

Detailed Task plan and Quality Schedule for the final phase of

. . . . . . .

p

WP18 WP Programme Management

Prepared for the Europ

A trust and Contract Managerocessing in on-demand cre

Michael Wilson, CCLRC

March 2006 Version 2

TrustCoM ment framework enabling secure collaborative business ated, self-managed, scalable, and highly dynamic Virtual

Organisations

ean Comm

P

SIXTH FRAMEWORK PROGRAMME

RIORITY IST-2002-2.3.1.9

ission under FP6 Contract No. 01945 as a deliverable form

D27 V2 – Detailed Task plan and Quality Schedule for the final phase TRUSTCOM – 01945 march 2006

LEGAL NOTICE

The following organisations are members of the Trustcom Consortium: Atos Origin, Council of the Central Laboratory of the Research Councils, BAE Systems, British Telecommunications PLC, Universitaet Stuttgart, SAP AktienGesellschaft Systeme Anwendungen Produkte in der Datenverarbeitung, Swedish Institute of Computer Scence AB, Europaeisches Microsoft Innovations Center GMBH, Eidgenoessische Technische Hoschschule Zuerich, Imperial College of Science Technology and Medicine, King's College London, Universitetet I Oslo, Stiftelsen for industriell og Teknisk Forskning ved Norges Tekniske Hoegskole, Universita degli studi di Milano, The University of Salford, International Business Machines Belgium SA .

© Copyright 2006 Atos Origin on behalf of the Trustcom Consortium (membership defined above).

Neither the Trustcom Consortium, any member organisation nor any person acting on behalf of those organisations is responsible for the use that might be made of the following information.

The views expressed in this publication are the sole responsibility of the authors and do not necessarily reflect the views of the European Commission or the member organisations of the Trustcom Consortium.

All information provided in this document is provided 'as-is' with all faults without warranty of any kind, either expressed or implied. This publication is for general guidance only. All reasonable care and skill has been used in the compilation of this document. Although the authors have attempted to provide accurate information in this document, the Trustcom Consortium assumes no responsibility for the accuracy of the information.

Information is subject to change without notice.

Mention of products or services from vendors is for information purposes only and constitutes neither an endorsement nor a recommendation.

Reproduction is authorised provided the source is acknowledged.

IBM, the IBM logo, ibm.com, Lotus and Lotus Notes are trademarks of International Business Machines Corporation in the United States, other countries or both.

Microsoft is a trademark of Microsoft Corporation in the United States, other countries or both.

SAP is a trademark of SAP AG in the United States, other countries or both.

'BT' and 'BTexact' are registered trademarks of British Telecommunications Plc. in the United Kingdom, other countries or both.

Other company, product and service names may be trademarks, or service marks of others. All third-party trademarks are hereby acknowledged.


Deliverable datasheet

Project acronym: TrustCoM Project full title: A trust and Contract Management framework enabling secure collaborative business processing in on-demand created, self-managed, scalable, and highly dynamic Virtual Organisations

Action Line: Activity: Work Package: Task:

Document title: Detailed task plan and Quality schedule for the

final phase Version: 2 Document reference: D27 Official delivery date: July 2005 Actual publication date: (V1 September 2005) May 2006 File name: Type of document: Report

Nature: Restricted to the project members, European Commission and their appointed reviewers.

Authors: Michael Wilson

Reviewers: BT

Approved by:

Version Date Date

Sections Affected

V.2 30/03/06 All


Table of Content 1 Introduction ................................................................................................................................. 5

2 Detailed planning and monitoring of individual lines of work ................................................. 6

3 Risk management ...................................................................................................................... 12

3.1 Lack of Industrial and Business relevance .................................................................... 12

3.2 Technical Feasibility Risks .............................................................................................. 14

3.3 Lack of influence of Social and Business results on technical work............................ 16

3.4 Lack of availability of appropriate resources................................................................ 16

3.5 Divergence of a partner’s business interests from the project plan ............................ 17

3.6 Problems in managing ystem integration....................................................................... 18

3.7 Dissemination and Exploitation preparation................................................................. 19

3.8 Escalation Procedures...................................................................................................... 20 3.8.1 Escalation Procedures within the project. .................................................................. 20 3.8.2 Escalation procedures within partner organisations................................................... 21

4 Quality management of processes and deliverables................................................................. 22


1 Introduction Deliverable D1 laid out the detailed plan for the first 18 months of the project and the overall quality plan for the entire project. Deliverable D27 V1 presented in July 2005 laid out the plan until June 2006. This document is merely an update to the covering those aspects that only arise after the first year of the project and mainly those which may have a significant impact in the final 16 months of the project. This is not a replacement for D1 as a general plan but a supplement to it. This deliverable is divided between the three objectives of the programme co-ordination activity:

o Detailed planning and monitoring of individual lines of work o Risk management at technical level o Quality management of processes and deliverables

These all build on the agreed description of work which states what the project is trying to achieve and how it will be done. A balance needs to be struck between imposing very strict management plans and controls on the project, and a lighter form of management which allows more creative freedom and personal motivation to individuals. Following the risk management analysis, action line 2 has been managed in a strict fashion to address convergence integration risks, whereas the remainder of the project is being more lightly managed to promote divergent creative potential.


2 Detailed planning and monitoring of individual lines of work

The description of work divides the project into activities as shown in Figure 1. Action lines, and activities are used to group workpackages across the overall project.

Figure 1: The overall project plan – as submitted in the DoW, April 2006.

The project is divided into phases to control the risks. The first phase addressed the foundation of the project for team building and to establish a common base for requirements and technical development during the first six months. The second phase addressed the development of a common framework to which all teams were working until month 18. The third phase focuses on the implementation of a reference implementation of the framework and two testbeds (aggregated services and collaborative engineering) which act as a focus for the technical development. This lasts from month 18 to 36. The final phase addresses the evaluation of the framework and tools through industrial demonstrators or business pilots which can assess the framework, the reference implementation and the business risks and benefits of the applications. The demonstrator phase lasts from months 18 to month 40, overlapping with the second phase. The phases are not strictly sequential, and a waterfall lifecycle is not being used since there are internal feedback loops at many stages to reduce the risks of the initial requirements, and early technical design choices being inappropriate for the business solutions.


Figure 2 – Workpackages in AL3 – Demonstration and Business Pilots

The DoW of March 2006 proposes and extension of the project and a structure for AL3 which are new to previous versions of this detailed plan until month 40. The demonstrator phase is itself broken down into three workpackages to address the migration, implementation and final evaluation of the approach. While these activities continue on beyond the 36 month deadline of the original project, supporting activities for management must also continue in parallel.

Figure 3: Workpackage and task cycle in Action Line 1 - Framework


Action line 1 addressing the Framework is divided into workpackages for each subsystem with integration workpackages for the architecture and framework itself to ensure that the overall descriptive documentation is consistent and tells the whole story rather than just the story of each sub-system. However, each of the main workpackages in action lines 1 and 2 are following an iterative six monthly development cycle. Figure 3 shows this breakdown for only one workpackage, but it applies to all of those active in this period. The workpackages for each sub-system end at month 30, leaving only the integration activities to continue to month 36 producing the final version of the Framework deliverable consistent with the reference implementation.

Figure 4: Workpackage and task breakdown for AL2 – Implementation

Action line 2 includes both the reference implementation of the framework and the development of the two prototype testbeds (collaborative engineering and aggregated services for e-learning). The workpackage structure of WP1 is repeated so that the same teams are working on both modifying the framework with feedback from the detailed design and implementation whilst undertaking that design and implementation for each subsystem. This structure is used to address the risk that the framework will become separate from the implementation, but it increases the risks associated with integrating the implementation. To mitigate this risk, Wp34 has been introduced to manage the integration, and it has been put under the control of an industrial software development manager from Microsoft, some of whose costs are covered from the management line of funding to ensure that he is focussed on the integration, and enforces a strict integration plan. The integration plan involves the three phases shown in blue as tasks: three use


cases have been designed as integration scenarios which pass through three phases of integration of the subsystems.

Figure 5: Workpackage and task breakdown for AL4 – Dissemination & Standards

Action Line 4 is intended to develop the influence of the TrustCoM approach during and after the project. It addresses dissemination of the results during the project, and planning for exploitation after the end of the project through the partners and through standardisation. As the project continues the dissemination will move in style from addressing academic conferences, to producing archived journal articles (WP14 Dissemination); from initial identification of product groups in consortium member companies to serious interaction with them and planning of adoption of the TrustCom technology into their business plans (WP15 exploitation) ; from an awareness of related standards to submission of proposals into existing standards activities (WP13 Standardisation) – using existing representation in standards bodies, and not using project effort or the long term project commitment to active participation in those bodies.


Figure 6: Workpackage and task breakdown for AL6 – Socio-Economic Research

Action Line 6 addresses the legal and business context in which the project is operating. These aspects need to have considerable impact on the technical developments. They start is independent lines of work, but as the project progresses, the technical participants become more aware of them, and the participants in these lines and the technical ones will work together more actively to ensure the collaboration and inclusion of these aspects in the TrustCoM results.

Figure 7: Workpackage and task breakdown for AL7: Roadmapping

AL7 addresses the roadmap for the project as a whole, that is to say it addressed the initial requirements which the project addresses, the initial technical state of the art, and during the project the relation between the technical development within the project and the


outside world. The only remaining task in the action line is for the project scientific co-ordinator (Theo Dimitrakos) to produce a final technical roadmap showing the relation of the project technologies to those developed outside which is due in July 2006.

Figure 8: Workpackage and task breakdown for AL8 – management.

The final Action Line addresses the management of the project. The current document is the final deliverable of WP18 on Programme Management, although this activity continues to co-ordinate the technical management of the project until it ends. WP19 addressing the General Management will also continue to produce periodic activity reports, financial statements, and respond to requests from the European Commission until the end of the project. The project management structure of an executive board, and workpackage leadership will continue under this overall direction. A final deliverable detailing the experiences and lessons learned from managing an integrated project will be produced following the interim one at month 24. This will be available for those proposing to take on this role in future proposals under FP7 as guidance.


3 Risk management The plan stated in the description of work, and described in the previous section is intended to apply the available resources to achieve the objectives of the project. However, there are many eventualities that may endanger achievement of the objectives, and we must be prepared to respond appropriately This chapter outlines the risks that have been identified, the mitigating actions that have been taken, and the contingency plans that have been put in place. Among those contingencies is the option of escalation of issues both within the project and within the organisations in the consortium, which are also defined. After the 24 month point in the project the following categories of risks have been identified as the major ones to the success of the project:

o Lack of industrial and business relevance o Technical feasibility risks o Lack of Influence of social and business results on technical work o Divergence of partner’s business interests from from project plan o Problems in managing system integration o Lack of availability of appropiate resources o Dissemination and exploitation preparation

Each of these risk categories, the actions to be taken to mitigate them, and contingency plans are described below.

3.1 Lack of Industrial and Business relevance The project is developing technology to meet a perceived future market opportunity. The risk here is that the assumptions about the future market and business requirements prove to be incorrect, and specifically that the project outputs will not meet any exploitable plans. Given the predominance of technical staff on the project the risk arises that either the anticipated requirements for products and services supporting VOs may need to be revised as the market matures and clarifies during the project, or that the innovative technologies that we are working towards are not optimal for potentially exploitable products. Actions taken to mitigate the risk:

• Development of initial project scenarios

• Market Study


• Two application testbeds are being used to focus the technical development on the market as understood, representing distinct classes in the spectrum of VOs:

o Collaborative engineering – long term relationships, complex businesses processes crossing enterprise boundaries

o Dynamic service aggregation for e-learning – short term relationships established on the fly, joint responsibility

• Industrial Advisory Board is used to provide guidance on other application markets

• Commission Reviewers provide feedback

• Internal dissemination, demonstration and elicitation of feedback within TrustCoM partner companies

• Exploitation plans under development with product divisions in companies

• IBM are conducting studies with their suppliers, BT and BAE Systems involving business and contract staff

These act as a clear focus for developments in the project and can be used to steer the direction of the project and resolve trade-offs and priorities in design. However, do the project outputs really meet the perceived market need? Evidence suggests that the SOA using web services element of the perceived market is developing an impact. The following quotes from one issue of the Financial Times support this (10 May 2006):

• “Web Services are beginning to stick and yield benefits”

– Jerry Norton, director of strategy for financial services, Logica CMG.

• “We leverage SOA in our investment bank and are looking for ways to leverage it across the enterprise.”

– Martin Davis, Corporate CIO, Wachovia Corporation.

A quotation from the same source supports the requirement to meet the security need:

• “What are my top three concerns? Information security, information security, information security.”

– Harvey Koeppel, CIO Citicorp Global Consumer Group.

A statistic on the growth of on-line fraud in the UK extrapolated to 2006 reinforces this need:

– 2004 - £37m

– 2005 - £360m (KPMG Research, 2006)

– 2006 - £3.6 billion (extrapolated)

The technical commitment to reputation services was supported by the updated review of the state of the art undertaken in autumn 2005 which showed that ERP providers are already incorporating supplier qualification and contract management services into their products with plans for further sophistication. Feedback from the Industrial Advisory Board suggests that SAP as a major ERP provider are following


this route to the extent that they find it hard to see how TrustCoM provides technology that is different from what they have already planned. As a project partner this is an opportunity for the project technology to be adopted by SAP rather than a problem. The reality of the first market of shared risk VO for SME remains open to question. There is considerable support from the EC for the support of shared risk VO for SME aggregation, but there is little market support visible so far. However, within the project BT consider that the provision of services for such aggregation of SME is a feasible market opportunity that they still wish to consider which provides an exploitation route to this market. Although the mitigating actions are in place, and both the market and planned technology appear appropriate, there is still the risk that they will not match. In this case the contingency plans are that:

• SAP will incorporate parts of the technology in their ERP products;

• BT will incorporate parts of the technology in the “21st Century Network” next generation converged network services platform and develop services for secure dynamic aggregation of applications consisting of components provided by independent enterprises;

• BAE Systems will derive experience of using SOA to work with their partners in collaborative projects and supply chain companies putting them in a position to define requirements for procurement of technology elsewhere;

• Atos Origin will be able to use the experience gained on this project of SOA technologies in future consultancy;

• Microsoft will adopt parts of the security technology into future enterprise products;

• Research teams (IC, UoK, SINTEF, ETH, UoM, SICS, CCLRC) will each take their specific tools further in future research activities.

• The project publications and input into standards will focus the community a small step towards a common approach to secure SOA which moves towards the solution of the major problem in its adoption.

The result of even some of these outcomes would justify the investment in the TrustCoM project. There is one subsidiary risk remaining in this class – that the demonstrators are implemented and evaluated, and show that the solution developed does not meet the business needs of the organisations or their customers. However, even this negative conclusion would provide valuable information guiding business decisions and development plans.

3.2 Technical Feasibility Risks The project is designing and implementing code for a set of sub-systems which can be integrated with application-specific services within the framework of the overall


architecture to produce applications serving VOs. There are risks associated with the ability of each sub-system to implement the functionality required of it by the framework specifications. The Roadmap deliverable D22 addressed the technical risks associated with the individual technologies, with the adoption of WS* specifications, and with competing technologies, so that analysis will not be repeated here. The remaining risks covered here are primarily due to work packages with mutual dependencies being conducted in parallel. The plan throughout the project has been that Action Lines 1 and 6 would develop advanced ideas in parallel with prototype implementation of more basic versions in AL2. Part of the reason for doing this is that requirements for the framework and legal and business issues need input from experimentation in AL2, while AL2 needs a definition of the framework to implement the prototypes. Consequently, The project has not defined a list of requirements that can be traced and ticked off when they are met by a sub-system. This style of working needs continuous effective communication between the teams involved. Such risks include:

• Divergent directions taken by different work packages working in parallel

• Gaps in coverage emerging due to different assumptions and expectations: for example AL1 and AL6 examine the management of contracts including terms and conditions, whereas AL2 has only so far addressed simple metrics in SLAs

Overcoming these problems was one of the motivations to align the workpackages in AL1 and AL2 with architectural sub-systems. Mitigating actions –

• The same teams are working on corresponding work packages (and hence sub-systems) in AL1 and AL2 so they state the requirements that they have to meet.

• Convergence of specification and implementation of the sub-systems is being quided by a set of graduated scenarios in the manner of the agile software development paradigm. The definition of the third phase of the scenarios will address the functionality in each sub-system in terms of the full framework.

Contingency action – o If the escalation procedures outlined below fail to rectify problems, we will

refuse to authorise funding to partners who fail to produce acceptable implementations of subsystems that will integrate, through the authority of the General Assembly as defined in the Consortium Agreement.

• If the functionality of a sub-system or service-oriented component diverges from the requirements of the framework as a whole or of other sub-systems relying on it, then the partners responsible will have to take responsibility for exploiting it according to their individual plans independently of the rest of the framework. This may, for example, result in creating of a third demonstration work package in AL3..


The project is continuously considering actions to mitigate this risk further.

3.3 Lack of influence of Social and Business results on technical work The IP was designed to integrate technical developments with research in both legal issues and business issues associated with the market to which the technical work is directed. The style, outputs, method of work and other aspects of this non-technical work is very different from the technical work. The project is mainly staffed by technical people who are unaccustomed to these other styles of work, and are unused to integrating it into their activities. The risk is that the technical and non-technical streams of work will not integrate; i.e. that the technical work is not influenced by the business, legal and social issues, and that the non-technical streams do not truly examine the impact of existence of the technical solutions on the business, social and legal context. This risk has been emphasised by the Commission reviewers at all reviews. Mitigating Actions –

• The programme manager has worked with the non-technical researchers to formulate their results in a way the technical staff can understand.

• The legal work is being integrated into the GVOA through a small working group;

• The business research is being integrated into the reputation management service through a small working group.

Contingency plans –

• Accept that the legal and business research has had visibility outside the project and has been successful in the communities where it was undertaken and has been seen, even if it has had less influence on the overall project than it could have had.

3.4 Lack of availability of appropriate resources The project budget has been consistently underspent by most partners who have been unable to allocate the staff resources planned. Several research teams have new projects starting between June and October 2006 onto which they will want to transfer staff, thereby further reducing the effort available to the project. The risk is that the project will not be able to provide the resources required to meet its plans. Planning and development of the demonstrators has been consistently delayed both by the failure to provide a thorough enough reference implementation, and by a failure to establish the required demonstration and evaluation environment in those organisations undertaking the business pilots. The risk is that the demonstrators will not be able to deliver usable results on the business benefits and costs of applying the technology developed. Mitigating actions –


• Funds have been transferred from underspending partners to those able to provide more effort at the end of both the first and second year of the project when new a new DoW has been submitted;

• Quarterly reporting of effort and funds by partners into the project portal is mandated;

• The project has requested and been granted a four month extension without additional funding to defer the demonstration phase;

• Quarterly reporting of the state of funding will be made by the project manager to shame those who have not reported, and to show the state of resources to enable further transfers;

• Further movement of funds during the final 16 months of the project will be undertaken if the effort is available in some partners while others continue to underspend.

Contingency actions –

• Escalation within partners line management of the need for effort and cost reporting will be required if they are not reported in a timely fashion;

• Introduce a system of penalties against partners who under-perform or fail to work constructively towards the collective goals of the project through the authority of the General Assembly as defined in the Consortium Agreement.

• Mandatory re-allocation of funding among partners by the decision of the General Assembly as defined in the Consortium Agreement without the consent of the partner involved.

• Introduce a panalty system against partners who fail to report their expenditure through the authority of the General Assembly as defined in the Consortium Agreement.

3.5 Divergence of a partner’s business interests from the project plan The IP is operated by staff from a consortium of organisations which have their own objectives in being part of it. For example, the universities are evaluated on their publication output, while company R&D groups may be evaluated by the patents they file, or the transfer of their technology to product groups; the research laboratories may be evaluated by the funding that they receive, and not by the outputs from that funded research at all. The project is entering its final 16 months so that deadlines are become realistic, resources are becoming more scarce so priorities have an impact on what can be done. At this stage of the project the choices partners make in the light of their own intentions will have a visible impact on the project. The risk that arises is that partners will allocate resources according to their own priorities rather than to meet the priorities of the project as a whole. The result will


be to bring about the risks identified elsewhere of failing to provide the required functionality in a sub-system, or failing to integrate the subsystems as an integral part of the overall framework. The first option for action would be to escalate the prioritisation in partner organisations. However, the effect of this may be for more senior management to perceive TrustCoM as conflicting with their own interests and confirming low prioritisation of TrustCoM work in competition for resources. For those organisations which rely upon continued EC funding it would be easy to explain that failure to deliver on this project will reduce the probability of future funding – but unfortunately there is no feedback loop in the proposal evaluation process that influences future funding choices based on previous performance unless it is a severe failure in financial administration. It would be convenient to be able to argue that the prestige received by an individual or team for being part of the achievement of a successful project will have a greater impact on their career than the priorities of their own organisations – but this is also false, and would increase tensions between project and partners. It would be easy to argue that the social pressure of their peers in the project, or a sense of duty to the project leadership would influence them towards the greater good of the group, but an IP is too large, and the staff turnover has been too frequent to create a cohesive social group. Mitigating action:

• The programme manager must convince all partners that the priorities of the project are in fact in the interests of their organisations;

• Escalation of the decision to remove funding from partners who are not working to the project plan and allocate it to others by the decision of the General Assembly as defined in the Consortium Agreement without the consent of the partner involved – even if they have spent the money.

Contingency actions –

• Accept that if individual partners are succeeding by their own standards, then the project is having an influence and achieving the sum of the achievements of individual partners – that is, the project is a portfolio of loosely related sub-projects each run by an individual partner, and not a single project.

3.6 Problems in managing ystem integration The revised description of work for 2005, and that for 2006 which followed it structured AL2 into workpackages for each technical component of the architecture aligned with the workpackages in Al1 to mitigate the risk of the framework and implementation diverging. This was identified at the time of drafting as increasing the risk of each component being developed in isolation, thereby increasing the risk of failure to integrate them. This has clear consequences:


Individual partners may develop subsystems that meet their needs but do not integrate – this risk is considered above; Generic implementation may not be integrated and cannot be released as open source software Integration of prototypes too late for evaluation, and to be used as a basis for demonstrators Mitigating actions:

o Adoption of a ‘agile development’ style of project management with emphasis on early and frequent integration testing;

o Close monitoring and tight management of the integration plan by Alexey Orlov from Microsoft;

o Staged integration plan through three phases of three scenarios; o Focussing project resources and senior staff on the integration management

– using both authoritative and negotiation styles; o Introduction in the 2006 DoW of a workpackage staffed by Atos Origin to

package the open source release; o Regular coding meetings of the software implementers to check that their

code can work together and resolve bugs face to face. Contingency actions -

o Refuse to authorise funding to partners who fail to produce acceptable implementations that will integrate, through the authority of the General Assembly as defined in the Consortium Agreement.

o The project is continuously considering actions to mitigate this risk further.

3.7 Dissemination and Exploitation preparation The remaining risks are related to the further exploitation of the results after the project:

• No route to exploitation for partners

• Insufficient communication between research and product divisions

• No champion in company to drive technology transfer TrustCoM results are incompatible with company’s business strategy

• No early adopters to drive exploitation

• Customers unaware of benefits of TrustCoM technology

• Failure of TrustCoM to influence open standards

• Failure of TrustCoM to influence the direction of future European research

The project has been very active in dissemination in general. However, the risk remains that the dissemination is too much directed at European technical


conferences and workshops and is not addressing the audience required to ensure adoption and assimilation of the TrustCoM results into the mainstream computing business or into the application domains used for the prototypes. This problem has been addressed in the revised Dissemination plan, D23, but the project is aware of the risk, and action to mitigate it is being monitored. The commercial partners in TrustCoM have also been very active in internal and customer-oriented dissemination events with the intention of encouraging exploitation on behalf of their companies. Mitigation actions –

• Industrial partners encouraged to talk to product divisions. The results of such dialogues will be monitored and reported via the TrustCoM exploitation work package and deliverables;

• Dissemination plan to produce brochures and roadshow materials in a product style for communication to product divisions;

• Project funding allocated for IAB attendance to encourage a champion to come forward;

• Dissemination plan aimed at demonstrations and business audiences. Contingency plans –

• The industrial companies will use their own mechanisms to prepare the market for exploitation of the results..

3.8 Escalation Procedures There are two classes of escalation procedures: Those within the project and those within the organisations to which the partners belong. The main sanction available to TrustCoM management is resource re-allocation. Consequently only those problems that may be resolved through this means are subject to escalation within the project. Other conflicts and failures to deliver by partners will be resolved by escalation within the partner organisation.

3.8.1 Escalation Procedures within the project. The consortium agreement and description of work define the following escalation procedures within the project: Conflicts within workpackages are addressed by the WP leader. Conflicts between workpackages are addressed by the Programme Manager – Michael Wilson (CCLRC). Conflicts that cannot be resolved through these means are escalated to the Project Executive Board (consisting of the project manager, workpackage leaders and project scientific leader). Teleconferences can be called by any EB member of the EB to resolve such conflicts.


Conflicts that cannot be resolved by the EB can be escalated to a general assembly of the project where the membership and conflict resolution procedures are defined in the consortium agreement. There has been no need to call a general assembly meeting of the project so far. The General Assembly is composed of the General Co-ordinator, the Financial Co-ordinator, the Programme Manager and one representative of each contractor, each having one vote. In voting the decisions shall be taken by a majority of two thirds of the votes of Parties present or represented by proxy at a quorate meeting.

3.8.2 Escalation procedures within partner organisations Several of the contingency actions listed above will require the agreement of the general assembly to be implemented. The general assembly has not yet agreed to the proposals. It is unclear whether the required two thirds majority of the general assembly would be willing to authorise any of the contingency actions listed above if they were asked to. Partners defaulting by producing deliverables that the reviewers appointed by the European Commission reject without costs being paid will result in those partners not receiving funding for work undertaken – as has already been done by the Commission in the case of an earlier version of this deliverable. Escalation procedures within partner organizations A variety of management structures exist within partner organizations including forms of matrix management. The management to whom the leaders of partners’ teams report also change during the project. Consequently, the route to escalation within partner organizations needs to account for these variations. The route to be used will be to inform the administrative contact point named in the contract for each organization if that organization is deemed to be in default of the contract. They will be informed of the possibility of the Commission rejecting deliverables without payment, and of the possibility of the project penalizing the organization if they do not correct the failure to comply with the previously agreed project plan defined in the Description of Work, and they will be asked to request that the appropriate management actions are taken to rectify the default.


4 Quality management of processes and deliverables The quality management review process is the same as defined in D1 in 2004. A review team of 2 individuals from different partners is assigned to each deliverable. The reviewers should both be sufficiently knowledgeable of the subject matter to ensure that the content is of sufficient quality, but also not have been involved in the development of the deliverable. This balance is difficult to ensure and cannot always he met. A further constraint is that no partner should be overburdened by reviewing deliverables, and that reviewing should be shared evenly between partners. The table below lists the deliverables and assigns partner organisations to provide individuals to review each one. When the reviewer name is not stated, a deliverable producer should contact the TrustCoM General Assembly representative for that partner and inform them that the deliverable is available for review. Table 1 identifies the consortium members and abbreviations used in table 2 where the deliverables are allocated to partners for review.

Abbrev. Name Type Country BAE BAE SYSTEMS Industry UK BT BT Industry UK

CCLRC Council for the Central Laboratory of the Research Councils National Research Institute UK

EMIC European Microsoft Innovation Center Industry DE ETH Swiss Federal Institute of Technology Zurich Academic CH

HLRS HLRS – High Performance Computing Centre, affiliated with the University of Stuttgart National Research Centre DE

IBM IBM Industry BE IC Imperial College London Academic UK KCL King’s College London Academic UK

NRCCL Norwegian Research Centre for Computers and Law (University of Oslo) National Research Centre NO

SAP SAP Industry FR Atos Atos Origin Industry ES SICS Swedish Institute of Computer Science National Research Institute SE

SINTEF SINTEF Group Independent Research Institute NO

UoM University of Milano Academic IT UoK University of Kent Academic UK

Table 1 Consortium Members


No Deliverable title Delivery date Rev. 1 Rev. 2

D9 TrustCoM Reference Architecture M18 SAP HLRS D10 Baseline prototype infrastructure for CE scenario M18 ETH BT D11 Baseline prototype infrastructure for AS scenario M18 IC BAE

D27 Detailed Task plan and Quality Schedule for the second phase of the project M18 ATOS

D14 Report on socio-economic models M18 CCLRC NRCC D15 Report on legal issues M18 CCLRC Atos D16 Conceptual Models V1 M18 SAP HLRS D17 Methods and tools for legal risk management M24 CCLRC Atos D18 TrustCoM Framework Specification v1 M18 SICS SAP

D19 Basic set of TrustCoM methods and support tools M18 IBM KCL

D20 Intermediate assessment of framework methods and tools using CE scenario M21 ETH BT

D21 Intermediate assessment of framework methods and tools using AS scenario M21 IC BAe

D24 Roadmap of technical standards development v2.0 M18 Atos

SINTEF

D23 Report on dissemination activities and updated dissemination plan M18 Atos

D25 Outline exploitation plans of identified innovations M18 EMIC UoK

D22 Overall RTD assessment of TrustCoM M18 BAE HLRS D26 Lessons Learned M18 SICS UoM D28 State of Art Evaluation Report Update M21 BAE BT D29 Conceptual Models V2.0 M24 UoM SAP D35 TrustCoM Framework (Version 2) M24 CCLRC EMIC D36 Architecture V2.0 M24 IBM BT

D37 Migration and Demonstration Plan for the Engineering Collaboration Demonstrator M24 SICS BT

D38 Migration and Demonstration Plan for the Ad Hoc Dynamic Processes Demonstrator M24 HLRS BAE

D39 Report on dissemination activities and updated dissemination plan M24 Atos

D40 Collaboration activities Report M24 CCLRC Atos D41 Enhanced prototype for CE scenario M27 SICS BT D42 Enhanced prototype for AS scenario M27 HLRS BAe

D43 Roadmap of technical standards development v3.0 M27 CCLRC Atos

D44 Exploitation plans v3 M27 IBM CCLR D62/45 Conceptual Models V3.0 M30 EMIC BT D62/51 TrustCoM Framework (Version 3) M30 SAP UoK D62/52 Architecture V3.0 M30 BAe UoM


No Deliverable title Delivery date Rev. 1 Rev. 2

D53 Enhanced set of TrustCoM methods and support tools M30 IBM IC

D54 Updated assessment of framework methods and tools using CE scenario M30 BT HLRS

D55 Updated assessment of framework methods and tools using AS scenario M30 BAe SICS

D56 Implementation and Validation of the Engineering Collaboration Demonstrator M30 EMIC SICS

D57 Implementation and Validation for the Ad Hoc Dynamic Processes Demonstrator M30 Atos HLRS

D59 Socio-Economics Issues Report M30 SAP CCLR D60 Legal Issues Report M30 SICS CCLR D61 Overall RTD assessment of TrustCoM M30 ETH Atos

D63 Conceptual Framework + Architecture Final version M36 BT IC

D64 Final TrustCoM Reference implementation and associated tools and user manual M36 SAP UoK

D65 Final prototype for CE scenario M36 Atos BT

D66 Final prototype for AS scenario M36 ETH BAe

D67 Final evaluation of framework using CE scenario M36 CLRC HLRS

D68 Final evaluation of framework using AS scenario M36 EMIC SICS

D69 Final Implementation and Validation of the Engineering Collaboration Demonstrator M40 BT SICS

D70 Final Implementation and Validation for the Ad Hoc Dynamic Processes Demonstrator M40 SAP BAe

D71 Final Standardisation Report M36 CLRC IBM

D72 Final Dissemination Report M36 UoK IC

D73 Final Exploitation plans M36 IBM Atos

D74 Lessons Learnt Managing an Integrated Project M40 CLRC HLRS D75 Open Source release software M40 UoK EMIC

D63 Conceptual Framework + Architecture Final version M36 BT IC

Table 2: List of official deliverables of TrustCoM implementation plan for the period covering from month 13 to month 40.

cordis | european commission - d27 quality plan v3 final · 2016-05-31 · d27 v2 – detailed task...

Documents