EN 9241:2025

SLOVENSKI STANDARD
01-februar-2026
Aeronavtika - Vodenje programa - Izvedbena logika
Aerospace series - Programme management - Execution logic
Luft- und Raumfahrt - Programmmanagement - Ausführungslogik
Série aérospatiale - Management de programme - Logique de déroulement
Ta slovenski standard je istoveten z: EN 9241:2025
ICS:
03.100.40 Raziskave in razvoj Research and development
49.020 Letala in vesoljska vozila na Aircraft and space vehicles in
splošno general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 9241
EUROPEAN STANDARD
NORME EUROPÉENNE
December 2025
EUROPÄISCHE NORM
ICS 49.020; 49.140
English Version
Aerospace series - Programme management - Execution
logic
Série aérospatiale - Management de programme - Luft- und Raumfahrt - Programmmanagement -
Logique de déroulement Ausführungslogik
This European Standard was approved by CEN on 19 October 2025.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2025 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 9241:2025 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
1 Scope . 5
2 Normative references . 6
3 Terms and definitions . 6
4 Acronyms . 9
5 Execution logic: end-purpose, concepts and constitutive elements . 10
5.1 End-purpose of programme execution logic . 10
5.2 Concepts . 11
5.2.1 Programme execution logic . 11
5.2.2 Execution plan . 11
5.3 Constitutive elements of execution logic . 12
5.3.1 Strategy elements . 12
5.3.2 Technical construction elements . 12
5.3.3 Risk control elements. 14
5.3.4 Reference documents . 16
6 Execution logic construction process . 16
6.1 General. 16
6.2 Inputs for the execution logic construction process . 18
6.2.1 Strategy for product acquisition by the customer . 18
6.2.2 Supplierʼs strategy and environment . 18
6.2.3 Execution requirements . 18
6.3 Description of the execution logic construction activity . 19
6.3.1 Incorporation of a standard execution logic . 19
6.3.2 Incorporation of execution requirements . 19
6.3.3 Identification of processes and associated meeting points . 19
6.3.4 Association of basic components . 20
6.3.5 Cascading and consolidation in the customer/supplier network . 20
6.4 Interfaces with the other disciplines . 22
6.4.1 General. 22
6.4.2 Interfaces with quality assurance . 22
6.4.3 Interfaces with configuration management . 23
6.4.4 Interfaces with risk management and opportunity management . 23
6.4.5 Interfaces with the procurement strategy . 23
6.4.6 Interfaces with legal management of the programme . 24
6.4.7 Interfaces with safety and dependability . 24
6.5 Process output: execution logic . 24
7 Execution logic change control . 25
7.1 General. 25
7.2 Triggers for updating the logic . 25
7.3 Impact analysis . 26
7.4 Decisions and baselining . 26
8 Capitalization and lessons learned about the logic . 27
Annex A (informative) Contents of an execution plan . 28
Annex B (informative) Example of execution logic for an entire programme. 31
Annex C (informative) Examples of specificities to be taken into account . 42
Bibliography . 46

European foreword
This document (EN 9241:2025) has been prepared by ASD-STAN.
After enquiries and votes carried out in accordance with the rules of this Association, this document has
received the approval of the National Associations and the Official Services of the member countries of
ASD-STAN, prior to its presentation to CEN.
This document shall be given the status of a national standard, either by publication of an identical text
or by endorsement, at the latest by June 2026, and conflicting national standards shall be withdrawn at
the latest by June 2026.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the
following countries are bound to implement this document: Austria, Belgium, Bulgaria, Croatia, Cyprus,
Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy,
Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North
Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and the
United Kingdom.
1 Scope
The scope of the present document is to provide the elements needed for elaborating the programme
execution logic and drafting the execution plan for the realization of a product.
NOTE 1 In this document, the term “logic” alone is sometimes used for “execution logic”.
NOTE 2 In this document, the term “product” is used to designate the object of the program concerned, and the
term “system” is used to designate the product for anything related to system engineering.
NOTE 3 The product is also considered a “system-of-interest” and its enabling systems are also taken
into account.
The execution logic and plan enable customers/suppliers to reach an agreement on how their respective
processes and activities can be organized.
The aim is to enable each actor in the programme to manage their activities with sufficient visibility of
the sequencing of the other stakeholders’ activities.
This document belongs to the documents supporting EN 9200 relating to the programme management
specification.
The present document describes the principles of programme execution logic and defines the
corresponding management requirements. This description is supplemented:
— on the one hand, in terms of execution logic principles, by:
— the challenges of a basic logic common to all actors (synchronization);
— the applicable criteria to set up this basic logic;
— the translation of this logic into the programme processes;
— on the other hand, in terms of implementing the execution logic, by:
— the procedures for practical implementation of the management requirements defined in
EN 9200;
— adaptations of the logic according to the various constraints and specificities of the programme,
and justification of these adaptations;
— the consistency between the basic logic at system level and the logics at subsystem and
constituent levels.
The breakdown of clauses as used in this document gives a gradual understanding of the approach to be
adopted to construct an execution logic. For instance:
— Clause 5 presents the end-purpose of a programme execution logic as well as the associated basic
concepts and the constituents of this logic;
— Clause 6 describes and characterizes the process for building the logic;
— Clause 7 concerns change control to the execution logic;
— Clause 8 concentrates on the importance of capitalization and lessons learned.
This document is applicable to aeronautical, space and defence programmes. The principles can be
extended to other areas of activity.
It is applicable to realization of a single product, of several samples or of a series. It is applicable to any
customer/supplier level, while ensuring consistency between successive levels.
The principles described concern all programme actors, from initial expression of need through to
closure of the programme.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at https://www.electropedia.org/
3.1
product life cycle
set of successive maturity states that the product takes during the different phases of a programme
Note 1 to entry: States of maturity during which the product is gradually processed are typically: concept,
development, realization, use including in-service support, disposal.
Note 2 to entry: The life cycle is generally illustrated as a series of stages, from production (extraction and harvesting
of raw materials) to final disposal (disposal or recovery), including manufacturing, packaging, transport, use and
recycling or disposal.
Note 3 to entry: Notion not to be confused with life profile.
3.2
programme life cycle
set of phases that a programme passes through from its initiation to its closure
Note 1 to entry: The phases of the programme are typically: initial expression of need, feasibility, definition,
development, production, operation, disposal.
Note 2 to entry: The life cycle is a structured and exhaustive scenario, elaborated as a common reference for all
stakeholders concerned and aimed at taking account of all contexts and processes in which the product shall be
involved during its life.
3.3
milestone
significant and planned event used to measure the progress of a programme to allow the next
phase to start
3.4
execution logic
phased and articulated sequence of activities, tasks and milestones covering the entire lifecycle of
the product
Note 1 to article: Execution logic enables each actor to control own activities and coordinate them with those of the
other actors.
3.5
phase
period of a programme, delineated by milestones, during which a coherent and orderly set of activities is
performed to achieve an objective
3.6
process
sequence of correlated or interacting activities that transforms inputs into outputs according to one or
more defined objectives
Note 1 to entry: The inputs of a process are usually the outputs of other processes.
Note 2 to entry: A process shall be planned and implemented under controlled conditions.
Note 3 to entry: A process is characterized by the following elements:
— object;
— objective(s);
— inputs, including prerequisites;
— results/purposes/effects;
— criteria of success;
— rules;
— constraints;
— definition and organization of activities;
— means (human and technical resources) to be implemented;
— methods to be applied.
Note 4 to entry: The French term “procédé” is generally used in the context of manufacturing processes. A process
is called “special process” when the conformity of the outputs cannot be verified by subsequent monitoring or
measurement and requires special provisions for process control.

3.7
product
result of activities or processes
Note 1 to entry: Product categories can be services, hardware, software, processed materials, intermediate work
products from elementary activities, such as documents, models, etc.
Note 2 to entry: In the frame of a product developed to satisfy a customerʼs need, the processes involved are the
expression of the need, the establishment of the definition, the industrialization and the production.
Note 3 to entry: The product can be either a final product to be delivered to a customer (aircraft, equipment) or one
of its components. In both cases, it represents the supply due under the contract.
3.8
programme
coordinated set of technical, administrative and financial tasks, intended to design, develop, realize and
use a product, satisfying a need under the best performance, quality, cost and time conditions as well as
ensuring the support of it and finally the disposal
Note 1 to entry: All or part of a programme can be designated also in the industrial world and in some normative
texts by the words “project”, “contract”, etc.
Note 2 to entry: When the notion of programme is associated with an overall system, the notion of sub-programme
or project is frequently used when addressing the constituents of this system.
3.9
review
systematic review of the results achieved at a given point in a programme to determine their suitability,
adequacy and effectiveness to achieve the defined objectives
Note 1 to entry: The review is a decision aid but shall not be confused with decision making.
3.10
system
arrangement of parts or elements that together exhibit a stated behaviour or meaning that the individual
constituents do not have
Note 1 to entry: A system is sometimes considered as a product or as the services it provides.
Note 2 to entry: In practice, the interpretation of its meaning is frequently clarified by the use of an associative noun,
e.g. aircraft system, weapon system.
Note 3 to entry: A complete system includes all of the associated equipment, facilities, material, computer programs,
firmware, technical documentation, services, and personnel required for operations and support to the degree
necessary for self-sufficient use in its intended environment.
nd
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.46, modified — Note 2 to entry: 2 sentence removed]

3.11
enabling system
system that supports a system-of-interest during the phases of its life cycle
EXAMPLE Production-enabling system, support system, qualification system, infrastructures, deployment system.
Note 1 to entry: Each enabling system has a life cycle of its own.
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.15, modified — Note 1 to entry incomplete]
3.12
system-of-interest
SOI
system whose life cycle is under consideration
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.48]
3.13
task
description of what needs to be accomplished, under set conditions, to achieve an expected and identified
result
Note 1 to entry: A task corresponds to an elementary action of a process. It uses identified resources which may
include personnel, finances, facilities, equipment, techniques and methods.
4 Acronyms
For the purposes of this document, the following symbols and abbreviations apply:
ABL Allocated baseline
CDR Critical design review
COTS Commercial off-the-shelf
DDF Definition data file
DJD Definition justification dossier
DJP Definition justification plan
ELR End-of-life review
FACI First article critical inspection
FBL Functional baseline
FPS Functional performance specification
FR Feasibility review
IIR Individual inspection register
ITAR International traffic in arms regulations
IVV Integration, verification and validation
MDR Mission definition review
MIF Manufacturing and inspection file
MRL Manufacturing readiness level
(N)TS (Need) technical specification
ORR Operational readiness review
PBL Product baseline
PDR Preliminary design review
PL Product logbook
PRR Production readiness review
QR Qualification review
REACh Registration, evaluation, authorization and restriction of chemicals
RJF Requirements justification file
SOI System-of-interest
SRR System requirements review
TPS Technical purchase specification
TRL Technology readiness level
TRR Test readiness review
UF User file
5 Execution logic: end-purpose, concepts and constitutive elements
5.1 End-purpose of programme execution logic
The execution logic is a component of the management reference common to all actors in the programme.
Its end-purpose is to coordinate and synchronize all the activities, taking account of the constraints and
compromises made, the expected results (performance, quality, costs, schedule) and the accepted risks.
Programme execution logic is a programme management approach that:
— reflects the product acquisition strategy;
— allows actors to situate their activities and supplies with respect to the overall programme execution;
— identifies and plans the milestones allowing defined goals verification, decision-making and obtaining
the data needed for this decision-making.
This logic is part of the execution plan.

5.2 Concepts
5.2.1 Programme execution logic
The programme execution logic describes the sequencing of its component elements.
This sequencing represents the sequence of:
— actions and work (work packages, activities or tasks);
— milestones and stop points;
— document productions including contractual deliverables.
The execution logic is described for each level of the technical breakdown structure (or work breakdown
structure), from the “customer” level of visibility to the work execution levels.
The level of visibility given to each actor within a programme (visibility given to programme actors
and/or visibility of the scope of the other programme actors) is to be contractually defined.
The execution logic integrates both the programmeʼs own work and milestones, as well as the work and
milestones interfaced with the programme (external entry and exit points).
The execution logic results from programme execution technical (performance), schedule, budget,
resource, strategic (policy, industrial policy, etc.) constraints.
5.2.2 Execution plan
An execution plan is the document drawn up by a supplier in reply to the execution requirements which
are applicable and which formalize its execution logic.
An execution plan describes, at product and constituentsʼ level:
— the planned scenario (logical and time-based) for execution and its possible variations, providing the
assurance that the objectives will be reached;
— inputs and outputs to the interfaced actors or processes;
— the necessary and allocated human and material resources;
— the schedule;
— the financing commitments.
This execution plan can be stand-alone or completed and detailed by phase, depending on the size of the
programme and the industrial strategy, through one or more specific plans such as:
— the development plan (see EN 9242);
— the industrialization plan (see RG.Aero 000 48);
— the production plan (see RG.Aero 000 43);

— the integrated logistic support plan (see EN 9276);
— the disposal plan.
The supplier ensures that the execution plan and the plans identified in the execution logic are consistent.
Each supplier is responsible for ensuring the synthesis and consistency of its suppliersʼ execution plans
with each other and with its own execution plan.
NOTE At the level furthest upstream, if the customer finds itself faced with several suppliers, it can be
necessary to entrust elaborating and monitoring of the programme execution plan to an entity specifically
mandated for this purpose.
An example of an execution plan template is given in Annex A.
5.3 Constitutive elements of execution logic
5.3.1 Strategy elements
5.3.1.1 Industrial strategy elements
Construction and validation of the execution logic take account of the opportunities and constraints
related to the programmesʼ portfolio and productsʼ portfolio (optimization of multi-programme
products – see C.3).
Construction and validation of the execution logic take account of the industrial policies (choice of
industrial manufacturers and partners), as well as the European, bilateral or international policies.
5.3.1.2 Product strategy elements
Construction and validation of the execution logic are also based on the product strategy covered by the
productsʼ portfolio (product family, product renewal and change, complementarity of products,
reusability).
They are also to be adapted according to the expected number of items (series production products,
unitary products).
5.3.1.3 Technological strategy elements
During construction and validation of the execution logic, the entry points identified by the technological
roadmap are taken into account. This consideration can lead to additional developments such as
upstream study programmes.
5.3.2 Technical construction elements
5.3.2.1 Overview
The life cycle corresponds to the development of an entity (in particular, a programme, a company,
a product or family of products, a process, a system or a solution) from its design to its disposal or
dismantling.
The life cycle is a structured and exhaustive scenario, elaborated as a common reference for all parties
concerned and aiming to take account of all environments and processes in which the product shall be
involved during its life.
5.3.2.2 Product life cycle
The different states of the product can correspond, for example, to levels of maturity, degrees of
achievement towards an availability (readiness level) and to increments or decrements in its capabilities.
As far as possible, transitions between these states are formalized with reviews, the objective of which is
to validate the transition from one state to another, in order to provide points of reference for monitoring
life cycle changes.
The life cycle takes account of the various missions for which the product has to be used and thus its
possible versions or configurations.
The concept of life cycle also extends to all product breakdown levels: each level has its own specific life
cycle, the steps of which can be organized differently from those of other levels.
The programme actors agree on significant situations (linked to product states and environments) to be
taken into account when structuring the life cycle.
5.3.2.3 Nature of the product
Construction and validation of the execution logic also depend on the criticality and complexity of
the product.
In addition, the software activities require integration into an adapted execution logic as they are very
different in nature.
5.3.2.4 Programme life cycle
The life cycle of a programme is organized into phases that show the projected progress of
the programme.
For the different product breakdown levels, the phases may be run in parallel depending on criteria:
— product maturity;
— development duration;
— schedule optimization.
NOTE EN 9277 describes the life cycle of a programme split into phases.
5.3.2.5 Integration of processes
A process explains how the activities are organized, i.e. their interactions, dependency and independence.
A process may also be broken down into sub-processes.
The processes can be executed sequentially, simultaneously, iteratively. They may be invoked by other
processes at any time in the life cycle of the programme.
The processes implemented in a programme are the result of adaptation of the following
“generic processes”:
— agreement processes;
— company processes;
— programme management processes (see EN 9200 in particular);
— technical processes.
Most of the activities associated with a product are grouped into technical processes which can be
implemented at all levels of the product breakdown structure (see RG.Aero 000 50, RG.Aero 000 14,
EN 9212, EN 9215 and EN 9276 in particular).
The purpose of integration of processes is to ensure good consistency of the interfaces of the execution
logic with other themes, see 6.4.
5.3.2.6 Tasks or activities
A task (or an activity) corresponds to an elemental action of a process. It uses identified resources which
may include personnel, finances, facilities, equipment, techniques and methods. The specific resources
(measurement bench, test device, etc.) needed to perform tasks and maintain in operational condition
are integrated into the product breakdown structure corresponding to the system-of-interest; an
execution logic is associated with them and enables convergence points to be identified.
The tasks plus their schedule and supply characteristics are used to consolidate the execution plan.
For each element on the “functions” or “products” breakdown structure and for each type of activity
(engineering, tests, manufacturing, etc.), it is up to the customer to determine the tasks for they wish to
obtain a certain level of visibility.
The execution logic reveals the sequencing and the time-related links between the tasks constituting the
various processes.
NOTE In this document, the terms “tasks” or “activities” are used interchangeably.
5.3.3 Risk control elements
5.3.3.1 Objectives
Setting up reviews, milestones, stop points and meeting points allows achievement of the expected
objectives to be made more reliable, as the programme execution matures. These elements contribute to
reduction of programme risks and guarantee better control of expected compliance
(see RG.Aero 000 67).
The execution of any programme is marked by a large number of decisions, each of which more or less
irreversibly determines the activities of several actors for a given period.
Such decisions can comprise a wide variety of content pertaining to:
— processes: qualification pronouncement, acceptance, authorization from an authority;
— technical choices concerning the product: scenarios, options, variants;
— programme management: start-up, confirmation, re-scheduling or aborting (of tasks, of processes or
of the programme);
— configuration management: designation of a baseline configuration.
These scheduled decisions can be taken unilaterally or jointly.
5.3.3.2 Associated meeting points
Given the challenges and the many actors concerned, each decision or set of decisions requires one or
more meeting points which are needed, in addition to taking the actual decisions themselves, for
the following:
— evaluation of prior work and conclusions concerning whether the predetermined conditions have
been met;
— identification and specification of downstream activities, including their evaluation methods;
— precise definition of expected decisions and of the associated prerequisites;
— scheduling of subsequent meeting points.
The meeting points specifically dedicated to evaluating the progress of work and the conclusions
regarding satisfaction of predetermined conditions may be based on reviews (see 5.3.3.4).
5.3.3.3 Milestones and phases
The scope of the decisions varies widely. A small number of them which more particularly impact the
future and the overall economics of the programme are identified as “strategic decisions”. They generally
involve the end customer, and the specific meeting points associated with them are by convention
identified as programme “milestones”.
These milestones correspond to moments deemed opportune for establishing a clear and consolidated
picture of the results obtained, so that the competent authority may decide on whether or not to commit
resources to continue the work.
A milestone marks the beginning of a phase, a programme portion dedicated to performing a collection
of activities recognized as having to be carried out in a consistent manner with regard to content,
objectives and schedule. Consequently, passing a milestone is dependent on:
— assurance that the previously identified objectives have been reached;
— identification or confirmation of the objectives specified for passing the next milestone.
A programme is thus split into phases, the aim of which is to reach a pre-defined maturity state of the
product corresponding to a particular programme milestone. This breakdown into phases depends on
the level of control expected according to the programme parameters: objectives, inputs, criticality and
associated risks in terms of technicality, cost, schedule, contractual relationship, confidence, etc.
The concept of milestones associated with phases is a method of organizing the general execution of a
programme which, through step-by-step progress and scheduled strategic decisions (see 5.3.3.2),
guarantees that the technical, financial and schedule objectives will be achieved. Identification of
milestones allows interim payments from the customer to their supplier to be contractually established.
5.3.3.4 Reviews
The reviews are presented here as a concept which is an integral part of the execution logic for a
programme. Their organization and implementation are covered by a specific recommendation
(RG.Aero 000 66). Similarly, the specific characteristics of each of the reviews proposed in the standard
logic are detailed in recommendation RG.Aero 000 67.
Reviews are organized on the occasion of meeting points specifically dedicated to evaluating the progress
of work and confirming that predetermined conditions have been met.
A review is intended to prepare and enable one or more expected decisions to be made. The purpose of
the review is to assist with:
— ruling on the validity of the results in relation to the forecasts and contractual requirements;
— allowing to initiate corrective and/or preventive action in the event of drift or insufficiency;
— materializing the transition to the next step and proposing a decision to pass the corresponding
milestone, as applicable.
5.3.4 Reference documents
The customer constructs an initial overall execution logic included in the programmeʼs management and
quality assurance specification, in line with the programmeʼs acquisition strategy (see 6.2.1).
The supplier then constructs the programmeʼs execution logic, for its scope of responsibility, based on
reference documents including in particular:
— the programmeʼs management and quality assurance specification;
— the (need) technical specification [(N)TS];
— the description of expected services (with milestones and logic);
— the list of interfaced systems and equipment;
— the lists of applicable documents, reference documents and documents for information;
— the acceptance conditions;
— the administrative and regulatory provisions;
— the specific clauses, particularly the security and safety clauses;
— the contractual and financial conditions.
The execution logic proposed by the supplier is then validated by the customer.
6 Execution logic construction process
6.1 General
The construction approach of a programme execution logic (see Figure 1) is presented as a process
characterized by:
— its inputs;
— a description of the activity: identification, assembly and consolidation of the various basic
constitutive elements;
— its output(s): the execution logic obtained and validated by level l+1;
— its actors and position with respect to time.
The constitutive elements of the execution logic are presented in 5.3.

Key
Customer
l-1 supplier
l-2 supplier
Figure 1 — Execution logic construction progress
The execution logic is the result of a process that is:
— iterative: the execution logic is constructed by allocating the execution requirements and taking
account of each supplierʼs own internal requirements (including their strategy) at all levels in the
contract work breakdown structure (see 6.3.5);
— recursive: consolidation is obtained by integrating the various execution plans, in particular by the
loopback of the logics.
The programme execution logic is the result of this consolidation and is updated throughout execution of
the programme.
In the approach presented in 6.3, emphasis is placed on assignment of the responsibilities associated with
the various activities. Responsibility for the activity is to be distinguished from its execution, which can
be on a joint basis (integrated team) or even be entrusted to a third party.
6.2 Inputs for the execution logic construction process
6.2.1 Strategy for product acquisition by the customer
The acquisition strategy is all of the principles and guidelines defined by a customer concerning
technologies, cooperation, industrial policy, resources available, support organization, etc. It also
includes environmental elements related to the programme (specific infrastructure, external interfaces)
and the support system for an initial period required for commissioning.
These principles and orientations are input data to identify:
— the information to be collected at each step (for example, from candidate suppliers or interfaced
programmes);
— the expected maturity at each step;
— the decisions to be taken at each step (commitment of the subsequent step and associated resources,
choice of a supplier, a technical solution, a support strategy, etc.).
They therefore specify the conditions to be met for passing each milestone, thereby framing the content,
objectives and schedule of the tasks making up the intermediate phases.
The acquisition strategy covers the entire product life cycle, from the initial expression of need up to
disposal. It is drawn up from the upstream stages of the programme onwards, and is to be gradually
refined according to information collected and decisions taken.
The customer provides its suppliers with the useful data from its acquisition strategy in its requirements
(see 6.2.3) included in the management specification.
6.2.2 Supplierʼs strategy and environment
The supplier has its own objectives as part of its programmes. It is up to the supplier to ensure that the
needs and constraints of its stakeholders have been taken into account. The customer is informed of how
these are taken into account in the execution logic.
6.2.3 Execution requirements
From its acquisition strategy, the customer extracts an initial set of programme execution requirements.
It is then up to the supplier to evaluate these requirements and confront them with its own strategy and
its own environment.
The programme execution requirements are formally expressed in the management specification.
These requirements in particular concern:
— the programme perimeter: “point of origin”, intermediate steps adopted, end of programme,
interfaced programmes;
— the meeting points, milestones and associated reviews;
— the perimeter of the activities requested of the supplier;
— the documents and input and output methods for each of the phases;
— the procedures for passing milestones;
— the conditions applicable to elaborating, consolidating, accepting and updating the execution plan;
— the overall schedule constraints.
These requirements specify the conditions whereby each party shall break down all of the activities that
are imposed on it, and set up meeting points at its own level, taking account of the higher-level
constraints. The link between these various levels is through agreed meeting points, monitored by the
higher level.
The breakdown of all of the activities into milestones and phases constitutes the template for the
execution logic.
6.3 Description of the execution logic construction activity
6.3.1 Incorporation of a standard execution logic
If there is a standard execution logic, predetermined according to products, services and/or the
organization, this is incorporated in order to initiate construction of the execution logic for
the programme.
However, using a standard logic requires adaptation to the programmeʼs specific characteristics, risks
and opportunities.
6.3.2 Incorporation of execution requirements
Each supplier or candidate supplier notes the requirements of its customer. If necessary, the supplier has
its customer specify the nature and scope of the decisions that the customer reserves the right to take,
the content of the expected supplies (data and justifications) and the reviews necessary for passing
each milestone.
The supplier demonstrates to the customer that each requirement related to the construction of the
execution logic has been taken into account in the execution logic submitted to the customer for
validation.
In particular, the supplier demonstrates to the customer that the overall schedule constraints have been
taken into account in the execution logic.
The supplier can then begin to draw up its execution plan.
6.3.3 Identification of processes and associated meeting points
In the work breakdown structure, each supplier lists the activities for which it is responsible, identifies
their inputs and outputs, their links, their durations, how they sequence together and arranges these
activities into processes which are themselves organized and interfaced together.
For each process, the supplier identifies the meeting points needed to measure progress and take the
relevant decisions.
Overall, these meeting points can correspond:
— to the inputs/outputs of process internal activities which determine execution (see 6.3.4);
— to the inputs/outputs of the process itself, in particular those from and towards processes interfacing
with it (see 6.3.4);
— to the outputs of the activities deemed necessary to pass the milestones specified by its customer.
In addition to the reviews associated with the milestones, the customer and supplier shall contractually
agree on other reviews to be conducted as part of the programme.
6.3.4 Association of basic components
Identification of the constitutive activities of the processes and scheduling of the meeting points are
carried out at the same time, to ensure that they are consistent.
The supplier positions the identified meeting points with respect to the specified milestones and
characterizes them in terms of:
— decisions to be taken;
— products and documents to be delivered;
— conditions to be met in this respect;
— reviews to be conducted.
It positions the activities and processes accordingly, while checking that their inputs and outputs are
consistent with each other and with the specified milestones. It thus details the content of the various
phases. In order to keep a meeting point, it can be necessary to identify the intermediate outputs of a
process; synchronization is sometimes at the level of activities belonging to different processes.
Taking account of the above elements, its own constraints and the resources it envisages mobilizing at
each moment, the supplier defines a target schedule for each activity and evaluates the flexibility it has
for overall trade-offs at the process and phase levels.
The schedule of meeting points and their characteristics are written up in t
...