artes 20 management requirements feasibility...

Ref. : MR for IAP Feasibility Studies Date : 25 March 2014

ESA Unclassified – For Official Use

ARTES 20 Management Requirements

FEASIBILITY STUDIES

Appendix 3 to Contract



TABLE OF CONTENTS

1 OBJECTIVES ................................................................................................................... 3 2 SCOPE OF WORK AND STUDY LOGIC .................................................................... 4 3 REVIEW MEETINGS AND CONTRACTUAL MILESTONES ................................ 7

3.1 Negotiation Meeting (NM) ...................................................................................... 7 3.2 User Requirements Review (URR) ........................................................................ 7 3.3 Service and System Definition Review (SSDR) .................................................... 7 3.4 Final Review (FR) .................................................................................................... 8

4 DOCUMENTS AND ITEMS TO BE PRODUCED / DELIVERED ......................... 10 4.1 Stakeholder Analysis and User Requirements Definition (D1) ......................... 10 4.2 Service and System Definition (D2) ..................................................................... 12 4.4 Viability Analysis (D4) .......................................................................................... 14 4.5 Conclusions and Recommendations (D5) ............................................................ 15 4.6 Final Report (FREP) ............................................................................................. 17 4.7 Final Data Package (FDP) .................................................................................... 17 4.8 Project Web Page (PWP) ...................................................................................... 18 4.9 Digital Media ......................................................................................................... 18 4.10 Deliverable Hardware ........................................................................................... 19 4.11 Deliverable Software and Content ....................................................................... 19 4.12 Submission of Documentation .............................................................................. 19 4.13 Document Confidentiality ..................................................................................... 20

5 MANAGEMENT ............................................................................................................ 21 5.1 Project Manager .................................................................................................... 21

6 REPORTING .................................................................................................................. 22 6.1 Distributed Project Collaboration Tool .............................................................. 22 6.2 Minutes of Meetings (MOM) ................................................................................ 22 6.3 Action Item List (AIL) .......................................................................................... 22 6.4 Monthly Progress Report (MPR) ......................................................................... 22 6.5 Bar Chart Schedule (BCS).................................................................................... 23 6.6 Risk Register (RR) ................................................................................................ 23 6.7 Problem Notification ............................................................................................. 23 6.8 Document Configuration and Management Control (DC&MC) .................... 23 6.9 Contract Closure Documentation (CCD) ............................................................ 23 6.10 Media Relations and Events ................................................................................. 24



1 OBJECTIVES

Feasibility Studies provide the preparatory framework to define and evaluate 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 prepare the implementation of a sustainable service(s) on the targeted market, and to support the business development for such service(s),

to evaluate and determine the technical feasibility and commercial viability of an integrated service(s)1 and the associated system(s)1 able to meet the needs and conditions of relevant user community(ies) and other stakeholders,

to reduce the technical and commercial risks related to the implementation of such sustainable service(s),

to generate the relevant answers to the most critical questions which allow taking informed decisions by all involved parties (industries, users/customers, stakeholders, ESA / National Delegations) on the necessary further investments,

to secure the buy-in and involvement of important users and other stakeholders,

to prepare a potential follow-on demonstration project.

The Contractor is invited to take note that a number of terms used in this document are defined in the “Terminology used in ARTES Projects” document accessible under: http://artes-apps.esa.int/documents

1 In the remainder of the Management Requirements, the singular form of services and systems will be used, where this may still indicate more than one service or system.



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 and non-economic viability of a service and the related enabling system which is able to meet the requirements of the relevant user community(ies) and other relevant stakeholders. Additionally, the Contractor shall define the roadmap towards its future implementation and operation of the service, which can include the preparation of a follow-on demonstration project.

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 deliverables as detailed in the sections below.

Due to the user-driven nature of the study and with respect to a potential follow-on demonstration project, clear partnership(s) shall be pursued by the Contractor with the user community(ies) and, whenever relevant for the successful achievement of the activity’s objectives, with other relevant stakeholders. Such partnership(s) 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. The duration of the study is expected not to exceed 9 months.

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 as part of the Full Proposal.

If an alternative study logic is proposed that is considered more suitable, this needs to be duly justified.

Figure 1: Study Logic



The scope of the tasks indicated in Figure 1 is the following:

Task 1 (Stakeholder Analysis & User Requirements Definition) – identification of the relevant stakeholders (incl. users), consolidation of the interest and involvement of representative users, analysis of the user problems and needs, and defining the user requirements in close cooperation with the involved users.

Task 2 (Service and System Definition) – identification and definition of the services to be provided to the user(s), including the service value chain and targeted operational scenarios; specification and justification of the related system, including the system architecture, the main building blocks, as well as internal and external interfaces; identification of the most critical elements for technical feasibility; evaluation of the technical feasibility.

Task 3 (Proof of Concept) (if applicable) – demonstration and validation of the feasibility of critical elements of the service and the related system in close collaboration with the users. NB: this task needs to be adapted to the complexity of the solution and the available feasibility study budget.

Task 4 (Viability Analysis) – detailed analysis of the economic and non-economic viability of the service, providing the fundamentals for a business plan; evaluation of the non-technical aspects that condition the deployment of the system and the operational provision of the service; evaluation of the economic and non-economic viability. NB: This task needs to be closely interlinked with other tasks in order to match technical and commercial elements. Whereas the handling of technical issues is normally within the capabilities of consortia, the handling of task 4 represents always a challenge to technically oriented organisations. Therefore, it requires special attention and know-how (business developer).

Task 5 (Roadmap & Preparation of Demo Project) – concluding on the feasibility and viability of the specified solution; d analysis of the risks, critical success factors, and showstoppers for the implementation of the solution; planning and approach of the next steps, providing a roadmap for further implementation, including the outline and planning of a potential demonstration project; securing the involvement of important users and other stakeholders, confirmation of the future service provider.

It is expected that the Contractor involves the users and the other stakeholders actively in all tasks and achieves a clear understanding on their further involvement in a potential demonstration project.

Preparation of a potential follow-on demonstration project:

Contractors which intend to continue after the completion of a feasibility study with a demonstration project have to prepare an outline proposal for such a demonstration project as part of task 5.

Accordingly, the individual tasks of the feasibility study are expected to result in outputs which allow the generation of an outline proposal for such a demonstration project.

The interactive training tool to facilitate the creation of such an outline proposal can be found on the ESA website under: http://telecom.esa.int/opdt/artesapps/artes20demo (registration required)



and contains 11 modules.

Feasibility study tasks 1, 2 and 4 are expected to produce the information that allows to complete demo project outline proposal modules 1 to 8a. Feasibility study task 5 is expected to produce information that allows to fill in (parts of) the modules 8b to 11; these modules are related to the implementation of the demo project itself.

In the following table the relation between feasibility study tasks and demo project outline proposal modules is presented.

Feasibility Study Task Demo Project Outline Proposal Module

Task 1: User Requirements Module 2: Major Project Stakeholders Module 7: User Requirements

Task 2: Service and System Definition Module 3: Service Value Chain Module 8a: System/Service Architecture

Task 4: Viability Analysis Module 5: Market Analysis Module 4: Competitive Positioning Module 1: System/Service Opportunity Module 6: Financial Indicators

Task 5: Roadmap / Recommendations Module 8b: System/Service Architecture Module 9: Implementation Approach Module 10: Pilot Service Module 11: Finance, Management & Administrative (FMA)



3 REVIEW MEETINGS AND CONTRACTUAL MILESTONES

The following four 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.

Milestones are the Negotiation Meeting and the acceptance of the deliverables required at User Requirement Review (URR), Service and System Definition Review (SSDR), and the Final Review (FR).

All review meetings include as important element the discussion of the progress on the Viability Analysis. The study shall be geared towards the preparation of relevant elements of a potential follow-on demonstration project respectively sustainable service provision.

3.1 Negotiation Meeting (NM)

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 envisaged Kick-off (KO) date will be agreed. 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 User Requirements Review (URR)

The purpose of the URR is for the Contractor to present the results of task 1, as well as parts of tasks 2 and 4, and for ESA to review the user requirements and to discuss the first aspects of the service and system definition as well as of the viability analysis.

The deliverable of task 1 ( D1) shall include all elements as defined in section 4.1.

The intermediate deliverable of task 2 (D2) shall provide a proposal for the service and system which will be further elaborated and evaluated in task 2, including a justification of its added value with reference to top priority user requirements and constraints, size of the market opportunity, and potential technology gaps.

The intermediate deliverable of task 4 (D4) shall provide an initial evaluation of the non-economic viability aspects which may lead to constraints to be taken into account for service and system specification. An evaluation of the market potential together with an initial segmentation of the market shall be presented as well as a SWOT and competitor analysis.

As part of the URR data package, the Contractor shall deliver to ESA the first version of the Project Web Page utilising the template accessible under: http://artes-apps.esa.int/documents.

3.3 Service and System Definition Review (SSDR)

The purpose of the SSDR is for the Contractor to present the results of task 2, as well as parts of tasks 3 and 4, and for ESA to review the service and system definition, and to discuss the objective and scope of the Proof of Concept as well as the further progress on the viability analysis, especially the financial and cost/benefit analysis of the proposed solution.

The deliverable of task 2 (D2) shall provide all elements as defined in section 4.2.



The intermediate deliverable of task 3 shall provide a proposal for the objective and scope of the Proof of Concept, aiming at validation of the most critical issues with respect to the successful implementation of the proposed solution and/or securing the further buy-in of the involved users/customers. To monitor the progress the proof-of-concept closely, ESA reserves the right to request intermediate deliverables (e.g. Prototype Design, Validation Plan and Procedures) in addition to the progress presented in the Progress Reports.

The intermediate deliverable of task 4 shall provide the financial analysis from the view of the service provider as well as a cost/benefit analysis from the view of the user/customer.

3.4 Final Review (FR)

The purpose of the FR is for the Contractor to present the results of tasks 3, 4 and 5, and for ESA to review the results of the Proof of Concept, the evaluation of the economic and non-economic viability of the proposed solution, the outline proposal for a potential follow-on demonstration project, and the future involvement of key users and other important stakeholders.

The deliverables of tasks 3 (D3), 4 (D4), and 5 (D5) shall include all elements as described in sections 4.3, 4.4, and 4.5 respectively. Furthermore, a final version of the Project Web Page, and a draft version of the Final Report shall be delivered. The duration of the Final Review is typically one day.

In collocation with the Final Review, a Final Presentation is foreseen to present the results of the feasibility study as well as the plans for a potential follow-on demonstration project. The participants to the Final Presentation include typically members of the Contractor / Consortium, ESA, and related National Delegation(s). The duration of the Final Presentation is typically a half day. Depending on the coordination between ESA and the related National Delegation(s), the Final Presentation might also be held at another location. In order to reach a wider audience, alternative means (e.g. Webinar) may be considered in coordination with ESA.

3.5 Meeting Overview

The following table provides a summary of the meetings described in the previous sections: Event Date Location Negotiation Meeting (NM) ESTEC/ECSAT Kick Off After successful NM by telephone User/Stakeholder Workshop During execution of Task 1 TBD User Requirements Review Conclusion of task 1 Contractor’s / User’s

premises Service and System Definition Review

Conclusion of tasks 2 ESTEC/ECSAT

Final Review with Final Presentation

Conclusion of tasks 3, 4 and 5 ESTEC/ECSAT

a) The Negotiation Meeting, the Service and System Definition Review and the Final

Review shall take place at the Agency's premises (ESTEC or ECSAT). The Final Presentation may be held in combination with the Final Review at the Agency’s premises, but can also be held with other means (e.g. Webinar) or at another location that



ESA or the related National Delegation(s) consider more appropriate to promote the further initiative.

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) For all meetings with the Agency, the Contractor shall ensure that proper notice is given at least four (4) 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.

e) With due notice to and in agreement with the Contractor the Agency reserves the right to invite Third Parties to meetings to facilitate information exchange.

f) Draft versions of deliverables which are subject for review and discussion at the Review Meetings shall be submitted to the Agency at least ten (10) working days before the meeting.

g) For each meeting the Contractor shall propose an agenda in electronic form. Hand outs of any presentation given at the meeting shall be prepared in electronic form and uploaded to the project collaboration tool (see Section 6.1 of this document). The Contractor shall also take the minutes of the meeting (MoM).



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 in their respective communities, etc.). As such, it is expected that the content of the documents D1 to D5 mirrors adequately their involvement and contributions.

The content of the deliverables D1 to D5 shall be focused on the essential findings and conclusions. The size shall be limited to 50 pages maximum for each deliverable. Any additional information supporting this findings and conclusions may be annexed to the single deliverable.

4.1 Stakeholder 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 involved users, 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 sub-elements:

D 1.1 Background and Task Approach: As introduction to this task, information on the motivation and background of the activity, as well as on the planned approach for execution of this task shall be presented.

D 1.2 Stakeholder (including Users) Overview, Interest and Involvement: This chapter shall provide a general overview of all (types of) stakeholders which are relevant for the subject of the feasibility study and 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 them, and their involvement in the activity (active, passive). Evidence on the involvement of critical stakeholders (e.g. potential customers, decision makers) shall be provided.

D 1.3 Involved Users, their Operational Scenarios, Problems and Needs: This chapter shall present the users that are actively involved in the activity, including information on their position and representativeness in the targeted market. An overview of present operational processes, services and systems of the users shall be provided. The challenges faced today and the needs/opportunities for improvement shall be presented and analysed. Finally, an overview of the resulting user needs and conditions shall be provided.



D 1.4 User Requirements: The user needs and conditions shall be processed into a clear set of user requirements which will form the basis for the service and system definition. Essential key performance and success criteria shall be highlighted. A mapping between user needs and conditions and the user requirements shall be generated. The user requirements are considered a key outcome of Task 1 and shall be consolidated in close cooperation with users and other relevant stakeholders.

User Requirements shall be unique and describe in a formal way what is required by the user. They shall be formulated from the user’s perspective, not from the system designers’ viewpoint. They shall describe what the service shall do in order to solve a problem or increase a capability, but not how (e.g. “The service shall allow / enable / support …”). Furthermore, they shall be formulated such that they do not impose a certain implementation or technology to be used. Each User Requirement shall be defined meeting the SMART criteria (Specific, Measurable, Attainable, Relevant, Timely). User Requirements shall be logically grouped (e.g. according to different user needs, business activities, or required functionalities). They shall be prioritised (e.g. as “Mandatory/Optional”, “Must have/Important/Nice to have”, or “High/Medium/Low”). Where applicable, User Requirements shall have both “target values” (ideal to solve the problem) and “minimum requirements” (sufficient to be acceptable).

Any related Conditions or Constraints imposed by users or other stakeholders shall also be unique and be described in a formal way. They may either be described separately or in conjunction with the User Requirement they refer to.

Requirements related to Interoperability Aspects with existing operational procedures and systems of the users as well as economic/non-economic aspects shall be captured.

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. (Later on, traceability matrices shall refer to these user requirements indicating how they map to the service and system definition, 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.

The related workshop report compiling all information, i.e. participants, programme, hand-outs, presentations, results, conclusions, shall become part of deliverable D1.

D 1.6 Demo Project Outline Proposal Modules 2 and 7: The outputs from the sub-elements D 1.2, D 1.3, and D 1.4 shall be used to generate the Modules 2 (Major Project Stakeholders) and 7 (User Requirements) of the Demo Project Outline Proposal (see: http://telecom.esa.int/opdt/artesapps/artes20demo)



4.2 Service and System Definition (D2)

This document shall present the outputs of the task 2 activities generating a definition of the service and the system that are able to meet the user requirements.

The document shall include the following sub-elements:

D 2.1 Starting Point and Task Approach: As introduction to this deliverable, information on the starting point (existing services, technologies, systems, etc.) shall be presented as well as the planned approach which is used to execute this task.

D 2.2 Service Definition and Service Value Chain: This chapter shall present the service best able to respond to the user requirements including a clear set of service requirements describing the performance, quality and mode of delivery of the services. Integration with and interfaces to operational processes and procedures of the users shall be made clear. A compliance matrix between the service requirements and the user requirements shall be included.

It shall present the related end-to-end service value chain (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. Finally, the organisation providing the service to the user and the targeted Concept of Operations shall be described.

D 2.3 System Architecture and Components, Design Justification: This chapter shall present and justify a system architecture that is best capable to provide the specified services, taking into account the existing infrastructure of the users, and the selected service provision model.

The description of the architecture shall include a functional and physical overview of the system, detailed enough to identify suitable technologies and COTS components, justify its feasibility and enabling an initial cost analysis. A graphical illustration shall be provided together with descriptions of the main building blocks in terms of required functions, and performance. The description shall also cover interfaces to external systems and services.

For the overall architecture as well as for each of the technologies or products selected for the building blocks, a justification (e.g. trade off analysis) shall be provided, also with respect to alternative technologies. This justification shall cover as a minimum aspects such as the maturity of the technology or product (e.g. Technology Readiness Level), their availability, costs (procurement, development, operation), longevity and lifecycle aspects, and feasibility of implementation in the user organisation.

D 2.4 Feasibility Analysis, Critical Service and System Elements: In this chapter the conclusion on the assessment of the technical feasibility of the overall solution shall be presented. In particular for those parts for which the maturity is low, an analysis of the required developments (implementation, modifications, enhancements, certification) shall be provided.

The most critical elements related to the development, implementation and operation of the service and the system, i.e. what is critical either from a user’s perspective (e.g. in order to adopt the service) or from a technical perspective (e.g. where the functionality or



performance is still not proven), shall be presented. These elements form an important input for the proof-of-concept and a potential follow-on demonstration project.

D 2.5 Demo Project Outline Proposal Modules 3 and 8a: The outputs from the sub-elements D 2.2, D 2.3, and D 2.4 shall be used to generate the Modules 3 (Service Value Chain) and 8a (System/Service Architecture) of the Demo Project Outline Proposal (see: http://telecom.esa.int/opdt/artesapps/artes20demo).

4.3 Proof of Concept (D3) (if applicable)

A Proof of Concept (PoC) is expected to be included when there is a real need and benefit for potential follow-on activities, i.e. for a potential demonstration project or for service roll-out. The inclusion of a Proof of Concept needs to justified.

A Proof of Concept might be considered relevant to proof the feasibility of critical elements of the service / system which can be of technical or non-technical nature, or to secure the further buy-in of potential users / customers. The Proof of Concept can include analysis, simulations, a prototype, or what otherwise is deemed appropriate to proof the concept. Any prototype demonstration should be limited in time and should be restricted to prove that the identified critical elements are feasible (NB: the execution of an end-to-end validation demonstration in a pre-operational environment 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 (preferably within their working environment).

The document shall present the outputs of task 3 and shall include the following sub-elements:

D 3.1 Starting Point and Task Approach: As introduction to this deliverable, information on the starting point (tools, services, products, systems, etc. which are available and planned to be used in the Proof of Concept) shall be presented as well as the planned approach which is used to execute this task, i.e. success criteria, verification and validation approach, user involvement, etc.

D 3.2 Preliminary Outline of the Proof of Concept : This chapter shall present the objective and a first outline of the Proof of Concept including scope, set-up, duration, and user involvement. The critical elements as identified in D 2.4 or a subset thereof are expected to become subject for further feasibility proof within this Proof of Concept.

D 3.3 Proof of Concept Design, Development, and Verification: This chapter shall address the design, development, and verification of a PoC prototype / mock-up.

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 (hardware, software, content, etc.) shall be created, including the related location of the assets. This list is called “Inventory and Status Control” (ISC).

The verification plan including all information related to the verification of the critical elements subject for the “Proof of Concept” (verification plan and procedures, verification results) shall be presented. 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. An analysis of the verification results including potential suggestions for improvements shall be provided.

D 3.4 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.

4.4 Viability Analysis (D4)

In this document the analysis and evaluation of the economic and non-economic viability aspects of the future service and the related system shall be presented.


D4.1 Starting Point and Task Approach: As introduction to this deliverable, information on the starting point (market analysis, business models and plans, etc. which are available and considered the starting basis) shall be presented as well as the planned approach which is used to execute this task.

D 4.2 Market Analysis: This chapter shall provide information on the potential opportunity for the service and the related system, i.e. the total market, the market segmentation, the addressable market and its value, the accessible market, the targeted market share, the key aspects or differentiators of the service/system, the value proposition, and the revenue potential.

D 4.3 SWOT and Competitor Analysis: A SWOT (Strength-Weaknesses-Opportunities-Threats) analysis shall be executed per targeted market segment to assess the attractiveness of the proposed service. A competitor analysis shall be presented, describing competitive / substitute services and solutions in each market segment, the market barriers, and the competitive positioning of the targeted service.

D 4.4 Financial Analysis, Pricing Strategy, and Cash Flow of Service Provider: This chapter shall provide information on the financial aspects of a future service from the perspective of the service provider / consortium.

It shall cover the relevant cost elements including, but not only, information on the capital cost for the implementation of the service (CAPEX), and the expected operational cost (OPEX). The pricing strategy shall be elaborated for each of the targeted market segments. Furthermore, funding requirements, funding sources, key financial indicators such as Break Even Point and NPV, and financial projections for (at least) 5 years shall be provided including a sensitivity analysis for a minimum scenario. Critical success factors shall be identified. Taking into account the results of D 2.2 (definition of the service value chain) the related cash flow streams shall be presented.

D 4.5 Cost/Benefit Analysis for User/Customer: This chapter shall provide information on the viability aspects relevant for the future user / customer community and shall be based



on a Cost/Benefit Analysis (benefits can include operational cost savings, increase of efficiency, socio-economic indicators, public image, etc.)

D 4.6 Non-Economic Viability Analysis: This chapter shall present the non-economic aspects relevant for the viability of the solution and their impact on the development and implementation of the solution.

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. Risks and critical success factors related to this shall be identified, including timing when risks can be mitigated and critical success factors are realised.

D 4.7 Demo Project Outline Proposal Modules 1, 4, 5, and 6: The outputs from the sub-elements D 4.2, D 4.3, D 4.4, D 4.5, and D 4.6 shall be used to generate the Modules 1 (System/Service Opportunity), 4 (Competitive Positioning), 5 (Market Analysis), and 6 (Financial Indicators) of the Demo Project Outline Proposal (see: http://telecom.esa.int/opdt/artesapps/artes20demo)

In advance of the URR and the SSDR various elements of the Viability Analysis (D4) shall be provided which are subject for discussion and review at these review meetings. For the URR the Market Analysis (D 4.2), the SWOT and Competitor Analysis (D 4.3), and a first iteration on the Non-Economic Viability Analysis (D 4.6) shall be presented. For the SSDR the Financial Analysis of the Service Provider (D 4.4), the Cost/Benefit Analysis for the User/Customer (D 4.5), and the evolution of the Non-Economic Viability Analysis (D 4.6) shall be presented. The final review of the complete results of this task (D4) will take place at the Final Review.

4.5 Conclusions and Recommendations (D5)

This document shall present the conclusion concerning the feasibility and viability of the specified service and associated system, wrap up the critical success factors and risks for the implementation of the solution, provide information on the next steps, including the preparation of a potential demonstration project and the involvement of important users and other stakeholders. Particular attention is required with respect to the involvement or establishment of a service provider (bridging the last mile to the user/customer), unless the intended service provider is already part of the bidding consortium.


D 5.1 Risk Analysis: A comprehensive risk analysis shall be done, covering risks related to all aspects of the implementation of a service and its associated system, i.e. technical, operational, economic and non-economic aspects. It shall include mitigation actions, explaining both how the likelihood of a risk event can be reduced and which actions to take in case the risk event occurs.



D 5.2 Recommendations: This chapter shall summarise the conclusions of the feasibility study and present an overview of recommendations for future implementation of the proposed solution, including information on the overall feedback and interest from users and stakeholders to participate in follow-on activities.

Critical success factors which need to be addressed in order to successfully introduce the solution in its environment, as well as showstoppers preventing the progression towards further implementation either via a potential follow-on demonstration project or direct market roll-out shall be clearly elaborated.

D 5.3 Demo Project Outline Proposal (if continuation is planned): This chapter shall present the Outline Proposal for a potential Demonstration Project using the related template accessible under: http://telecom.esa.int/opdt/artesapps/artes20demo. (NB: As the Demo Project Outline Proposal will require inputs from the different tasks of the feasibility study, it is recommended to fill in relevant sections of the demo project outline proposal along the feasibility study upon completion of these tasks and discuss them with ESA at the relevant review meetings.)

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 might 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 coordinated and agreed with ESA. A related output from such an event shall be generated, and shall become part of deliverable D5:

D 5.4 Stakeholder / User Workshop Document: Information shall be compiled from such a workshop, i.e. participants, programme, hand-outs, presentations, results, conclusions.



4.6 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 be self-standing, not requiring to be read in conjunction with reports issued within the study and shall be suitable for non-experts in the field. It shall consist of about 25 pages and shall not contain Proprietary Information.

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.”

The Final Report shall not contain any confidentiality/copyright statement other than the following:

“The copyright in this document is vested in [Company]. This document may only be reproduced in whole or in part, or stored in a retrieval system, or transmitted in any form, or by any means electronic, mechanical, photocopying or otherwise, either with the prior permission of [Company] or in accordance with the terms of ESTEC Contract no [Contract no].“

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,

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.7 Final Data Package (FDP)

Together with the finalised version of the Final Report, the Contractor shall deliver to ESA three 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.8 Project Web Page (PWP)

The Contractor shall produce, as part of the URR package, a Project Web Page according to the template accessible under: http://artes-apps.esa.int/documents. The Contractor shall ensure that the public image of the project is properly portrayed and maintained through the above Web Page.

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 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.9 Digital Media

In order to support a further promotion of the Integrated Applications Promotion programme, Digital Media shall be generated in the course of the feasibility study. Especially digital pictures and/or digital videos related to the Proof of Concept (if included in the study) are considered of relevance and interest.

1. Photography: The Contractor shall deliver at least ten (10) high resolution photos displaying the technology involved and its end users, specifying how the credits should be listed. ESA shall be granted all rights to use these images, for online, print and any other occasions as needed, free of charge. Accepted formats: JPEG.

2. Videos and Animations: In order to promote the results of the project in a visual and illustrative way, a video of minimum 60 seconds shall be delivered. This video can include interviews with users, the project team, the ESA Technical Officer, as well as text and graphical animations. All videos are meant to be published on the IAP website, together with the related Project Web Page (PWP) and must follow the listed format requirements:

CONTAINER FILE EXTENSION

VIDEO CODEC

AUDIO CODEC

RESOLUTION BITRATE

MP4 .mp4 H.264 AAC 1280 x 720 max. 6Mbps max.

Furthermore an End Sequence shall be provided in order to show the contribution of ESA’s ARTES Applications programme and to maintain a corporate design. On request, ESA shall also get access to the digital files of the raw, unedited footage material in the highest quality available.

ESA shall be granted all rights to use the produced video and the footage for its own purposes, free of charge.



3. Print and on-line productions:

Should the Contractor decide to produce any information related to the project in print or in on-line form (folders, flyers, brochures, posters, etc.), coordination with the ESA Technical Officer is required by providing the draft content one (1) month before intended publication, so as to ensure a correct representation of ESA and, where possible, ensure consistency with the ESA Corporate Visual Identity. All material prepared by the Contractor, intended for publication including the internet, shall acknowledge that it is an ESA project carried out under the ARTES programme by the European Space Agency. The Contractor shall display in an appropriate and visible way the ESA’s logo, downloadable at www.esa.int/esalogo.

The obligation shall cease 3 years after contract completion.

4.10 Deliverable Hardware

Article 2 para. 2.1.3 of the Contract applies.

4.11 Deliverable Software and Content

A list of the software and content to be produced or procured shall be presented. Software or content is not expected to be a deliverable.

4.12 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 NM every meeting FR

D1 Stakeholder Analysis & User Requirements Definition

4.1 URR FR

D2 Service and System Definition

4.2 URR SSDR FR

D3 Proof of Concept / Prototype 4.3 SSDR FR FR

ISC Inventory and Status Control (as part of D3)

4.3 FR FR

D4.1 D4.2 D4.3 D4.6

Starting point & task approach Market Analysis & SWOT and Competitor Analsyis & Non-Economic Viability Analysis

4.4 URR SSDR FR

D4.4 D4.5

Financial Analysis & Cost/Benefit Analysis

4.4 SSDR FR

D4 Viability Analysis (complete)

4.4 FR FR

D5 Conclusions and Recommendations

4.5 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.8 URR every review meeting

FR

DC& MC

Document Configuration and Management Control

6.8 URR as necessary FR

CCD Contract Closure Documentation

6.9 FR FR

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

DM Digital Media 4.9 FR FR

NM: Negotiation Meeting KO: Kick-Off URR: User Requirements Review FR: Final Review SSDR: Service and System Definition Review

4.13 Document Confidentiality

All deliverable documents produced in the frame of the project and marked as “Proprietary Information” will be treated in confidence (see Clause 52.2 of the ESA General Clauses and Conditions).

The Project Web Page and the Final Report shall not contain any “Proprietary Information” since they are intended for public dissemination (e.g. the Agency will publish them on the IAP website: http://artes-apps.esa.int/projects.)



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. He shall formulate 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 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

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 who will be the coordinator on consortium level. The Agency will activate within one week from the Negotiation Meeting an account dedicated to the project team.

6.2 Minutes of Meetings (MOM)

Formal written Minutes of Meetings from the meetings that are 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 and be distributed in electronic form to all participants not later than five working days after the meeting. 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:

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://artes-apps.esa.int/documents.

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.

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 negotiation 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 negotiation meeting. The starting point for this risk register are the potential problem areas identified in the Full Proposal (see section C.5 of the Special Conditions of Tender). It shall be updated throughout the feasibility study taking into account any newly identified risks. It shall present the 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.

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 this document. The contents of the Contract Closure Documentation shall conform to the layout provided in Annex A hereto.



6.10 Media Relations and Events

Should the Contractor plan to initiate contacts with media in the context of the study, coordination with the ESA Technical Officer is required by providing the draft content one (1) month before intended publication. Wherever possible, liaison with the Contractor will be established to agree on the text, Frequently Asked Questions, and material to be provided to media.

Should the Contractor plan to participate in trade fairs, exhibitions, or other events where the Project is displayed, coordination with the ESA Technical Officer is required by providing the draft content two (2) months before the event takes place, so as to ensure a correct representation of ESA and, where possible, ensure consistency with the ESA Corporate Visual Identity.

This obligation shall cease after 3 years of contract completion.



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 Location2) Property of

Rights granted / Specific IPR conditions3)

Documentation

Hardware

Software

(delivery in object code)

Other

2 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.) 3 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 57 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 deliverable4

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

4 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 feasibility...

Documents