kSIST FprEN 9241:2025

SLOVENSKI STANDARD
oSIST prEN 9241:2025
01-februar-2025
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: prEN 9241
ICS:
49.020 Letala in vesoljska vozila na Aircraft and space vehicles in
splošno general
oSIST prEN 9241:2025 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

oSIST prEN 9241:2025
oSIST prEN 9241:2025
DRAFT
EUROPEAN STANDARD
prEN 9241
NORME EUROPÉENNE
EUROPÄISCHE NORM
November 2024
ICS 49.140; 49.020
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 draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee ASD-
STAN.
If this draft becomes a European Standard, 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.

This draft European Standard was established by CEN 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.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.

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
© 2024 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 9241:2024 E
worldwide for CEN national Members.

oSIST prEN 9241:2025
prEN 9241:2024 (E)
Contents Page
European foreword . 3
1 Scope . 4
2 Normative references . 5
3 Terms and definitions . 5
4 List of acronyms . 8
5 Execution logic: end-purpose, concepts and constitutive elements . 9
5.1 End-purpose of programme execution logic . 9
6 Concepts . 9
6.1 Programme execution logic . 9
6.2 Execution plan . 9
6.3 Constitutive elements of execution logic . 10
7 Execution logic construction process . 14
7.1 General. 14
7.2 Inputs for the execution logic construction process . 16
7.3 Description of the execution logic construction activity . 17
7.4 Interfaces with the other disciplines . 19
7.5 Process output: execution logic . 21
8 Execution logic change control . 22
8.1 General. 22
8.2 Triggers for updating the logic . 22
8.3 Impact analysis . 23
8.4 Decisions and baselining . 23
9 Capitalization and lessons learned about the logic . 23
Annex A (informative) Contents of an execution plan . 25
Annex B (informative) Example of execution logic for an entire programme . 28
B.1 General. 28
B.2 Description of phases and milestones . 30
Annex C (informative) Examples of specificities to be taken into account . 38
C.1 Incrementally realized product . 38
C.2 Integration of a commercial off-the-shelf (COTS) product . 39
C.3 Integration of a multi-programme product . 40
Bibliography . 41

oSIST prEN 9241:2025
prEN 9241:2024 (E)
European foreword
This document (prEN 9241:2024) has been prepared by ASD-STAN.
This document is currently submitted to the CEN Enquiry.
oSIST prEN 9241:2025
prEN 9241:2024 (E)
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:
o the challenges of a basic logic common to all actors (synchronization);
o the applicable criteria to set up this basic logic;
o the translation of this logic into the programme processes;
— on the other hand, in terms of implementing the execution logic, by:
o the procedures for practical implementation of the management requirements defined in
EN 9200;
o adaptations of the logic according to the various constraints and specificities of the programme,
and justification of these adaptations;
o 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 applies to aeronautical, space and defence programmes. The principles can be extended
to other areas of activity.
oSIST prEN 9241:2025
prEN 9241:2024 (E)
It applies to realization of a single product, of several samples or of a series. It applies 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
life cycle (of a product)
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
life cycle (of a programme)
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.
oSIST prEN 9241:2025
prEN 9241:2024 (E)
3.5
phase of a programme
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, etc.)
or one of its components. In both cases, it represents the supply due under the contract.
oSIST prEN 9241:2025
prEN 9241:2024 (E)
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, etc.
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.
[SOURCE: ISO/IEC/IEEE 15288:2023, modified — Note 2 to entry incomplete]
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, etc.
Note 1 to entry: Each enabling system has a life cycle of its own.
[SOURCE: ISO/IEC/IEEE 15288:2023, 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]
oSIST prEN 9241:2025
prEN 9241:2024 (E)
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 List of acronyms
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
oSIST prEN 9241:2025
prEN 9241:2024 (E)
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.
6 Concepts
6.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, and 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.
6.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:
oSIST prEN 9241:2025
prEN 9241:2024 (E)
— 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 RG.Aero 000 42);
— the industrialization plan (see RG.Aero 000 48);
— the production plan (see RG.Aero 000 43);
— the integrated logistic support plan (see RG.Aero 000 76);
— 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.
6.3 Constitutive elements of execution logic
6.3.1 Strategy elements
6.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.
6.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).
oSIST prEN 9241:2025
prEN 9241:2024 (E)
6.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.
6.3.2 Technical construction elements
6.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.
6.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.
6.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.
6.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.
oSIST prEN 9241:2025
prEN 9241:2024 (E)
6.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 in particular EN 9200);
— 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 RG.Aero 000 76 in particular).
The purpose of integration of processes is to ensure good consistency of the interfaces of the execution
logic with other themes, see 7.4.
6.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, installations, 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.
6.3.3 Risk control elements
6.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;
oSIST prEN 9241:2025
prEN 9241:2024 (E)
— 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.
6.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 6.3.3.4).
6.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 6.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.
oSIST prEN 9241:2025
prEN 9241:2024 (E)
6.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.
6.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 7.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.
7 Execution logic construction process
7.1 General
The construction approach of a programme execution logic (see Figure 1) is presented as a process
characterized by:
— its inputs;
oSIST prEN 9241:2025
prEN 9241:2024 (E)
— 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 +1;
— its actors and position with respect to time.
The constitutive elements of the execution logic are presented in 6.3.

Key
Customer
n-1 supplier
n-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 7.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 7.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.
oSIST prEN 9241:2025
prEN 9241:2024 (E)
7.2 Inputs for the execution logic construction process
7.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, etc.) 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 7.2.3) included in the management specification.
7.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.
7.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;
oSIST prEN 9241:2025
prEN 9241:2024 (E)
— 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.
7.3 Description of the execution logic construction activity
7.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.
7.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.
7.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 7.3.4);
— to the inputs/outputs of the process itself, in particular those from and towards processes
interfacing with it (see 7.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.
oSIST prEN 9241:2025
prEN 9241:2024 (E)
7.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 the execution plan.
7.3.5 Cascading and consolidation in the customer/supplier network
7.3.5.1 General
On the basis of its own execution strategy, and in particular of the structure of the network of suppliers
it intends to contact, the supplier (acting as a level n customer) identifies and positions in the execution
plan the decisions and actions for which it is responsible in its relationship with each of its (level n-1)
suppliers, plus the corresponding meeting points. It deduces and specifies its customer requirements
(see 7.2.3).
The construction approach (see 7.1 – Figure 1) therefore follows a double path in the customer/
supplier network:
— the level n execution logic is broken down into requirements for level n-1;
— the level n-1 execution logic may result in constraints on the level n execution logic and requires
modifications to the higher and/or collateral level(s).
These double paths (iterations) are performed:
— firstly on the execution logics;
— secondly on the execution plans.
The execution plans proposed in reply by the suppliers are successively aligned and consolidated by
their customers in their own execution plans, after negotiating any compromises with both the
suppliers and their upstream customer.
7.3.5.2 Consolidation of execution logics and alignment of execution plans
After iterations for consolidation of the execution logic, each actor constructs their execution plan.
oSIST prEN 9241:2025
prEN 9241:2024 (E)
As for the construction of the execution logic, the level n execution plan constitutes a set of
requirements for developing and establishing level n-1 execution plans. The level n-1 execution plan
can result in constraints on the higher and/or collateral level execution plans.
Each supplier draws up a proposal for an execution plan based on the validated logic and its own
constraints. This proposal is validated by the customer, which ensures consistency with:
— its own plan;
— those of its other suppliers.
This validation is conducted in order to identify compatibility problems, particularly in terms of
inputs/outputs (outside expectations, constraints, supplies), schedule (important meeting points), and
risks. Each compatibility problem is jointly addressed by the customer with the affected supplier(s) and
escalated and addressed at the higher level if necessary.
After handling all of the identified problems, the affected execution plans are reorganized.
The process described above may require several iterations between execution plans and
execution log
...