CAATS II C APPROACH TO AIR TRAFFIC S II · Project no.: FP6-2005-TREN-4-Aero- 036826 CAATS II COOPERATIVE APPROACH TO AIR TRAFFIC SERVICES II Instrument: CA - Coordination Action

Project no.: FP6-2005-TREN-4-Aero- 036826

CAATS II

COOPERATIVE APPROACH TO AIR TRAFFIC SERVICES II

Instrument: CA - Coordination Action

Thematic Priority: AERO-2005-1.3.1.4h

D.19.2 – BUSINESS GOOD PRACTICES

Due date of deliverable: 06/06/2009 Actual submissi on date: 09/06/2009

Start date of project: 06/11/2006 Duration: 36 mont hs

Organisation name of lead for this deliverable:

Revision: Draft

Project co-funded by the European Commission within the Sixth Framework Programme (2002-2006)

Dissemination Level

PU Public X

PP Restricted to other programme participants (including the Commission Services)

RE Restricted to a group specified by the consortium (including the Commission Services)

CO Confidential, only for members of the consortium (including the Commission Services)

“Cooperative Approach to

Air Traffic Services II”

Date:

Document ID:

Revision:

09/06/2009

CII-WP1.4-ISD 026-V1.1- DE-PU

Draft

D.19.2 – BUSINESS GOOD PRACTICES - 1 -

This project has been carried out under a contract awarded by the European Commission

© 2009 – All rights reserved

Document Change Log

Revision Edition Date Author Modified Sections / Pages Comments

V1.1 12/06/2009 Isdefe All First public version



Date:

Document ID:

Revision:

09/06/2009


Draft

D.19.2 – BUSINESS GOOD PRACTICES - 3 -



Table of Contents

1. Introduction....................................... ................................................................................. A-3

1.1. Scope and Objectives ....................................................................................................... A-3 1.2. The Context: The ATM Performance-driven Framework ................................................... A-3 1.3. Working Method ................................................................................................................ A-4 1.4. Structure of the Document................................................................................................. A-4

2. Overview of Good Practices for a BC within the ATM OC Validation ........................... A-5

3. Good practices for “framing” the BC................ ............................................................... A-6

3.1. BC Common Definition: but, what is a BC? ....................................................................... A-6 3.2. Characteristics of ATM R&D Projects relevant to BC development ................................... A-6 3.3. BC as part of validation of ATM R&D projects ................................................................... A-7 3.4. Principles Guiding the Development of a BC in Validation................................................. A-8

4. Good practices for supporting the development of th e BC itself within the

validation process ................................. .......................................................................... A-10

4.1. BC First Building Block: the BC Structure........................................................................ A-10 4.2. BC Second Building Block: the Business Strategy .......................................................... A-11 4.3. BC Third Building Block: The Economic Impact Assessment .......................................... A-13 4.4. BC Fourth Building Block: The Business positioning of the OC ....................................... A-15 4.5. BC Fifth Building Block: Funding and Financial Aspects of OC implementation............... A-15 4.6. BC Sixth Building Block: The BC Report ......................................................................... A-16

ANNEX A. REFERENCE DOCUMENTS.

ANNEX B. TERMS AND ACRONYMS.

ANNEX C. WP 1.4.1 ADDITIONAL BUSINESS CASES STUDIES.

ANNEX D. WP1.4.1 WORKING METHOD.

ANNEX E. COMMON FINANCIAL CONCEPTS.

ANNEX F. IMPACT ASSESSMENT COST CATEGORIES.

ANNEX G. ATM PERFORMANCE KPA DEFINITIONS.

ANNEX H. CHARACTERISTICS OF ATM R&D PROJECTS.

ANNEX I. BUSINESS CASE STRUCTURE.

ANNEX J. BUSINESS CASE STRATEGY.

ANNEX K. ECONOMIC IMPACT ASSESSMENT.

ANNEX L. BUSINESS POSITIONING FOR THE OPERATIONAL CONCEPT.

ANNEX M. DEVELOPING THE FUNDING AND FINANTIAL ASPECTS.



Date:

Document ID:

Revision:

09/06/2009


Draft

D.19.2 – BUSINESS GOOD PRACTICES - A-1 -



EXECUTIVE SUMMARY To cope with new challenges in the European air traffic, the European Commission (EC) has launched the SESAR Programme. Currently in its development phase, SESAR aims ultimately at achieving an efficient performance-based Air Traffic Management (ATM) system within the Single European Sky policy targets. Because of its comprehensive scope and vision, SESAR is the most important project ongoing in this field. As such, it sets the key parameters for related R&D activities. In particular, it has adopted the European Operational Concept Validation Methodology (E-OCVM) as integral component of the SESAR Operational Concept Validation. An ATM Operational Concept (OC) is an idea to improve some aspects of the ATM System (benefits) that need investment and/or procedural and behavioural changes (costs) and affect, generally, more than one group of stakeholders with potentially conflicting interests Validating an ATM OC is the process of answering the question: are we designing the right system/procedure? To answer the question correctly, many aspects of the new system should be considered, such as: who are the main stakeholders and what are their requirements? Is it safe? Is it technically feasible? How could it be financed? What is the economic impact on stakeholders? Does it have environmental impact? Will it enhance ATM security? These aspects are taken care in the validation process by building specific Cases (Safety, Human Factors, Environment, and Business) to be approved by stakeholders and decision makers. In particular, the Business Case is a dual-purpose decision-making tool. Its core function, through the use of CBA and other techniques, is to analyze the economic and financial impact of the OC implementation. But more broadly, it should also give a comprehensive view of the impact of the OC, and therefore take into account the conclusions and recommendations of the other validation cases, both quantifiable and qualitative. Furthermore, as noted above, it should do so both globally and for each group of stakeholders affected (e.g., Airspace Users, Airport Operators, and Air Navigation Service Providers). In this sense, the CAATS II project directly supports the SESAR programme with the development of a comprehensive analysis of good practices required for an accurate validation process of an OC. Extending the work done in CAATS I, it approaches the issue from the perspectives of Safety, Human Factors, Environment and Business. Each perspective is analyzed through a systematic Case, consistent with SESAR parameters, then to be integrated through the E-OCVM. This deliverable deals with the Good Practices recommended in structuring the validation Business Case (BC). More specifically, the good practices stated in the document respond to the question: “what should be done to develop a business case when validating an (ATM R&D) OC?” In this sense, the identified good practices can be considered as keystones of the BC process. These good practices are further developed in the document “Business Case Guidance” (D20, Ref. ¡Error! No se encuentra el origen de la referencia. ) in which it could be found a method to perform an ATM BC. The deliverable initial Chapters (1-2) provide an introduction to the BC and overview of the categories of Good Practices for a Business Case: 1) Good practices for “framing” the BC, a work to be done by the project partners previous to start the BC itself to establish a common working ground; and 2) Good practices for supporting the development of the BC itself.

Date:

Document ID:

Revision:

09/06/2009


Draft



- A-2 - D.19.2 – BUSINESS GOOD PRACTICES


.© 2009– All rights reserved

Chapter 3 elaborates on the first category of Good Practices, those related to “framing” the BC on: BC definition, vision on the role of a BC in validation, relationship with other validation cases and guiding principles on developing a BC. The bulk of the document is in Chapter 4 and relates to Good Practices for supporting the development of the BC itself and is structured on the analysis of six Building Blocks in constructing a BC. The first one, the BC Structure, deals with the definition of the problem and of the prospective solution, the operation concept, within the constraints of its maturity phase. Most importantly, it points out the need for a thorough understanding of priorities, motivations and expectations of the relevant stakeholders and decision makers. This is to be achieved not only analytically but also to a major extent through consultations, so that an early consensus on the scope and direction of the work can be achieved. The second one is the definition of the BC Strategy. It focuses on the identification of incremental Costs and Benefits associated with those Key Performance Areas (KPAs) considered significant by the stakeholders, as well as on techniques to establish their relative weights. The importance of consultations with stakeholders is again emphasized. The third one is the assessment of Economic Impact of the OC. It deals with the determination of appropriate Key Performance Indicators for the significant KPA (KPIs, often not easily quantifiable), with various techniques to analyze or estimate impact, and with the need to make explicit the possible variations due to uncertainty. The fourth one, Business Positioning, broadens the analysis by including inputs from other Validation Cases and external sources. Being in essence qualitative, the document recommends the use of SWOT analysis. The fifth Building Block, Funding Prospects, deals with how and at what phase of maturity it would be appropriate to consider the prospects for implementation funding. Finally, the sixth one deals with how to structure the BC Report. It provides guidelines for the Report presenting the results of the Business Case to stakeholders and decision makers. For ease of reference, wherever appropriate, shaded insertions provide a summary of the subject being analysed. Several Annexes provide additional background or more detailed information.



Date:

Document ID:

Revision:

09/06/2009


Draft




1. Introduction 1.1. Scope and Objectives This document presents the research and conclusions on good practices for developing a Business Case (from now on BC) when validating1 an Air traffic Management (ATM) R&D Operational Concept (from now on OC). The document builds on the review of existing BC /Cost Benefit Analyses (CBAs) for OCs done by business and ATM experts in CAATS I (Ref. ¡Error! No se encuentra el origen de la referencia. ) and the first part of the CAATS II conclusions (see Annex C) from the review and further research coupled with continuous interaction with ATM stakeholders in the framework of CAATS II have made possible the establishment of good practices for developing a BC in the context of validating an OC. Good practices referred in this document respond to the question: “what should be done to develop a business case when validating an (ATM R&D) OC?” In this sense, the identified good practices can be considered as keystones of the BC process. These good practices are complemented with the document “Business Case Guidance” (D20.2, Ref. ¡Error! No se encuentra el origen de la referencia. ), where the question how should the business case be developed?” is answered by giving detailed guidance on BC development, being the good practices the drivers. This deliverable makes continuous references to the European Operational Concept Validation Methodology or E-OCVM version 1 and 2 (Ref. ¡Error! No se encuentra el origen de la referencia. and Ref. 4) since the research ultimate objective is to integrate the BC good practices within the E-OCVM structure. The document must, then, be understood in this context. This document follows closely the ongoing SESAR work to define the European ATM Performance Framework (Ref. ¡Error! No se encuentra el origen de la referencia. ), including the identification of ATM high-level objectives for 2020 and beyond, ATM Key Performance Areas (KPAs) and their key performance indicators (KPIs). 1.2. The Context: The ATM Performance-driven Framew ork The annual European traffic demand, forecasted to reach at least 18 Million IFR (Instrumental Flight Rules) flights by 2020 (Ref. ¡Error! No se encuentra el origen de la referencia. ) is challenging the current ATM System capabilities. In response to the ATM challenge, the European Commission (EC) launched the SESAR programme to achieve a future European ATM System able to cope with the increasing demand. The SESAR vision is to achieve a performance-based future European ATM System to best support the increasing societal and States´ expectations for air transport in a safe, environmentally sustainable and cost-effective manner. Therefore, measuring the expected performance of any ATM OC is critical to decide if the OC should be further researched and/or implemented. This evaluation is done in the validation process of any OC. To

1 Validation.

Date:

Document ID:

Revision:

09/06/2009


Draft






measure the performance of the future ATM System the SESAR Consortium has selected the 11 Key Performance Areas (KPAs) developed by ICAO (Ref. ¡Error! No se encuentra el origen de la referencia. ). This selection applies both to R&D and operational levels. The BC developed and part of the validation process of any ATM OC will include quantitative and qualitative impacts on these KPAs that might result from the OC implementation. Annex G includes a classification of the KPA by their focus and the description of each KPA. This annex has been extracted from SESAR D2 (Ref. ¡Error! No se encuentra el origen de la referencia. ) and it is annexed to this document to facilitate its reading. 1.3. Working Method The working method followed to research for BC good practices have been the following: 1. Review of economic impact assessments (BCs and CBAs) in ATM and other sectors establishing

their strengths and weaknesses and lessons learned (Annex C).

Through the analysis of the lessons learned previously gathered:

2. Identification of good practices for framing a BC in the context of ATM OC validation.

3. Proposal of BC Building Blocks and their components (Elements).

Annex D describes the working method used for developing good practices for a BC. 1.4. Structure of the Document This document is composed of the following chapters: Chapter 1 - Introduction defines scope, objectives and working method used for identifying the BC good practices. Chapter 2 – Categories of Good Practices to build a BC within an (ATM R&D) OC Validation process introduces the two categories of good practices when developing a BC in validation. There are explained with further detail in chapters 3 and 4. Chapter 3 - Good practices for “framing” the BC presents good practices corresponding to the first category defined in chapter 3: those to be followed by the members of the Consortium as preliminary work before building the BC itself. Chapter 4 - Good practices for supporting the devel opment of the BC itself within the ATM OC Validation describes the set categorized as the practices needed to build the BC once the BC framework has been established.



Date:

Document ID:

Revision:

09/06/2009


Draft




2. Overview of Good Practices for a BC within the A TM OC Validation By applying the working method described in Section 1.3 and Annex D, a number of good practices for development of a BC (in the context of validating an ATM OC) have been identified. These good practices are classified in two categories: �� Good practices for framing the BC within the ATM R&D Validation process ( preliminary work):

BCs and CBAs examined in this study are stand-alone processes (Annex C) performed by experts with no interaction with other (project) partners. This leads to the paradox that a project validation and its BC are, very often, processes that are developed in parallel, resulting in a BC falling short of input data from KPAs included in validation (e.g., Safety, Human Factors or Environment). Also, other conclusions refer to the studies results: oftentimes, results are provided by means of graphs and numbers that decision-makers do not relate to their concerns and/or those results are not trusted by them because of the opacity of the process. To solve this type of problems, consensus (on BC-related issues) must be reached by the (project) partners before starting the BC development. At this stage, project partners include the project manager and the validation team. It does not include stakeholders and decision makers because this preliminary work of “framing” the BC should be done prior to involving stakeholders in building up the BC. The points where consensus is needed for framing the BC deals with the following issues: −−−−−−−−−−−− Common definition of a BC - Section 3.1. −−−−−−−−−−−− Characteristics of ATM R&D projects that influence BC development - Section 3.2 and Annex H. −−−−−−−−−−−− BC in validation using the E-OCVM - Section 3.3. −−−−−−−−−−−− Guiding principles for BC development - Section 3.4.

From these issues good practice (s) for framing the BC will be derived.

�� Good practices for supporting the development of the BC itself:

Once consensus has been reached among project partners on the BC “frame”, BC development might start. At this stage, interaction with stakeholders and decision-makers should be strong. Good practices for developing a BC are related to:

−−−−−−−−−−−− BC Structure - Section 4.1. −−−−−−−−−−−− BC Strategy - Section 4.2. −−−−−−−−−−−− Analysis.

∗∗∗∗∗∗∗∗∗∗∗∗ Economic Impact Assessment and the BC Uncertainty: how to deal with it - Section 4.3.

∗∗∗∗∗∗∗∗∗∗∗∗ Business positioning of the Operational Concept (OC): SWOT Analysis - Section 4.4.

∗∗∗∗∗∗∗∗∗∗∗∗ How will the OC it be financed? : Funding the OC implementation - Section 4.5.

∗∗∗∗∗∗∗∗∗∗∗∗ Presentation of the BC results – Section 4.6.

Date:

Document ID:

Revision:

09/06/2009


Draft






3. Good practices for “framing” the BC 3.1. BC Common Definition: but, what is a BC? In the review of the impact assessment studies done as the first part on this work, often the term “BC” is used interchangeably with other terms such as Return on Investment (ROI), Cost Benefit Analysis (CBA), and Cost Assessment.. This confusion in terms is more than a semantic problem: it might give way to emphasize, for instance, the financial elements involved in the BC disregarding the “soft” aspects. Furthermore, some managers might think they require a BC, but really they need a project plan, business plan or operating budget to address the given situation. All too often, people will bring forward a “business case” for consideration, when what they really are supplying is a sales presentation for a specific idea that explores only one option. Annex E presents the definition of the most commonly used financial concepts. As example, the study “APR Business Case Assessment” done by Eurocontrol in 2004 (see Annex C for more detailed information on the study) provides, in fact, a framework for CBA when implementing the Airport Operations Programme (APR). It gives financial data but it does not provide all information relevant (human factors, environmental impact, soft benefits) for stakeholders to decide on the APR implementation. So, the study title “Business Case” is misleading; it should say “CBA” assessment. It is, therefore, necessary that the first action (and first good practice) when developing a BC case should be the agreement by all the parties involved on a common definition and expectations. Basis for the discussion should be that the understanding that “A good BC predicts business outcomes (different options) but in order to do so credibly it has to communicate much more than projected cash flow” (Ref. 10). Good practice 1: Common understanding (and consensus) about the BC definition

•••••••••••• Agree on a common definition and expectations of a BC. The definition should be clear and acceptable to different (internal) actors of the project: project management and validation team.

3.2. Characteristics of ATM R&D Projects relevant t o BC development The ATM R&D projects have the some characteristics relevant to the business case development (further information on characteristics of ATM R&D projects can be found in Annex H): •••••••••••• Different project maturity levels to take into account.

•••••••••••• Outcomes may have a long time (10-20 year) horizon.

•••••••••••• Medium size projects with generally many parties and technologies involved.

•••••••••••• Stakeholders (and decision-makers) with different interests.

•••••••••••• Externalities (legal, economical and social) might play an important role in the project.



Date:

Document ID:

Revision:

09/06/2009


Draft




•••••••••••• Risk and uncertainty intrinsically high (on R&D projects), though decision-makers attitude towards risk and uncertainty differs from commercial ventures.

These characteristics determine the approach taken for the BC of ATM R&D projects and they should be known by the project partners involved in validation (that includes the BC leader). As example, the study “Airport CDM Cost Benefit Analysis” done by EUROCONTROL in 2005 and focuses on the financial aspects of a BC, (see Annex C), provides just orders of magnitude in costs and benefits of implementing a CDM. The results are still valid for the users given the maturity of the concept (and if they know what they should be expecting). Good practice 2: Project Partners should be aware (and agree on) of ATM R&D characteristics that affect BC development of an OC

•••••••••••• ATM R&D projects present characteristics that influence the way the BC is developed. These characteristics should be known to all the project partners involved in the BC in order to correctly frame the study:

−−−−−−−−−−−− Due to the long-term horizon, the BC must rely heavily on assumptions. The more advanced the maturity-level of the projects, the more realistic the assumptions (but there will be always assumptions).

−−−−−−−−−−−− Given the many parties and technologies (some to be developed) involved, project risk is high.

−−−−−−−−−−−− Due to the potentially conflicting interests of stakeholder groups, the BC must explicitly incorporate their agreed and realistic expectations (according to the project maturity-level).

−−−−−−−−−−−− Externalities (e.g., economy, politics) might have significant impact when positioning the Operational Concept in the market.

3.3. BC as part of validation of ATM R&D projects As said earlier, evaluation of an ATM OC performance is needed to decide if it might be further researched and/or implemented. Performance evaluation is done through the Validation Process using the E-OCVM, which is the established validation One of approaches of the E-OCVM is the case-based approach. The case-based approach integrates the validation exercises results into ‘cases’ or complementary views, each case focusing on a certain impact of implementing the OC. One of those cases is the BC2. The BC presents quantitative and qualitative results (how well it will perform) should the OC implemented.3

2 The other validation cases are the Safety Case, the Human Factors Case, the Environment Case and the Technology Case. 3 As Caats II develops, there are some projects that are in contact with the CAATS II Business Case Team and are considering the BC within the

OC validation process. One of these projects is SWIMSUIT.

Date:

Document ID:

Revision:

09/06/2009


Draft






Good practice 3: A BC is part (outcome) of the validation process

•••••••••••• Validation of an (ATM R&D) OC using the E-OCVM) is a process whose outcome is structured in cases. One of these cases is the BC. A BC within a validation process is:

−−−−−−−−−−−− A structured process itself.

−−−−−−−−−−−− It should be seamless integrated in the validation process. The validation process should cover all the phases needed in a stand-alone BC.

−−−−−−−−−−−− It provides comprehensive results on the ATM OC implementation and, therefore, receives inputs (quantitative data, conclusions and recommendations) from the other validation cases.

•••••••••••• Partners involved in the BC (as part of the Validation Team) must be knowledgeable of validation, the E-OCVM and how the different validation “Cases” might feed the BC.

3.4. Principles Guiding the Development of a BC in Validation In addition to lack of a clear BC definition, another important lesson learned when reviewing impact assessment studies in ATM4 was that, in a significant percentage, stakeholders and decision-makers looked at these studies with scepticism. The studies´ lack of credibility was due to several reasons: no reliable input data sources; no use of established methodology to develop the case; stakeholders’ misguided expectations; and either not enough guidance on cost/benefit modelling or the perception of excessive reliance thereon. The reasons abovementioned have derived in some good practices when performing a BC: (i) there must be a consensus on assumptions and sources; and, (ii) the rationale of the process followed to reach the conclusions must be understandable to stakeholders and decision makers. These practices are guiding principles when building the BC and must be followed by all the partners involved.

4 This was the first step of the working method used in this study as reflected both in section 1.3 and Annex D.



Date:

Document ID:

Revision:

09/06/2009


Draft




Good practice 4: Establishing Credibility throughout the BC process

•••••••••••• Establishing credibility should be the guiding principle for all partners involved in the BC:. •••••••••••• Focusing on stakeholders and decision-makers expectations and constraints. •••••••••••• Convincing stakeholders and decision-makers on the process validity and the soundness of the BC

conclusions and recommendations by:

−−−−−−−−−−−− Consulting with stakeholders and decision makers through the BC process.

−−−−−−−−−−−− Building the BC in a way that all decision makers, independently of their professional background, would understand the conclusions. Complex analytical tools should therefore be seen as supporting (rather than substituting for) the reasoning leading to those conclusions.

−−−−−−−−−−−− Being transparent on data, assumptions and cost/benefits models because, in principle, readers of a BC must travel the same road (and reasoning) as of its developers.

−−−−−−−−−−−− Connecting evidence (numbers and other qualitative measures) to conclusions through a convincing rationale. The BC should present clear evidence and reasoning consistent with the financial models.

Date:

Document ID:

Revision:

09/06/2009


Draft






4. Good practices for supporting the development of the BC itself within the validation process

Once the BC “frame” has been agreed by project partners, BC development itself might start on solid ground. The studies examined as part of this deliverable included both BCs and CBAs and impact assessment methodologies such as MEDINA, ATOBIA and EUROCONTROL Guidelines for CBAs (Annex C and Ref. 10 and Ref. 25). One conclusion from both the studies and the methodologies is that a BC is, firstly, a (structured) process composed by building blocks. Each building block should describe certain aspect of a BC (structure, strategy, economic impact assessment, positioning of the OC, funding, reports) on which next block is built. As result of the research, we have defined the BC as usually composed by six building blocks. These building blocks might be organised (and renamed) but they should be always included in a BC. “D20 Guidance material for typical BC” provides a detailed methodology based on these building blocks. Good practice 5: Developing the BC through building blocks

•••••••••••• A Business Case is usually composed of Building Blocks:

1) Structure; 2) Strategy; 3) Economic Impact Assessment; 4) Business positioning for the Operational Concept; 5) Funding; and 6) BC Reporting.

•••••••••••• The BC building blocks should be embedded in the Validation (E-OCVM) steps.

4.1. BC First Building Block: the BC Structure The Structure is the first building block of a BC and usually addresses the following two aspects: •••••••••••• Project Overview.

−−−−−−−−−−−− Understanding the problem. −−−−−−−−−−−− Understanding the proposed solution (so-called OC). −−−−−−−−−−−− Identification of the stakeholders and decision-makers. −−−−−−−−−−−− Identification of the project maturity level according to the E-OCVM project lifecycle stages.

•••••••••••• BC Fundamentals.

−−−−−−−−−−−− Team involved in the BC development. −−−−−−−−−−−− BC Context: what a BC represents in the context of a specific validation process, so that a

common understanding and the Stakeholders´ expectations could be achieved.



Date:

Document ID:

Revision:

09/06/2009


Draft




Good practices 6: Developing the BC Structure

•••••••••••• The BC Structure is the first building block of a BC. It should be started once the preliminary BC “framing” has concluded.

•••••••••••• The BC Structure deals with the following aspects:

−−−−−−−−−−−− Project Overview. It refers to:

∗∗∗∗∗∗∗∗∗∗∗∗ Understanding the problem and the proposed solution (so-called OC). ∗∗∗∗∗∗∗∗∗∗∗∗ Identification of the stakeholders and decision-makers. ∗∗∗∗∗∗∗∗∗∗∗∗ Identification of the project maturity level according to the E-OCVM project lifecycle stages.

� This aspect is fully covered by the current version of the E-OCVM. Good practices for

this element are covered in E-OCVM corresponding steps.

−−−−−−−−−−−− BC Fundamentals deals with the BC Team and the common agreement of the BC Context (BC common definition, ATM characteristics and stakeholders expectations with respect to the BC). For a correct development of these elements, the following good practices apply:

∗∗∗∗∗∗∗∗∗∗∗∗ BC Team Management:

� Appointment by the Validation Manager of a BC coordinator with expertise in the ATM R&D validation process and in the development of BCs.

� Recruitment of a multidisciplinary BC Team including a representation of all stakeholders groups.

∗∗∗∗∗∗∗∗∗∗∗∗ Get to know the BC Context through:

� Working sessions held for all members the BC Team to get an agreement on the BC Context.

� Plenary session with all interested stakeholders/decision makers to validate the BC Structure designed by the BC Team. If necessary, update the BC Structure with suggestions and comments gathered in the Plenary Session.

•••••••••••• The key to build the BC Structure: Communication, Communication & Communication.

More information can be found in Annex I.

4.2. BC Second Building Block: the Business Strateg y Once established a common ground among the BC Team on concepts, expectations, effort to be taken and responsibilities, the next step is to design the appropriate strategy to develop the BC. The following Elements define the BC Strategy:

Date:

Document ID:

Revision:

09/06/2009


Draft






•••••••••••• Scope and Boundaries: The Ancillary and Core Models .

−−−−−−−−−−−− Which benefits and costs should be included? −−−−−−−−−−−− Where are the benefits and costs coming from?

•••••••••••• BC Scenarios for obtaining the benefits.

−−−−−−−−−−−− Which scenarios should be considered? •••••••••••• Assumptions and Data Sources.

−−−−−−−−−−−− How to deal with future events? Define and justify the assumptions taken. −−−−−−−−−−−− How should benefits and costs be converted into monetary value? −−−−−−−−−−−− What reliable data sources are available?

Good practices 7: Developing the BC Strategy

•••••••••••• The BC Strategy is the second Building block of a BC. It builds on the BC Structure. •••••••••••• Good practice for building the BC Strategy are:

−−−−−−−−−−−− Define the Scope and Boundaries of the BC:

∗∗∗∗∗∗∗∗∗∗∗∗ Identify the KPAs and KPIs for the BC. (Which benefits and costs should be included in the BC?). The identification should be done simultaneously with the identification of the KPAs and KPIs for the overall validation process, and be consistent with it.

∗∗∗∗∗∗∗∗∗∗∗∗ Prioritise Stakeholders/Decision Makers KPAs/KPIs using MCDM (Multi-criteria Decision Making) Tools.

∗∗∗∗∗∗∗∗∗∗∗∗ Identification of the Benefit and cost Mechanisms for all Stakeholder Groups (Where are the benefits and costs coming from?).

−−−−−−−−−−−− Define Scenarios for benefits (and costs) calculations.

∗∗∗∗∗∗∗∗∗∗∗∗ Consider Baseline scenarios versus alternative Deployment scenarios.

∗∗∗∗∗∗∗∗∗∗∗∗ Coordinate with Validation Manager to verify if the scenario(s) are able to provide results for the identified benefits.



Date:

Document ID:

Revision:

09/06/2009


Draft




−−−−−−−−−−−− Assumptions.

∗∗∗∗∗∗∗∗∗∗∗∗ Given the characteristics of the ATM R&D projects (see Section 3), assumptions (values) on parameters and conditions are always present when developing the BC. The BC Team should agreed on the assumptions and justify them to achieve credibility for the BC.

∗∗∗∗∗∗∗∗∗∗∗∗ Assumptions should be justified by explaining the reason why their values were taken, referring to accredited sources or expert judgment. In this last case, reference to the expert(s must be included).

∗∗∗∗∗∗∗∗∗∗∗∗ Links among assumptions should be taken into account to avoid unrealistic expectations.

−−−−−−−−−−−− Data Sources.

∗∗∗∗∗∗∗∗∗∗∗∗ Data sources should be reliable and referenced in the BC, including when possible, other studies where the data sources have been used.

−−−−−−−−−−−− Communication: key to a successful development of the BC Strategy.

∗∗∗∗∗∗∗∗∗∗∗∗ At least one BC Team working session (internal to the consortium) at the start of the task and one ”conclusions” session at the end of the BC strategy development should be held.

∗∗∗∗∗∗∗∗∗∗∗∗ One plenary session at the end of the BC Strategy development to present the results and enforce the stakeholders buy-in of the BC process.

More information can be found in Annex J. 4.3. BC Third Building Block: The Economic Impact A ssessment The assessment of the project impacts requires: i) estimation of all identified KPIs and, ii) assignment of weights expressing the relative importance of each KPI. The method to be selected for estimating the identified KPIs depends on a number of factors including the project lifecycle phase, the assessment objective, and availability of resources. Two broad categories of impact assessment methods can be distinguished depending on the type of data available (KPIs). If the available data for measuring the impacts are “objectively” derived, then we have the case of quantitative methods; in contrast, if the available data are derived subjectively, i.e., through expert judgments, then, we have qualitative methods. In what follows, a concise description of applicable quantitative and qualitative impact assessment methods is provided. Good practices 8: Developing the economic impact assessment

•••••••••••• The economic impact assessment is the third Building Block of a BC process and builds on the BC Strategy.

Date:

Document ID:

Revision:

09/06/2009


Draft






•••••••••••• Good practices for the economic impact assessment are:

−−−−−−−−−−−− Impact assessment requires: i) estimation of all identified KPIs, ii) assignment of weights expressing the relative importance of each KPI.

−−−−−−−−−−−− Depending on the data availability, KPIs can be quantifiable or measured subjectively (qualitative). Both types of KPIs must be considered in the impact assessment.

−−−−−−−−−−−− Quantitative impact

∗∗∗∗∗∗∗∗∗∗∗∗ For quantifiable KPIs, two techniques can be applied: for KPIs that can be expressed in monetary terms, the cost-benefit analysis. For KPIs that cannot be expressed in monetary terms, the cost-effectiveness technique is used. Each technique to be used should be explained in detail in an annex of the BC Report.

∗∗∗∗∗∗∗∗∗∗∗∗ Standard Data Sources exists for quantitative analysis. However, as much as possible, the values should be customized to reflect particular conditions of the project.

∗∗∗∗∗∗∗∗∗∗∗∗ There are several methods to quantify the impact depending in the techniques used for quantifying the KPIs: NPV; IRR; CBR.

−−−−−−−−−−−− Qualitative impact:

∗∗∗∗∗∗∗∗∗∗∗∗ For KPIs that cannot be quantified, the assessment requires the judgment of an expert or experts. The DELPHI and the Analytic Hierarchy Process can be used when the estimation is focused, respectively, on the absolute magnitude or on the relative magnitude of the impacts.

∗∗∗∗∗∗∗∗∗∗∗∗ There are no standard references in the case of qualitative analysis, judgments tend to be project-specific and it is not transferable even among similar projects.

∗∗∗∗∗∗∗∗∗∗∗∗ A variety of methods exist for the non-quantitative (qualitative) assessment of the impacts. These methods include: i) simple scoring, ii) cost-effectiveness analysis with judgmental data, and iii) cost-benefit analysis with judgmental data.

−−−−−−−−−−−− Uncertainty and risk analysis is a must.

∗∗∗∗∗∗∗∗∗∗∗∗ Because a BC and the assessment of its impact are based on assumptions, there is always room for uncertainty. This uncertainty about the results affects adversely the credibility of the BC and should be managed. Stakeholders and decision-makers need to know the degree of uncertainty of the results and the relative significance of the assumptions in determining the results.

∗∗∗∗∗∗∗∗∗∗∗∗ The measurement of the influence of uncertainty and risk on the results of the impact assessment is a requirement. It might be done using several techniques: Sensitivity analysis, Monte-Carlo analysis, tornado diagrams, and reverse cumulative probability. Several commercial tools already exist for carrying out the uncertainty and risk analysis.

Detailed information can be found in Annex K.



Date:

Document ID:

Revision:

09/06/2009


Draft




4.4. BC Fourth Building Block: The Business positio ning of the OC The Business Positioning will summarise the factors that, although intangible, might significantly influence the development and implementation of the OC. Factors can be external to the process of developing and implementing the OC (i.e., Political, Social, Economic , Technological, and Human Factors) or closely related to it, such as project leadership, technical expertise, availability of required technology, the OC economic impact assessment, the OC safety case assessment, the environmental impact of the OC. The Business Positioning will, then, be a tool to present all the possible risks, uncertainties, and opportunities that are part of the development and implementation of the OC. Given the characteristics of the ATM R&D projects, already mentioned in Sec. 3.2 (e.g., several project maturity levels to deal; long time horizon; many parties and technologies involved; stakeholders with different interests; externalities; risk and uncertainty intrinsically high), this study should be done at a high-level. A comprehensive and probed tool for this type of studies is the SWOT analysis. Good practices 9: Developing the SWOT Analysis

•••••••••••• Business positioning of the OC is the fourth Building Block of a BC. It builds on the impact assessment, inputs from other validation cases and external sources.

•••••••••••• In addition to the impact assessment, decision-makers need a global picture of the advantages,

weaknesses, opportunities and threats of implementing the OC. The most used technique is the SWOT Analysis. SWOT analysis will be developed at different levels depending on the maturity of the OC.

•••••••••••• The analysis SWOT will be based on data from very different sources, but especially from: (i)

conclusions and recommendations from other Validation Cases (e.g., Human Factors, Environmental, Safety, Technological and others) and, (ii) the impact assessment of the BC.

•••••••••••• The result should be a comprehensive view of the OC positioning in the market.

More detailed information can be found in Annex L. 4.5. BC Fifth Building Block: Funding and Financial Aspects of OC implementation The preceding Building Blocks will have provided comprehensive data as to the estimated costs and benefits of the OC, its non-quantifiable features, and its responsiveness to stakeholders’ priorities. If the conclusions are broadly positive and the specific economic indicators are satisfactory, the funding of its implementation would be justified. This, however, does not necessarily ensure that it will happen, particularly in view of the number of stakeholders and the magnitude of the amounts involved. A realistic and constructive analysis of Funding Prospects (FP) is therefore an important component of the BC, and the validation process should assess if and to what extent it has been considered.

Date:

Document ID:

Revision:

09/06/2009


Draft






Good practices 10: Developing the Funding and Financial aspects

•••••••••••• BC Funding is the fifth building block of a BC. The OC Funding Prospects are recommendations on how to mobilize the necessary funding, primarily though not only, for the implementation of the OC.

•••••••••••• BC Funding is composed of the following Elements:

−−−−−−−−−−−− Understanding Stakeholders’ requirements and expected benefits −−−−−−−−−−−− Assessing Revenue Streams −−−−−−−−−−−− Developing Funding Structures

•••••••••••• Good practices to deal with BC Funding are:

−−−−−−−−−−−− Systematic consultation with Stakeholders and (in Phase V3) with Decision Makers; −−−−−−−−−−−− Analysis of Stakeholders’ economic impact assessment; −−−−−−−−−−−− Analysis of expected and potentially enhanced revenue streams; −−−−−−−−−−−− Testing of alternative structures for allocation and/or re-allocation of revenue streams.

•••••••••••• Funding prospects’ options should be recommended in the BC Report, to support the financial

feasibility of implementing the Operational Concept.

More detailed information can be found in Annex M. 4.6. BC Sixth Building Block: The BC Report The BC Report is the presentation of the BC to the stakeholders and decision-makers. All the work done previously is condensed in this document that will be the tool for decision taking on the continuity of the Operational Concept development or implementation



Date:

Document ID:

Revision:

09/06/2009


Draft




Good practices 11: Writing the BC Report

•••••••••••• The BC Report is the sixth and last building block of a BC. •••••••••••• The BC Report is composed of the following Elements:

−−−−−−−−−−−− The BC Report outline.

−−−−−−−−−−−− The BC Conclusions and Recommendations. Conclusions derived from the BC impact assessment and the Business positioning analysis.

•••••••••••• Good practices for the BC Report are:

−−−−−−−−−−−− To understand the BC rationale, the decision-makers must travel the same road as that of the BC developers. The outline of the BC report follows of the same structure as the Building Blocks.

−−−−−−−−−−−− In order to gain credibility, all the assumptions, source data, simulation techniques, calculations, and expert judgments must be documented.

−−−−−−−−−−−− The conclusions and recommendations must be derived from the impact assessment, including the sensitivity and risks analyses, and/or from the SWOT analysis.

−−−−−−−−−−−− The conclusions and recommendations must be linked to the business objectives.



Date:

Document ID:

Revision:

09/06/2009


Draft

D.19.2 – BUSINESS GOOD PRACTICES



AAAnnnnnneeexxx AAA... WWWPPP 111...444...111 AAAddddddiiitttiiiooonnnaaalll BBBuuusssiiinnneeessssss CCCaaassseeesss

SSStttuuudddiiieeesss...

AAAnnnnnneeexxx BBB... WWWPPP111...444...111 WWWooorrrkkkiiinnnggg MMMeeettthhhoooddd...

AAAnnnnnneeexxx CCC... CCCooommmmmmooonnn FFFiiinnnaaannnccciiiaaalll CCCooonnnccceeeppptttsss...

AAAnnnnnneeexxx DDD... IIImmmpppaaacccttt AAAsssssseeessssssmmmeeennnttt CCCooosssttt CCCaaattteeegggooorrriiieeesss...

AAAnnnnnneeexxx EEE... AAATTTMMM PPPeeerrrfffooorrrmmmaaannnccceee KKKPPPAAA DDDeeefffiiinnniiitttiiiooonnnsss...

AAAnnnnnneeexxx FFF... CCChhhaaarrraaacccttteeerrriiissstttiiicccsss ooofff AAATTTMMM RRR&&&DDD PPPrrrooojjjeeeccctttsss...

AAAnnnnnneeexxx GGG... BBBuuusssiiinnneeessssss CCCaaassseee SSStttrrruuuccctttuuurrreee...

AAAnnnnnneeexxx HHH... BBBuuusssiiinnneeessssss CCCaaassseee SSStttrrraaattteeegggyyy...

AAAnnnnnneeexxx III... EEEcccooonnnooommmiiiccc IIImmmpppaaacccttt AAAsssssseeessssssmmmeeennnttt...

AAAnnnnnneeexxx JJJ... BBBuuusssiiinnneeessssss PPPooosssiiitttiiiooonnniiinnnggg fffooorrr ttthhheee OOOpppeeerrraaatttiiiooonnnaaalll

CCCooonnnccceeepppttt...

AAAnnnnnneeexxx KKK... DDDeeevvveeelllooopppiiinnnggg ttthhheee FFFuuunnndddiiinnnggg aaannnddd FFFiiinnnaaannntttiiiaaalll

AAAssspppeeeccctttsss...

Documents

CAATS II C APPROACH TO AIR TRAFFIC S II · Project no.: FP6-2005-TREN-4-Aero- 036826 CAATS II COOPERATIVE APPROACH TO AIR TRAFFIC SERVICES II Instrument: CA - Coordination Action