artes 20 management requirements...

Ref. : MR for IAP Feasibility Studies Date : 11 April 2012

ESA Unclassified – Releasable to the Public

ARTES 20 Management Requirements

FEASIBILITY STUDIES

Appendix 3 to Contract



TABLE OF CONTENTS

1 OBJECTIVES ................................................................................................................... 6 2 SCOPE OF WORK AND STUDY LOGIC .................................................................... 6 3 CONTRACTUAL MILESTONES AND REVIEW MEETINGS ................................ 8

3.1 Negotiation Meeting (NM) / Kick-Off (KO) .......................................................... 8

3.2 1st Milestone: 1st Progress Meeting (PM1) ............................................................. 8

3.3 2nd Milestone: Mid Term Review (MTR) .............................................................. 8

3.4 3rd Milestone: 2nd Progress Meeting (PM2) ........................................................... 9

3.5 4th Milestone: Final Review (FR) ........................................................................... 9 4 DOCUMENTS AND ITEMS TO BE PRODUCED / DELIVERED ......................... 10

4.1 Stakeholder / User Analysis and User Requirements Definition (D1) .............. 10

4.2 State of the Art Analysis & Identification of Appropriate Technologies (D2) . 11

4.3 Service and System Definition (D3) ............................................................................ 12

4.4 Proof of Concept / Prototype (D4) ............................................................................... 13

4.5 Viability Analysis (D5) ................................................................................................. 14

4.6 Implementation Roadmap and Recommendations (D6) ........................................... 15

4.7 Final Report (FREP) ............................................................................................. 16

4.8 Final Data Package (FDP) .................................................................................... 16

4.9 Project Web Page (PWP) ...................................................................................... 16

4.10 Digital Media (if applicable) ................................................................................. 17

4.11 Deliverable Hardware ........................................................................................... 17

4.12 Deliverable Software and Content ....................................................................... 17

4.13 Submission of Documentation .............................................................................. 17

4.14 Document Confidentiality ..................................................................................... 18 5 MANAGEMENT ............................................................................................................ 18

5.1 Project Manager .................................................................................................... 18

5.2 Experts .................................................................................................................... 18

5.3 Access ...................................................................................................................... 18



6 REPORTING .................................................................................................................. 19

6.1 Distributed Project Collaboration Tool (Daptiv) ............................................... 19

6.2 Minutes of Meetings (MOM) ................................................................................ 19

6.3 Action Item List (AIL) .......................................................................................... 19

6.4 Monthly Progress Report (MPR) ......................................................................... 20

6.5 Bar Chart Schedule (BCS).................................................................................... 20

6.6 Risk Register (RR) ................................................................................................. 20

6.7 Problem Notification ............................................................................................. 20

6.8 Document Configuration and Management Control (DC&MC) ..................... 20

6.9 Contract Closure Documentation (CCD) ............................................................ 21



DEFINITION OF TERMS

Term Definition

Asset Anything tangible or intangible that is capable of being owned or controlled to produce value and that is held to have positive economic value is considered an asset. Simply stated, assets represent ownership of value that can be converted into cash (although cash itself is also considered an asset)

Key Performance Indicator (KPI)

Aspect of an item observed or measured from its operation which is of critical importance for the user/customer/stakeholders

Integrated System A system reliant on the combination of space and non – space assets. In the case of the Integrated Application Promotion programme (ARTES 20), assets from at least two space domains are required.

Product A sellable good such as equipment, subsystem, system or service of-fered by the supplier to the end users, and required by the end users in order to implement his/her application

Proof of Concept Evidence that an idea or concept is feasible or capable of solving a particular problem [meet requirements]

Scenario A type of situation in which a service is required. A scenario is a summary description of an event or series of actions and events

Service An intangible good provided to make available and support a specific application in the end user environment. It is the result of at least one activity necessarily performed at the interface between the supplier and customer and is generally intangible

Service Provider The service provider is a group or person providing a product or service, from processing various input, to an (end) user or client organisation, who is using the product or service to support its operational (business) processes

Stakeholders A stakeholder is a person or group with an interest in a particular category of product or service, which is critical for the successful implementation of a sustainable service.

Subsystem A major part of a system which itself has the characteristics of a system, usually consisting of several components. The subsystem represents the next level of detail in comparison to a system.

System A functionally self-contained combination of hardware and/or software products, which represent the technological building blocks required to provide a service. The system, in its turn, can consist of a number of subsystems and equipment, representing a further breakdown of the technological platform



Term Definition

System Requirements Statement typically originated by the designer about what the system shall do and/or shall be to fulfil the User Requirements (e.g. associated to constraints, environment, operational and performance features)

Traceability Matrix Verification method used to check that the set of elements A is correctly translated and matched to the set of elements B, e.g. User Requirements to System Requirements.

User Person or organization for which the service / product is designed and which exploits at least one of its functions at any time during its life cycle.

Use Case Description of the steps or actions between the user and the service/system.

User Need What is necessary for or desired by the user, not necessarily verifiable.

User Requirement Statement originated by the user describing the functions, performance and capabilities that a service / system will bring to them during its utilization. A user requirements represents the user expectations which are critical to the success of the service / system and typically include key performance parameters and measures of effectiveness.

Validation Process to obtain confirmation that a service/system does what it is required to do. The user shall have a key role in its validation

Confirmation, through the provision of objective evidence that the requirements for a specific intended use or application have been fulfilled

Verification Process to obtain confirmation that a service/system has been implemented according to the System Requirements. This is usually done through a verification method.

Confirmation, through the provision of objective evidence that the requirements for a specific intended use or application have been fulfilled



1 OBJECTIVES

Feasibility Studies provide the preparatory framework to analyse and define new, potentially sustainable applications and services within the Integrated Applications Promotion (IAP) element of the ARTES programme (ARTES 20).

They cover the preparation of user-driven applications and services that employ two or more space assets and are conceived to become sustainable in the short to medium term.

The objectives of a feasibility study are to determine the technical feasibility and economic viability of an integrated service(s) and the associated system(s) able to meet the needs and conditions of relevant users and other stakeholders, to prepare the implementation of sustainable service(s) via a potential follow-on demonstration project (if considered necessary), and to secure the buy-in and involvement of important users and other stakeholders.

2 SCOPE OF WORK AND STUDY LOGIC

2.1 Scope of Work

Within an ARTES 20 Feasibility Study the Contractor shall investigate and analyse the technical feasibility and economic viability of an application / service integrating multiple space based assets in order to fulfil the requirements of the relevant user community, and define the roadmap for its future implementation.

The Contractor shall be responsible for the fulfilment of all the activities required for the setting up and execution of the study. This shall be achieved in accordance with the requirements of the standard documents as detailed in the sections below

Due to the user-driven nature of the study and to the expected follow-on activities, a clear partnership shall be pursued by the Contractor with the user community and, whenever relevant for the successful achievement of the activity’s objectives, with other relevant stakeholders.

Written evidence of the formal agreements with the partners (all participants not appearing explicitly as subcontractors) is provided in the full proposal. Such partnerships shall be actively maintained and possibly reinforced by the Contractor during the whole study.

2.2` Study Logic

To achieve the above-mentioned objectives the study logic presented in Figure 1 is suggested as baseline.

If already all information related to a specific task exists, this task does not have to be repeated, but relevant proof has to be provided to the Agency. If an alternative study logic is proposed that is considered more suitable, this needs to be duly justified.



Figure 1: Study Logic

• Task 1 – consolidating the interest and involvement of the related users and other stakeholders, analysing in detail their respective needs and defining the user requirements,

• Task 2 – performing a state-of-the-art analysis of the different existing technological solutions (both terrestrial and space based) able to respond to the user needs and conditions and to meet the requirements, identifying the technologies best suited to solve the problem, analysing the technological gaps,

• Task 3 – defining the integrated service(s) and the service value chain, generating the architecture and requirements for the service(s) and the associated system(s),

• Task 4 – proving the feasibility of critical technical and non-technical elements of the service(s) and the associated system(s) (Proof of Concept) in collaboration with the users (this task needs to be adapted to the complexity of the solution and the available feasibility study budget),

• Task 5 – analysing the economic and non-economic viability of the service(s) and the associated system(s),

• Task 6 – preparing the roadmap for the further implementation of the service(s) and the associated system(s), generating inputs for the preparation of a demonstration project, and securing the involvement of important users and other stakeholders.

It is expected that the Contractor involves the users actively in all tasks.

Task 1: Stakeholder / User Analysis & User

Requirements Definition

Task 2: State-of-the-Art

Analysis & Technology

Identification (incl. space assets)

Task 3: Service and

System Definition

Task 4: Proof-of-Concept /

Prototype (when applicable)

Task 5: Viability Analysis (economic & non-economic)

Task 6: Roadmap and

Recommendations &

Preparation of Demo Project

Mid Term Review (MTR)

2nd Progress Meeting (PM2)

Final Review

(FR)

Negotiation Meeting /

Kick-off (KO) 1st Progress

Meeting (PM1)



3 CONTRACTUAL MILESTONES AND REVIEW MEETINGS

The following five meetings represent the sequence of events to be taken into account in establishing the logical organisation of the work. Each of these meetings will be attended by ESA’s Technical Officer and representatives of the project team. The documentation supporting each meeting shall be delivered to ESA ten (10) working days before the meeting takes place.

Contractual Milestones are the Negotiation / Kick-off Meeting, the Mid Term Review and the Final Review. Progress Meetings are considered equal important for the monitoring of the study progress and can be but do not have to be contractual milestones.

3.1 Negotiation Meeting (NM) / Kick-Off (KO)

The purpose of the Negotiation Meeting (NM) is to clarify any outstanding issues identified by ESA, to agree on the project planning and to negotiate the contract.

During the Negotiation Meeting the official Kick-off (KO) date will be agreed, which can be the date of the Negotiation Meeting at the earliest. In general, it is not foreseen to have a separate physical Kick-off meeting with ESA, but it can be held via teleconference.

3.2 1st Milestone: 1st Progress Meeting (PM1)

Between the KO and PM1, the Contractor shall consolidate the interest and involvement of the related users and other stakeholders, analyse in detail their respective needs, define the user requirements (task 1), carry out an investigation of the state-of-the-art of existing technological solutions (terrestrial and space based) and a related gap analysis (task 2), as well as to elaborate on the market analysis of the Viability Analysis (task 5).

It shall be considered if a workshop is necessary or helpful to complete these tasks and/or to federate the communication in the user and stakeholder community. Such a workshop (venue, date, program) shall be coordinated with ESA in advance.

The purpose of PM1 is for the Contractor to present the findings on the user requirements, the state of the art, and the first elements of the viability analysis; and for ESA to approve the user requirements and cross check the findings of the state-of-the-art analysis and the first elements of the viability analysis (market analysis, cost of the selected technologies).

As part of the PM1 data package, the Contractor shall deliver to ESA the first version of the Project Web Page according to the template accessible under: http://iap.esa.int/templates/pwp.

PM1 represents the starting point for task 3 “Service and System Definition”.

3.3 2nd Milestone: Mid Term Review (MTR)

The MTR will mark the end of the service and system design (task 3). It will be held to present, discuss, review and accept the Integrated Services, the Service Requirements, the Service Value Chain and Service Elements, the System Requirements, the System Architecture, the System Design and the trade-off processes performed to select the different building blocks, the Critical Elements which are proposed for further validation in a potential proof-of-concept and a First Outline of the Proof of Concept, and to cross check the findings of the second set of elements of the viability analysis (cost of the service(s) and system(s), cash flow streams).

http://iap.esa.int/templates/pwp



Successful completion of MTR is a condition to proceed with the following tasks. The MTR marks also the starting point for discussions of a potential follow-on demonstration project.

3.4 3rd Milestone: 2nd Progress Meeting (PM2)

Between the MTR and PM2 task 4 “Proof-of-Concept / Prototype” will take place and task 5 “Viability Analysis” will be completed. At PM2 the Contractor shall present the design, development, implementation and results of the Proof-of-Concept which was carried out in collaboration with the users, as well as the analysis on the economic and non-economic viability of the proposed service(s) and the associated system(s).

To follow the proof-of-concept closely, ESA reserves the right to request intermediate deliverables (like Prototype Design, Validation Plan and Procedures).

3.5 4th Milestone: Final Review (FR)

At the Final Review (FR) the Contractor shall present the overview of the activities carried out during the project, the overall assessment of the technical feasibility and economic viability of the proposed service(s) and the associated system(s).

Special focus will be given to the results of the viability analysis in combination with the roadmap for the further implementation, including the identification of the key elements for a potential follow-on demonstration project and the future involvement of key users and other stakeholders.

If considered necessary or helpful, a user / stakeholder workshop shall be organised to present the study results, federate the stakeholder community and collect feedback on the further implementation roadmap. Such a workshop (venue, date, program) shall be coordinated with ESA in advance.

3.6 Meeting Overview Event Date Location Negotiation Meeting ESTEC Kick Off Meeting After successful negotiation

meeting by telephone

Users/Stakeholders Workshop During execution of Task 1 TBD Progress Meeting 1 Conclusion of tasks 1 and 2 Contractor / User Mid Term Review Conclusion of task 3 ESTEC Progress Meeting 2 Conclusion of tasks 4 and 5 Contractor / User Awareness Event During execution of task 6 TBD Final Review with Final Presentation

Conclusion of task 6 ESTEC

a) The Negotiation Meeting, the Mid Term Review and the Final Review with Final

Presentation shall take place at the Agency's premises.

b) Additional meetings may be requested either by the Agency or the Contractor.



c) The Contractor shall give to the Agency prior notice of any meetings with Third Parties to be held in connection with the Contract. The Agency reserves the right of participation in such meetings.

d) With due notice to the Contractor the Agency reserves the right to invite Third Parties to meetings to facilitate information exchange.

e) For all meetings with the Agency, the Contractor shall ensure that proper notice is given at least two (2) weeks in advance. For all other meetings, the Contractor shall inform the Agency, which reserves the right to participate. The Contractor is responsible for ensuring the participation of his personnel and those of the Subcontractor(s), as needed.

f) For each meeting the Contractor shall propose an agenda in electronic form and shall compile and distribute hand-outs of any presentation given at the meeting.

4 DOCUMENTS AND ITEMS TO BE PRODUCED / DELIVERED

During the execution of the project the Contractor shall produce the deliverable documents / items as described below. The documents shall be produced / updated at the meetings as detailed in Section 3 and the table in Section 4.13.

In principle, it is expected that all the tasks of the feasibility study are performed in close coordination with the users (leveraging on their connections to important stakeholders, assisting in the definition of the user needs and requirements as well as in the service and system definition, supporting the proof of concept (e.g. facilities, in situ support), providing feedback on the usefulness, contributing to the viability analysis, assisting in the preparation of the roadmap and of a potential demonstration project, promoting the service and system in their respective communities, etc.). As such, it is expected that the content of the documents D1 to D6 mirrors adequately their involvement and contributions.

4.1 Stakeholder / User Analysis and User Requirements Definition (D1)

This document shall present the outputs of the task 1 activities and shall include a systematic overview of the users and other stakeholders, information on the consolidated interest of the users and other stakeholders, the typical use cases and scenarios including problem statements as well as the related stakeholder / user needs. This information shall be translated into user requirements which are considered the major outcome of task 1.

The document shall include the following elements:

D 1.1 Concept Note: The concept note – aimed at users and other stakeholders – shall describe in about 4 pages the concept of the subject activity, its purpose and principle, and the added value of the integrated solution based on multiple space based assets.

D 1.2 Stakeholder Overview, Interest and Involvement: This chapter shall provide a systematic overview of the stakeholders, i.e. identify the stakeholders (entities, contact persons, etc) that are considered indispensable for implementation and operation of a sustainable service(s), their roles and importance in the realm of the activity (political, regulatory, technical, commercial, users, etc), their interest in a new service, the level of communication established with the Contractor, and their involvement in the activity (active, passive). Evidence on the involvement of critical stakeholders shall be provided.



D 1.3 User Needs and Use Cases: This chapter shall provide a good insight in the problems and needs that the involved user community has. To this purpose, the users relevant for this activity shall be presented together with typical use cases and their present operational processes providing a good understanding of the current situation, the problems that need to be solved, the ideal solution, and the impact and added value that a new efficient application / service is expected to provide to these users (in economic and non-economic terms).

D 1.4 User Requirements: The information collected from users and other stakeholders shall be translated in a clear set of requirements for a new application/service. They shall be consolidated in close cooperation with users and other stakeholders. User requirements represent the user expectations which are critical to the success of the service/system and typically include key performance parameters and measures of effectiveness. They can be quantitative and thus easily allocated to the service/system, or they are qualitative, in which case measures of performance need to be derived. They describe what a service/system shall do, how well the service/system shall do it, and what/how the service/system shall interface to other services/systems. They shall be achievable, verifiable, unambiguous, traceable, consistent, complete and appropriate. They shall not describe how a service/system/product shall do its task. Failure to satisfy these requirements will cause the user to deem the service/system unacceptable. The requirements shall be specified using unique identifiers to allow easy traceability throughout the activity and shall be traced all the way through the project documentation. If applicable, they shall be categorised in “mandatory” and “optional” requirements. It is expected that also requirements related to interoperability aspects with existing operational procedures and systems of the users as well as economic/non-economic aspects are captured. (Later on, traceability matrices shall refer to these user requirements indicating how they map to the service and system requirements, the design, implementation and verification).

D 1.5 Stakeholder / User Workshop Document: Depending on the subject and when considered necessary or helpful, the organisation of a user/stakeholder workshop shall be considered. If such a workshop is proposed to be part of the activity, the venue, date and programme of the event shall be agreed with ESA. A related workshop report shall be generated from this event compiling all information, i.e. participants, programme, hand-outs, presentations, results, conclusions.

4.2 State of the Art Analysis & Identification of Appropriate Technologies (D2)

This document shall present the outputs of the task 2 activities and shall include the analysis of the state-of-the-art of the different existing technological solutions (both space and terrestrial) which are considered best to solve the problem, respond to the user needs and their requirements and are considered suitable for integration into a new application / service.


D 2.1 State of the Art Technologies: This chapter shall present the identified existing terrestrial and space-based solutions / assets / technologies that can provide an operational or pre-operational solution (strengths & weaknesses) to the user needs (or a subset



thereof) and which could constitute a component of the final service (s) and the associated system(s). It shall also include information on the maturity and availability (e.g. experimental stage, operational, legal issues), the cost, and the provided added value of these elements. The chapter shall contain as a minimum an introduction explaining the concept to which the solutions / assets / technologies shall correspond, a set of assessment and selection criteria (which should be compliant with the user requirements), the information on the various relevant solutions / assets / technologies, the final assessment and proposed selection and related trade-off considerations.

D 2.2 Gap Analysis: In this chapter a critical review of the identified state-of-the-art elements shall be presented identifying the needs and requirements that are already met adequately and those that are not or only partially met. The review shall be concluded by an analysis of additionally required developments (modifications, enhancements, developments, etc.).

4.3 Service and System Definition (D3)

This document shall present the outputs of the task 3 activities generating a definition of the service(s) and the associated system(s) able to meet the user requirements.


D 3.1 Service Definition and Service Value Chain: This chapter shall present the service(s) able to respond to the user requirements including a clear set of service requirements. It shall contain the related service value chain end-to-end (e.g. information collection, information fusion, information processing and modelling, information distribution) together with the actors relevant for each step of the service value chain (from data collectors / providers to the recipients and payers of the service) and their roles. Beside the primary service functions also secondary support functions and elements (e.g. back office, billing, maintenance, training) shall be considered and, depending on their relevance, presented. Integration with and interfaces to operational processes and procedures of the users shall be made clear. Based on the service value chain the potential cash flow streams shall be identified.

D 3.2 System Requirements: This chapter shall present a clear set of system requirements (functional, performance, interface, environment, etc.) for the associated system compliant with the defined services and able to meet the user requirements. They shall be broken down to a level which allows the selection of (terrestrial and space based) technologies. The system requirements shall be associated to mandatory and optional user requirements. Integration with and interfaces to operational processes and procedures of the users shall be made clear. The requirements shall be defined using unique identifiers to allow easy traceability throughout the activity. They shall be traced all the way through the project documentation. A traceability matrix showing the dependence between the user requirements and the system requirements shall be included.

D 3.3 System Architecture: The chapter shall contain the description of the overall set up of the system including the major building blocks of the next lower level. It shall present the description of the selected technologies (terrestrial and space based assets), the justification for their selection (e.g. trade off analysis), the different interactions,



interfaces and interoperability aspects, the information on the development maturity and availability (e.g. COTS, to be modified, to be enhanced, to be developed, etc). A compliance matrix between chosen technologies and system requirements / user requirements shall be included.

D 3.4 Critical Service and System Elements: In this chapter a critical reflection of the service and system design shall be presented identifying the most critical elements (technological and non-technological) for the implementation of a future sustainable service.

D 3.5 Preliminary Outline of the Proof of Concept (if applicable): These critical elements or a subset thereof are expected to become subject for further feasibility proof within task 4 “Proof of Concept” (if included in the study). In coherence with the identification of the critical elements of D 3.4, a first outline of the potential “Proof of Concept” shall be generated.

4.4 Proof of Concept / Prototype (D4)

Depending on the complexity of the subject and the available feasibility study budget, a proof-of-concept might be included in the study. Such an activity is expected to prove the feasibility of critical elements of the service / system which can be of technical or non-technical (e.g. economic, securing user buy-in) nature. The “Proof of Concept” can include analysis, simulations, a prototype, or what otherwise is deemed appropriate to assess the feasibility of the concept. Any prototype demonstration should be limited in time and should be restricted to proof that the identified critical elements are feasible (the execution of an end-to-end validation demonstration is subject for an ARTES 20 Demonstration Project). The size of this task and its complexity should be in line with the resources available to the feasibility study. It shall be carried out in collaboration with the users and preferably within their working environment.

The document shall present the outputs of this task 4 and shall include the following elements:

D 4.1 Proof of Concept Design and Development: This chapter shall include the identification of the critical elements of the Service and System Design which shall be addressed within the proof of concept and the related definition and justification of the “Proof of Concept”. In case of a prototype demonstration it shall contain the design of the prototype itself, and the presentation of the working environment with service behaviour and user interaction. The prototype is then expected to be produced according to the design. As one element of this document, an inventory list of all the items produced or procured shall be created, including the related location of the assets. This list, called “Inventory and Status Control” (ISC), shall comprise all hardware, software and content.

D 4.2 Proof of Concept Verification: This chapter shall include all information related to the verification of the critical elements subject for the “Proof of Concept” (verification plan and procedures, verification results). In case of a prototype demonstration the technical performance of the prototype shall be verified before the validation with the users according to the defined verification plan and procedures and the results presented.

D 4.3 Proof-of-Concept Validation and User Feedback: This chapter shall include a validation plan (duration, involved actors, environment, validation elements, etc), and



the validation procedures (i.e. the approach, the methodology, the validation sequence and the validation conditions). Any necessary training material in preparation of the validation activities shall be documented. The validation activities shall be carried out with the users and the results recorded, analysed and evaluated in close coordination with the users. A specific chapter presenting the user feedback shall be incorporated.

D 4.4 Digital Media: The documentation related to the proof-of-concept shall be complemented by a collection of Digital Media consisting of digital pictures and/or digital videos taken during the execution of the proof-of-concept and documenting the installation and utilisation of the prototype by the User Groups.

4.5 Viability Analysis (D5)

In this document an analysis of the viability aspects of the future service(s) and the associated system(s) shall be presented including, where applicable, economic elements like market analysis and cost/benefit analysis, as well as non-economic elements like political, regulatory, legal aspects. This document has to be understood as precursor of the business plan for a demonstration project proposal respectively to the future operational service(s).


D 5.1 Market Analysis: If relevant with the proposed objective of the activity, this chapter shall provide information on the potential opportunity for the system and its associated services, the potential total market, the addressable market, the market segmentation, the service provision chain, the competitive positioning (SWOT), the attractiveness of the service(s) and the associated system(s), and the revenue potential.

D 5.2 Cost/Benefit Analysis: This chapter shall provide information on the financial aspects of a future service relevant for the service provider / consortium as well as on the cost/benefits from the point of view of the user community. As such, it shall cover the relevant cost elements for the service provider/consortium, including, but not only, information on the capital cost for the implementation of the service (CAPEX) and on the expected operational cost (OPEX) as well as on the planned pricing policy. From the user point of view the identification and quantification of the benefits of the service(s) and the associated system(s) shall be presented. The chapter shall be completed with a final conclusion on the overall cost/benefit result.

D 5.3 Non-Economic Viability Analysis: This chapter shall present the non-economic aspects relevant for the viability of the future service(s) and the associated system(s). This might include. information on the decision makers to be involved to overcome possible political or regulatory obstacles, together with information on their decision criteria, legal obstacles and liability considerations and potential measures to overcome these obstacles, public acceptability of the proposed system and its associated services, impact on the existing working environment of the users, important partnerships, intellectual property rights, etc.

D 5.4 Final Viability Assessment: Taking into account the above findings an overall assessment of the economic and non-economic viability of the proposed service(s) and the associated system(s) shall be presented, clearly identifying the major elements to be



taken into account for the implementation (incl. the demo project). This assessment is expected to be made traceable back to the relevant user and stakeholder conditions and requirements of D1.

During the PM1, MTR and PM2 various elements of the Viability Analysis will be discussed and reviewed. During PM1 the market analysis and cost of selected services / assets / technologies identified in Task 2 shall be presented, during the MTR the cost of the service(s) and the associated system(s) as identified in Task 3 as well as potential cash flow streams. The final discussion and review of the completion of the task will take place at PM2.

4.6 Implementation Roadmap and Recommendations (D6)

In this document the roadmap for the further implementation of the intended service(s) and the associated system(s) shall be documented, as well as the relevant inputs for the preparation of the implementation of a potential demonstration project.


D 6.1 Feasibility and Viability Assessment: This chapter shall provide the overall assessment of the technical feasibility and economic viability of the proposed concept including a comprehensive risk analysis, also in view of a potential follow-on demo project, together with an overall evaluation of the added value of the service / system and the integrated space assets.

D 6.2 Implementation Roadmap: This chapter shall present the roadmap for the implementation of the proposed service(s) and the associated system(s) via a demonstration project and beyond. It shall include information on the overall framework (legal, political, financial, technical, operational, etc) for a future service, identify essential aspects which are not mature or cannot be covered by the demonstration project, present the plan of activities to be carried out within a potential demonstration project, propose measures with regards to important aspects (legal, regulatory, IPR, etc) and stakeholders (governments, institutions, standardisation bodies, general public, etc). It shall present information on the required partnership agreements as well as on the expected involvement of important users and other stakeholders within the demonstration project.

Depending on the subject and to close the loop with stakeholders / users, a workshop / awareness event presenting the outcome and discussing the future of the activity shall be considered. If such a workshop / awareness event is proposed to be part of the activity, the venue, data and programme of the event shall be agreed with ESA. The following output shall be generated from this event:

D 6.3 Stakeholder / User Workshop Document: The content of such a workshop is expected to cover a presentation of the potential of the service(s) and the associated system(s) to a wider range of important users and other stakeholders as well as to collect feedback from these users and stakeholders on the legal, political, financial, technical, operational, etc. framework and the identified roadmap. The related document shall compile accordingly all information related to such a workshop, i.e. participants, programme, hand-outs, presentations, results, conclusions.



4.7 Final Report (FREP)

The Contractor shall deliver, not later than ten working days before the Final Review, a Draft Final Report, on which ESA will provide comments within one week after said review.

The Final Report (FREP), which is intended for general publication, is to be written in a concise form, and shall describe the major accomplishments of the study. It shall consist of about 25 pages and shall not contain Proprietary Information nor any confidentiality/copyright statement.

The front cover of the report shall carry the following text within a delineated box of at least 10 cm x 4 cm, preferably located in the top or bottom left-hand corner of the cover:

“EUROPEAN SPACE AGENCY CONTRACT REPORT

The work described in this report was done under ESA contract. Responsibility for the contents resides in the author or organisation that prepared it.”

Within four weeks after the Final Review the finalised version of the Final Report shall be delivered as follows:

• One (1) paper copy and one (1) copy on CD-ROMs to the ESA Information and Documentation Centre,

• 1 paper copy and 3 CD-ROMs to the Agency's Technical Officer

The CDs shall be labelled with: the title “Final Report”, the project name, the company name, the contract number, and the completion date. They shall include Acrobat Reader and the Final Report in PDF format. 4.8 Final Data Package (FDP)

Together with the finalised version of the Final Report, the Contractor shall deliver to ESA 3 copies of the Final Data Package (FDP), consisting of a CD or DVD containing the final versions of all main deliverables (FREP, PWP, D1 – D6, content developed as part of the contract, Digital Media documenting the proof-of-concept demo).

The CDs shall be labelled with: the title “Final Data Package”, the project name, the company name, the contract number, and the completion date. They shall include Acrobat Reader and the documents in PDF format as well as an index document with links to the different document files

4.9 Project Web Page (PWP)

The Contractor shall produce, as part of the PM1 package, a Project Web Page according to the template accessible under: http://iap.esa.int/templates/pwp

With every review meeting, starting from the publication of the Project Web page and ending with the conclusion of the contractual activities, the Contractor shall provide an updated version of the “Current Status” paragraph of the Project Web Page.

The “Current Status” paragraph of the Project Web Page will be the opportunity for the project to inform the general public about the status of the progress. The Contractor shall ensure that the public image of the project is properly portrayed and maintained through the above Web Page. A final version of the Project Web Page shall be provided together with the Final Report. This final

http://iap.esa.int/templates/pwp



version shall include a paragraph summarising the most significant achievements of the study.

All study information to be published including the "project web page" will duly respect any relevant confidentiality agreement established among the partners

4.10 Digital Media (if applicable)

Digital Media comprises digital pictures and/or digital videos documenting the Proof of Concept (if included in the study) elements during installation and utilisation by the Users.

4.11 Deliverable Hardware

Article 2 para. 2.1.3 of the Contract applies.

4.12 Deliverable Software and Content

Any software and content developed under the Contract shall be delivered in executable form upon completion of the contract. ESA will acquire the license according to Article 2.1.2 of the contract. The same acquisition rule applies to technical data (“information” in the terminology of the General Clauses and Conditions).

4.13 Submission of Documentation

The deliverable documentation given in the following table is required as a minimum and shall be provided during the Contract as indicated.

All documentation shall be delivered in electronic form, using preferably MS Word or Adobe Acrobat format with pictures and tables embedded in the document. The documentation shall include in its options the possibility to be printed.

The documents shall be delivered at least ten working days prior to the review via the Distributed Project Collaboration Tool (see chapter 6.1).

Name Deliverable Reference to Section

Initial Submission

Updating Final Submission

MOM Minutes of Meetings 6.2 KO every meeting FR

D1 Stakeholder/User Analysis & User Requirements Definition 4.1 with the proposal PM1 FR

D2 State of the Art Analysis & Technology Identification 4.2 with the proposal PM1 FR

D3 Service and System Definition 4.3 with the proposal MTR FR

D4 Proof of Concept / Prototype 4.4 with the proposal PM2 FR

ISC Inventory and Status Control (as part of D4) 4.4 PM2 FR

DM Digital Media (as part of D4) 4.4 PM2 FR

D5.1 Viability Analysis – Market Analysis & Technology Cost Information

4.5 with the proposal PM1 FR

D5.2 Viability Analysis – Cost Elements of Service/System & Cash Flow Streams

4.5 with the proposal MTR FR



Name Deliverable Reference

to Section Initial

Submission Updating Final

Submission D5 Viability Analysis (complete) 4.5 with the proposal PM2 FR

D6 Implementation Roadmap and Recommendations 4.6 with the proposal FR FR

MPR Monthly Progress Report 6.4 KO + 1 month every month FR

RR Risk Register 6.6 with the proposal every month within MPR FR BCS Bar Chart Schedule 6.5 with the proposal as necessary and at reviews FR PWP Project Web Page 4.9 PM1 every review meeting FR DC&MC

Document Configuration and Management Control 6.8 PM1 as necessary FR

FREP Final Report 4.7 FR FR FDP Final Data Package 4.8 FR FR

CCD Contract Closure Documentation 6.9 FR FR

KO: Negotiation/+Kick-Off meeting PM1: 1st Progress Meeting MTR: Mid Term Review PM2: 2nd Progress Meeting FR: Final Review

4.14 Document Confidentiality

All deliverable documents produced in the frame of the project will be treated in confidence. The only exceptions are the Project Web Page and the Final Report, which the Agency may make available to participating states and persons and bodies thereof. 5 MANAGEMENT

5.1 Project Manager

The Contractor shall implement effective and economical management for the Project. His nominated Project Manager shall be responsible for the management and execution of the work to be performed and, in the case of an industrial team, for the coordination and control of the industrial team’s work. He will be the official point of contact with the Agency during the execution of the work.

During the contract execution, the Project Manager shall notify the Agency of any critical risk that may arise, analysing the cause, assessing the potential impacts on the project in terms of time, objectives and scope and formulating in the shortest possible time a mitigation strategy. Risks already identified and not completely resolved shall be addressed in a specific paragraph in the Monthly Progress Report (see section 6.4) together with the associated mitigation strategy.

5.2 Experts

For special cases the Agency reserves the right to be advised by external experts. These experts will be committed to treat any information obtained in the context of this contract on a strictly proprietary basis.

5.3 Access

During the course of the Contract the Agency shall be afforded free access to any plan, procedure, specification or other documentation relevant to the programme of work. Areas and equipment



used during the development/testing activities associated with the Contract shall also be available for inspection and audit.

The Contractor shall notify the Agency at least three weeks before the start of any test programme, or as mutually agreed, in order to enable the Agency to select those tests that it wishes to witness. The Agency shall notify the Contractor of its visit at least one week in advance. 6 REPORTING

6.1 Distributed Project Collaboration Tool (Daptiv)

During the execution of the project the web based project planning and collaboration tool accessible under http://telecom.esa.int/collaboration_tool, shall be used. This collaborative environment is made available free of charge by ESA for the duration of the project, and it is intended to replace the usual electronic communication tools (e.g. E-Mail with attached document and/or FTP) within the project team and in the communication with ESA, as well as for recording and tracking Action Items.

Unless otherwise agreed with ESA and formalised in the minutes of the Negotiation Meeting, the Contractor shall provide at the Negotiation Meeting the name of the person to be appointed as administrator of the account. The Agency will activate within one week from the Negotiation Meeting an account dedicated to the project team. During the first part of the project, the environment shall be used on a trial basis by the project team to support information exchange in preparation of the first review meeting. At the first review meeting the Contractor shall inform the Agency whether, on the basis of the results of the trial period, the project team has decided to retain or not the environment for the remaining part of the contract. In case the environment is not retained, the specific account will be deleted by the Agency.

6.2 Minutes of Meetings (MOM)

Formal written Minutes of Meetings attended by ESA shall normally be agreed and made available by the Contractor at the end of the meeting. If distributed in manuscript form at the end of the meeting, a typed version shall follow within five working days and be distributed in electronic form to all participants. The minutes shall clearly identify all agreements made and action items accepted together with, where relevant, an update of the Action Item List.

6.3 Action Item List (AIL)

The Contractor shall maintain an Action Item List (AIL) recording all actions agreed with the Agency. Each item shall be uniquely identified with reference to the minutes of the meeting at which the action was agreed recording the generation date, due date, originator and the person instructed to take action. The AIL shall be reviewed at each progress meeting. In case the Distributed Project Collaboration Tool (see section 6.1) is adopted, Action Items shall be recorded here.

To establish a uniform and consistent procedure, the Contractor shall keep track of the Action Items adopting the following identification scheme:

http://telecom.esa.int/collaboration_tool



Action X.Y where X is the identifier of the meeting (0: Negotiation/Kick Off Meeting, 1: First Review Meeting, 2: Second Review Meeting, etc.), and Y is the Action number starting from 1 at each new meeting.

In case of urgent or critical problems, new Action Items can be originated by the Agency and/or by the Contractor even outside the normal scheduled meetings.

6.4 Monthly Progress Report (MPR)

The Contractor shall provide, within the first five working days of each month, a concise status report following the template provided under http://iap.esa.int/templates/mpr .

This report shall in particular highlight any problems in the study activities and the corrective actions taken by the Contractor. To the extent possible, the progress report and annexed documentation should be delivered in MS Word format by using the Distributed Project Collaboration Tool or as an attachment to email.

6.5 Bar Chart Schedule (BCS)

The Contractor shall be responsible for maintaining the bar-chart for work carried out under the Contract, as agreed at the kick-off meeting.

The Contractor shall present an up-to-date chart for review at all consequent meetings, indicating the current status of the contract activity (WPs completed, documents delivered, etc.).

6.6 Risk Register (RR)

The Contractor shall be responsible for maintaining a risk register, agreed at the kick-off meeting. This register shall identify potential risks, their likelihood and severity, and propose meaningful mitigation measures.

The Contractor shall present an up-to-date risk register in his monthly progress reports.

6.7 Problem Notification

The Contractor shall notify the Agency's representatives (Technical Officer and Contracts Officer) of any problem likely to have a major effect on the time schedule of the work or to significantly impact the scope of the work to be performed (due to e.g. procurement problems, unavailability of facilities or resources, etc.).

6.8 Document Configuration and Management Control (DC&MC)

Starting with the first review meeting, the Contractor shall create and maintain, for consultation by ESA, a Document Configuration and Management Control recording all documents produced in connection with the contract. The list shall indicate the document title, name of the file, document reference, type of document, date of issue, revision number, confidentiality level and distribution list.

Each deliverable document shall include a Title Page reporting Project Name, Contract Number, Title of the Document, Reference Identifier, Author(s) and related Organisation(s), Date of Issue and Revision Number.

http://iap.esa.int/templates/mpr



All deliverable documents shall include as second page a Document History Sheet, indicating for each submitted revision the corresponding date and the reason for the revision. Each revision shall be formatted in order to easily spot changed parts with respect to the previous submission.

6.9 Contract Closure Documentation (CCD)

The Contract Closure Documentation is a mandatory deliverable, due at the end of the Contract (or at the end of a Phase in case the Agency decides not to proceed with the following Phase). For the avoidance of doubt, “end of the Contract” shall mean the finalisation of a series of tasks as defined in the “MR” for Feasibility Studies (Appendix 3 to the Draft Contract). The contents of the Contract Closure Documentation shall conform to the layout provided in Annex A hereto.



ANNEX A: LAYOUT FOR CONTRACT CLOSURE DOCUMENTATION

for

ESA/ESTEC Contract Nr. [INSERT NUMBER]

“[INSERT ACTIVITY TITLE]”,

hereinafter referred as the “Contract”

Section 1 – Parties, contract duration and financial information

Contractor [CONTRACTOR NAME]

Sub-Contractor(s) (state if not applicable)

[NAME AND COUNTRY] [NAME AND COUNTRY] [NAME AND COUNTRY] [NAME AND COUNTRY]

Contract duration Per Contract

From: To:

Phase 1 from: to:

Phase n from: to:

Total contract price (including all CCNs, Work Orders, Call of Orders) and total contract value (in case of co-funding; state if not applicable)

EUR EUR

broken down as follows:

Original contract price and original contract value (in case of co-funding; state if not applicable)

XXX EUR (XXX EUR) EUR

CCN x to n Work Order x to n Call-off Order x to n

EUR in total EUR in total EUR in total



Section 2 – Recapitulation of deliverable items 2.1 Items deliverable under the Contract If any of the columns do not apply to the item in questions, please indicate “n/a”. Table 2.1.1 – Items deliverable according to the Management Requirements Type Ref.

No. Name/ Title

Description Location1) Property of

Rights granted / Specific IPR conditions2)

Documentation

Hardware

Software

(delivery in object code/source code?)

Other

1 In case the item is not delivered to ESA, please indicate the location of the deliverable and the reason for non-delivery (e.g. loan agreement, waiver, future delivery, etc.) 2 e.g. IPR constraints, deliverable containing proprietary background information (see also 2.1.4 below)



Table 2.1.2 – Other deliverable items: Inventory of items produced or purchased under the contract (if applicable) [OPTION 1: No Fixed Assets] No Fixed Asset has been acquired under the Contract by the Contractor and/or its Sub-Contractor(s). [OPTION 2: Fixed Assets] All fixed assets are listed below. The Contractor certifies that all its obligations with regards to Fixed Assets (see also Article 2.1.3 and Article 4 of the Contract) have been fulfilled.

Item name Part/ Serial reference number Location Resale Value

Table 2.1.3 – Customer Furnished Items and Items made available by the Agency Any Customer Furnished Items and/or Items made available by the Agency to the Contractor and/or its Sub-Contractor(s) under the Contract, are listed in the following List of Customer Furnished Items and Items made available by the Agency. The following tables certify which of the items have been returned to the Agency and which of the items remain in the custody of the Contractor, and/or a Sub-Contractor(s) and/or a third party for further ESA work or for other purposes. Customer Furnished Items ESA DECISION

Item name

ESA Inventory Number

Location Insurance Value

Confirmation of Receipt Deliver

Leave at (Sub-) Contractor’s Disposal

Items made available by the Agency

Item name

ESA Inventory Number

Location Replacement Value Deliver

Leave at (Sub-) Contractor’s Disposal



Table 2.1.4 – Background Information used and delivered under the Contract (see Clause 43 of the General Clauses and Conditions) The following background information has been incorporated in the deliverable(s): Proprietary Information (title, description)

Owner (Contractor, Sub-Contractor(s), Third Party/ies)

Affected deliverable (which documents, hardware, software, etc.)

Description impact on ESA’s rights to the deliverable3

Other/comments

Section 3 – Output from / Achievements under the Contract 3.1 Technology Readiness Level (TRL) N/A 3.2 Achievements and Technology Domain N/A 3.3 Application of the Output/ Achievements N/A 3.4 Further Steps/Expected Duration Please tick off as appropriate: No further development envisaged. Further development needed: ………………………………………………………. Please describe further development activities needed, if any, including an estimate of the expected duration and cost. 3.5 Potential Non-Space Applications

N/A

3 if not explicitly stated otherwise, the contractual stipulations shall prevail in case of conflict with the description provided in this table



Section 4 – Statement of Invention [OPTION 1: NO INVENTION] In accordance with the provisions of the above Contract, ……………[Company] hereby certifies both on its own behalf and that of its consortium/Sub-Contractor(s), that no Intellectual Property Right(s) has(ve) been registered in the course of or resulting from work undertaken for the purpose of this Contract; and that no inventions have been made in the course of or resulting from work undertaken for the purpose of this Contract that generated knowledge that could be registered as Intellectual Property Rights. [OPTION 2: INVENTION] In accordance with the provisions of the above Contract, ……………[Company] hereby certifies both on its own behalf and that of its consortium/Sub-Contractor(s) that the following Intellectual Property Right(s) has(ve) been registered in the course of or resulting from work undertaken for the purpose of this Contract. ……………………. [OPTION]: In accordance with the provisions of the above Contract, ……………[Company] hereby certifies both on its own behalf and that of its consortium/Sub-Contractor(s) that the following inventions have been made in the course of or resulting from work undertaken for the purpose of this Contract but have not been registered as Intellectual Property Rights: ……………………. [OPTION]: In accordance with the provisions of the above Contract, ……………[Company] hereby certifies both on its own behalf and that of its consortium/Sub-Contractor(s) that the following inventions have been made in the course of or resulting from work undertaken for the purpose of this Contract and are foreseen for and/or in the process of registration: The Agency’s rights on such registered and/or unregistered Intellectual Property Rights shall be in accordance with the ESA GCC Part II provisions as amended by the above Contract.

artes 20 management requirements...

Documents