The statistics are sobering. According to research from Oxford's Bent Flyvbjerg, nearly 90% of mega-projects (infrastructure, rail, defence, …) experience significant cost overruns, schedule delays, or are fundamentally challenged in meeting their objectives [1]. The problem extends beyond infrastructure: McKinsey research found that fewer than 30% of transformations succeed, while only 16% of digital transformations both improve organisational performance and sustain those improvements over the long term. Success rates were even lower in traditional industries, ranging from 4% to 11% [2].
These aren't isolated incidents; they reflect a systemic challenge spanning industries from financial services to healthcare, government, defence, and beyond. The convergence of these two statistics reveals a profound and persistent gap between intent and execution in large-scale initiatives.
What makes this pattern particularly troubling is that organisations undertaking these mega-projects and transformations have had access to model-based systems engineering methodologies and sophisticated requirements management tools for decades. Since the 1990s, enterprises have made sustained investments in systems engineering tools, requirements-management systems, and project-management frameworks. Yet despite this technological sophistication and methodological maturity, high failure rates continue to be reported for projects at this scale. This suggests that the problem is not simply a lack of tools or engineering rigour, but also concerns how large organisations conceptualise, plan, and execute transformational change at scale.
This article explores the root causes of these persistent failures and presents a practical framework for achieving better outcomes.
Large-scale transformation and mega-projects typically begin with ambitious visions and executive mandates, but the process of translating these aspirations into actionable requirements remains ad hoc and surprisingly primitive. Requirements are often gathered through hierarchical consultation processes where business needs flow down through multiple organisational layers, each layer adding interpretation, assumptions, and constraints without rigorous validation. These nascent requirements frequently reflect stakeholder hopes rather than feasible realities, contain inherent contradictions, and are rarely complete or stress-tested against implementation constraints, focusing heavily on the acquisition of technologies and materials at the expense of understanding the requirements on the intended operational and supporting systems.
Once captured in various documents and spreadsheets, these often-deficient requirements then become the fixed foundation upon which Model-Based Systems Engineering (MBSE) methodologies are applied. Sophisticated tools and formalisms such as SysML (Systems Modelling Language) and UML (Unified Modelling Language) are deployed to structure, organise, and trace these requirements across the system architecture. The result is a paradox: organisations invest heavily in formal MBSE languages and rigorous requirements traceability matrices, only to discover that they have meticulously documented flawed assumptions and misaligned stakeholder expectations at scale. The rigour of the modelling language cannot compensate for deficient inputs. In essence, organisations have optimised the process of managing poor requirements rather than improving the process of developing good ones.
Whilst UML and SysML excel at describing system structure (parts, relationships, interfaces), they often fail to provide the integrated behavioural description needed to predict the effects of design changes. As Donald Firesmith has recognised, many MBSE efforts struggle with distributed, disparate information across multiple disconnected and often inconsistent architectural views, compounded by access and control issues across this information landscape [3]. The result is a fragmented model landscape: separate, unintegrated views of process, information flow, chronology, and state that cannot be easily synthesised to understand system behaviour as a whole.
For traditional cyber-physical systems (such as aerospace or automotive systems), the structural and relational descriptions provided by UML and SysML represent an acceptable limitation because the models used for predicting behaviour, assuring safety, and informing regulation are often supplemented by formal analysis. In physical systems engineering, this may include physics-based mathematical models; in software engineering, it may include simulation, formal methods, or statically analysable code. Such techniques provide additional ways to reason about cause, effect, and likely outcomes.
Mega-projects and ICT transformations, however, operate within complex socio-technical contexts shaped by organisational structures, policies, doctrine, and human behaviour. These systems are not readily amenable to mathematical formalisation. Without formally grounded behavioural models to support prediction, organisations lack the rigorous foundation needed to anticipate the consequences of design decisions at the scale of the socio-technical system of interest. What mega-project management requires is a new class of integrated behavioural models: descriptions that capture not just structure but also the relationships between cause, effect, and the wider organisational and operational context in which systems must function.
Behaviour Engineering is a discipline developed and verified by Prof. Geoff Dromey in the early 2000s [4]. Unlike UML and SysML, which focus on structural descriptions, Behaviour Engineering offers an integrated approach to modelling both behaviour and structure together. It enables the constructive and incremental modelling of how agents and elements within a system interact, compose, and behave. The Behaviour Modelling Language (BML) is the formally grounded graphical language that supports this discipline, providing an expressive and human-readable notation for building completely integrated behavioural, compositional, and structural views from natural-language descriptions [4,5].
A BML model describes sequences of actions and concurrent exchanges that occur in response to triggering events. Critically, each action is conditioned by defined circumstances and associated with a definable probability of producing specific changes in state. This makes BML models analogous to executable software code (with the addition of probability), enabling rigorous reasoning about cause and effect.
What sets BML apart is the integration of behaviour with all its enabling factors. Each action, its guarding conditions, expected outcomes, the performers, enablers, and resources involved are explicitly linked within the model. More importantly, these elements connect directly to constraints and requirements, ensuring that obligations are satisfied during execution. This linking of behaviour to structure is intended to provide an integrated view that may be difficult to achieve using standard MBSE languages and tools alone.
BML models can represent behaviours that are performed, enabled, or constrained by the full breadth of organisational capability: doctrine, command structures, coordination mechanisms, organisational hierarchy, personnel, leadership, management, training, facilities, intelligence, policy, and resource allocation. This capability-centric view moves analysis beyond technology alone to encompass the entire socio-technical system, enabling the identification and mitigation of risks to fitness for purpose.
Furthermore, BML models explicitly incorporate and track uncertainty. Beyond representing the probability that an action will produce specific effects under specific conditions, BML can capture higher-level unknowns: the enablement of behaviours, environmental triggers, adversary actions, and actual performance parameters. By making uncertainty explicit within the model, we gain a clearer assessment of prediction reliability and a more honest accounting of our knowledge limitations.
BML-based models enable testable predictions of cause and effect with a clearly defined and justifiable degree of uncertainty. This is precisely what mega-projects and ICT transformations require: not perfectly accurate models of impossibly complex systems, but honest, integrated models that reveal both what we know and what we don't.
BML translates natural language descriptions of intent (scenarios, requirements, regulations, policies, etc.) directly into formal behaviour models. When you describe how something should act, BML captures that description and automatically synthesises the logical architecture that would enable that behaviour to occur. This is powerful because it moves beyond passive documentation to active specification.
As you build BML models from these natural language descriptions, the tool automatically establishes bidirectional traceability between the original source statements and every behavioural element, component, and relationship referenced in the model. This means you maintain complete and verifiable connections between intent and implementation, not as an afterthought but as an integral part of the modelling process.
The most powerful aspect of BML is its behaviour-first approach. Rather than starting with a predefined set of requirements and then trying to model them, you start with a description of desired behaviour. The model then synthesises everything else: the logical architecture, the enabling components, the supporting structure, and even the requirements themselves. In the diagram below, the "source requirement" was not pre-existing; it was generated as a result of capturing the behaviour fragment on the left. Everything else shown in the figure, other than the initial behaviour description, was synthesised from that single behaviour specification.
This approach reverses the traditional requirements-first workflow. Instead of guessing at requirements upfront and then trying to model them, you describe what needs to happen, and the model automatically generates the complete specification of how it should be structured and enabled.
Follow-up posts in this series will focus on how to model using the Kompozition platform.