Methodology
The methodology presented on this site is analytical and descriptive.
It does not prescribe how engineering execution should be organised, managed, or optimised.
Its purpose is to provide a coherent framework for observing execution reality as it unfolds in engineering-driven projects — independent of specific tools, processes, or organisational models.
Analytical focus
The methodological focus lies on execution as a structural phenomenon.
Rather than analysing individual decisions, behaviours, or coordination practices, the methodology examines how execution emerges from the interaction of:
- product structure,
- dependencies,
- phases,
- and workload.
Execution is treated as a property of the product and its state of readiness, not as a derivative of task completion, reporting accuracy, or planning precision.
In this context, execution refers to executability — the ability of a product or assembly to progress into the next state of realisation.
Separation of domains
A central methodological distinction is the separation between:
- definition,
- planning,
- and execution.
These domains interact continuously, but they are governed by different structural logics.
Methodological clarity requires that execution is not reduced to planning artefacts, schedules, or coordination mechanisms.
It must be observed in its own right, based on executability rather than intention.
Execution is not what is planned or reported.
Execution is what is structurally possible at a given point in time.
Structural reference
The primary analytical reference of the methodology is product structure.
Assemblies and sub-assemblies are treated as execution carriers through which readiness, dependencies, and workload accumulate.
This structural reference remains stable across industries and organisational contexts, allowing execution behaviour to be analysed and compared without relying on process-specific terminology.
Phases and readiness
Execution is analysed through implicit phases of readiness, rather than formal milestones or approval gates.
These phases describe transitions in executability, not document status or administrative completion.
Readiness is evaluated as a condition that emerges from the alignment of:
- structure,
- dependency resolution,
- and execution constraints.
It cannot be inferred reliably from isolated indicators.
Visibility and risk
A key methodological concern is the visibility of execution reality.
Execution risk is understood as a consequence of misalignment between assumed and actual executability.
Risk is not treated as an external factor.
It is analysed as an intrinsic property of execution under evolving definition, observable through:
- gaps in readiness,
- unresolved dependencies,
- and workload concentration.
Non-prescriptive stance
The methodology deliberately avoids normative claims.
It does not define:
- best practices,
- maturity levels,
- or optimisation targets.
Instead, it establishes a descriptive language for analysing execution conditions before interventions are considered.
This separation is intentional: premature solutions tend to obscure the structural nature of execution problems.
Relation to Product Flow
This methodological framework underlies Product Flow as an Engineering Execution System (EES).
Product Flow applies this analytical model to make engineering execution explicit, observable, and discussable as a distinct system layer between product definition and production.
Relation to the site structure
All content on this site is grounded in the same methodological framework.
System comparisons, execution principles, use cases, and analytical insights represent different analytical projections of the same execution reality.
Together, they form a coherent analytical corpus, not a step-by-step method or implementation guide.