An Introduction to System Simulation and Modeling

1.0 The Fundamentals of Simulation

To begin our journey into the world of system modeling, let's first establish the foundational concepts of
simulation. At its heart, simulation is a powerful technique used by managers, engineers, and analysts to
understand, analyze, and improve complex real-world systems. Whether managing an airport, designing a
production line, or planning a public health response, decision-makers often face systems whose behavior is
too intricate to predict through simple observation or intuition. This section will explain what simulation is, why it
is so valuable, and how it provides a more robust alternative to traditional mathematical modeling for dynamic
problems.

1.2 What is Simulation?

At its core, simulation is a method of creating a likeness of a real-world system to study its behavior over time.
The formal definition describes it as:

“Experimentation with a simplified imitation on a computer of a system as it progresses over time, for the
purpose of better understanding and/or improving the systems’ performance.”

Think of it this way: consider the challenge of managing an airport terminal where flight delays are a persistent
problem. A manager needs to answer several critical operational questions:

●​ What are the primary sources of passenger delays?

●​ How many check-in desks should be open during different periods of the day, and where should they be
located?
●​ How many security checkpoints are needed, and where should they be placed?

Answering these questions by experimenting with the real terminal would be disruptive, expensive, and
impractical. A simulation model of the terminal, however, allows the manager to test different layouts, staffing
levels, and process changes on a computer to see their impact on passenger delays before committing to
real-world changes.

1.3 Simulation vs. Mathematical Modelling

While many systems can be described using mathematical models, these models often fall short when dealing
with dynamic complexity. They typically require oversimplified and unrealistic assumptions to remain solvable,
which limits their applicability to real-world problems. Simulation, on the other hand, is specifically designed to
handle dynamic, complex systems with many variables and realistic assumptions.

A key distinction to grasp here is how these two approaches differ:

 Characteristic Mathematical Modelling Simulation Modelling

Static vs. Tends to be static, representing a single point Inherently dynamic, representing system
Dynamic in time. changes over time.

Simplicity vs. Often oversimplified to allow for an analytical Can incorporate high levels of complexity
Complexity solution. and detail.

Assumptions Includes generally unrealistic assumptions to Allows for the use of realistic assumptions
make the model solvable. about system behavior.

Number of Typically limited to a few variables. Can handle a virtually unlimited number of
Variables variables.

Development May need to be redeveloped to represent Models system evolution over time without
over Time different time periods. needing redevelopment.

Because of these differences, simulation is often the better, and sometimes the only, methodology for solving
complex problems where time and variability are critical factors.

1.4 Key Advantages of Simulation

Simulation offers several distinct advantages over direct real-world experimentation.

●​ Cost: It is far less expensive to experiment on a model than on a real system. For instance, an airport
manager can test the impact of a new terminal floor without incurring the massive cost of actually building
it.
●​ Time: Simulation can compress or expand time, allowing for rapid analysis. Assessing the impact of a new
motorway on traffic congestion can be done in minutes on a computer, rather than waiting years for
construction to finish.
●​ Replication: It allows for the controlled study of rare or non-repeatable events. A researcher can study the
impact of a Tsunami on fish populations multiple times under different conditions, an impossibility in the real
world.
●​ Safety: It provides a risk-free environment for testing dangerous scenarios. An air traffic control manager
can test new rules for aircraft separation without endangering lives.
●​ Legality: It allows for the exploration of illegal or prohibited actions. An airline can assess the business
impact of introducing night flights, even if they are currently forbidden by law.

1.5 System Classifications

To select the correct simulation technique, it is essential to first classify the system being studied. Systems can
be categorized along several key dimensions.

●​ Deterministic Systems: These are systems where behavior is completely known and predictable. If a train
station has a fixed number of passengers arriving every minute and trains arrive at precise intervals, the
number of people on the platform at any given time can be calculated exactly. The simulation results for
such a system have no variability.
●​ Stochastic Systems: In these systems, behavior is not completely predictable and involves random
variables. The information about these variables is often captured through probability distributions. For
example, the duration of tuberculosis treatment might be described as a Normal distribution with a mean of
60 days and a standard deviation of 6 days, meaning most patients will be treated for a period between 42
and 78 days.
●​ Terminating Systems: These systems have a natural start and/or end point. A flight from London to
Frankfurt is a terminating system; its operations begin when the aircraft leaves the gate in London and end
when it arrives at the gate in Frankfurt.
●​ Non-Terminating Systems: These systems operate continuously over time without a specific start or end
event. Air traffic control at an airport is a non-terminating system, as its activities are a continuous stream.
A simulation of this system represents only a partial snapshot of its ongoing operations.

Understanding these fundamentals provides the necessary groundwork for exploring specific simulation
methodologies, beginning with the conceptual framework of System Dynamics.

2.0 System Dynamics: The Conceptual Framework

System Dynamics (SD) is a discipline and a modeling methodology focused on understanding the often
counterintuitive behavior of complex systems as they evolve over time. It provides a framework for moving
beyond simplistic cause-and-effect thinking to see the hidden structures that drive system behavior. In this
section, we will explore the core conceptual tools of SD, including feedback loops and Causal Loop Diagrams
(CLDs), which help us map and understand these underlying complexities.

2.2 Policy Resistance and Dynamic Complexity

One of the key problems SD seeks to address is Policy Resistance, the tendency for well-intentioned
decisions to yield counterintuitive or even negative results. For example, project managers facing a delay often
hire extra staff to speed things up. However, the disruption caused by training new members can lead to even
more delays, worsening the very problem the policy was meant to solve.

Policy resistance arises from the inadequacy of our "mental models"—our internal, often over-simplified, views
of how the world works. This problem is most prevalent in systems with high Dynamic Complexity. Dynamic
complexity is not about the number of components in a system but rather the counterintuitive behavior that
emerges from the interactions among those components over time. It is particularly evident when the
short-term consequences of an action differ significantly from its long-term consequences.
2.3 The Power of Feedback Loops

The most important cause of dynamic complexity is feedback. Feedback occurs when the output of an action
"feeds back" to modify or influence subsequent actions.

Let's walk through a simple "Weapon Race" example:

1.​ Country A develops a new weapon system.

2.​ This is perceived as a threat by Country B.
3.​ In reaction, Country B develops its own new weapon system.
4.​ This action by Country B is then perceived as a threat by Country A, prompting it to develop even more
weapons.

This cycle, where an action by one entity creates a reaction that feeds back to influence the original entity, is a
classic feedback structure. A Feedback Loop is a diagrammatic structure that represents these
self-reinforcing or self-balancing consequences of actions, revealing how different parts of a system are
interconnected.

2.4 Analyzing Feedback Loops: Reinforcing and Balancing

There are two fundamental types of feedback loops that combine to create the complex behavior of systems.

Loop Type Description

Reinforcing This loop amplifies or reinforces any change in its variables, leading to exponential growth or
(Positive) decline. In the "Fear of exams" example, a delay in revision increases the fear of exams.
Loop This heightened fear and panic reduces the effectiveness of revision, causing further delays.
The initial change (a delay) is amplified through the loop, creating a vicious cycle.

Balancing This loop counteracts change and seeks to move the system toward a goal or equilibrium. In
(Negative) the "Transportation capacity" example, an increase in delivery delay creates a requirement
Loop for more transportation capacity. As more capacity is acquired, the delivery delay is reduced,
counteracting the initial change and bringing the system back toward balance.

2.5 Visualizing Systems with Causal Loop Diagrams (CLDs)

Causal Loop Diagrams (CLDs) are the visual tools we use to map the feedback loops within a system.
Constructing a CLD is often the first step in the System Dynamics methodology, as it helps to capture our
hypotheses about the causes of a system's behavior.

Now, let's focus on a critical principle you must master when building CLDs: the distinction between Causation
vs. Correlation. The links in a model must represent genuine causal relationships, not simply statistical
correlations. For example, while there may be a strong correlation between the number of tuberculosis
infections and the demand for soda drinks (both increase in cold weather), it would be incorrect to draw a link
suggesting that soda demand causes tuberculosis. The model must capture the true underlying cause—cold
weather—which affects both variables independently.

The key rules for constructing effective CLDs are:

●​ Use nouns or noun phrases for variables.

●​ Label the polarity of each link: + if the cause and effect move in the same direction, and - if they move in
opposite directions.
●​ Label the polarity of each loop: 'R' for a Reinforcing loop and 'B' for a Balancing loop.
●​ Make the goals of balancing (negative) loops explicit to clarify their purpose.

While CLDs are invaluable for conceptualizing a system, they are qualitative. The human mind struggles to
accurately trace the consequences of even a few interacting loops. This is why we must translate these
conceptual maps into quantitative simulation models to formally test our hypotheses.

3.0 System Dynamics: Quantitative Modelling

While conceptual maps like Causal Loop Diagrams are excellent for identifying feedback structures, our minds
are not equipped to accurately infer the dynamic behavior that emerges from them. This limitation, known as
Bounded Rationality, is the driving force behind the move from qualitative maps to formal, quantitative
simulation models. Only by building and running a simulation can we truly understand the consequences of the
system's structure. This section details the core components of these models: stocks, flows, and the rate
equations that govern their behavior over time.

3.2 Stocks and Flows: The Building Blocks of SD Models

Quantitative SD models are built upon two fundamental types of variables: stocks and flows. Think of it this
way: a bathtub is a perfect analogy.

●​ A Stock is a variable that represents an accumulation or level at a specific point in time, like the amount of
water in the bathtub. It is the memory of the system, accumulating the history of what has flowed into and
out of it. If time were to freeze, you could still measure a stock. Examples include the money in a savings
account, patients in a hospital, or inventory in a warehouse.
●​ A Flow is a rate that changes a stock over time. In our analogy, the faucet filling the tub is an in-flow, and
the drain emptying it is an out-flow. Flows represent the activities or processes that fill or drain the stocks. If
time were to freeze, a flow would become nil. Examples include annual interest payments, the patient
referral rate, or the production rate of a factory.

The savings account example clearly illustrates this relationship. A customer deposits an initial £3000 (the
initial value of the stock "Account Balance"). The account earns 10% interest per year. This interest payment
is a flow that adds to the stock. Each year, the flow (Annual Payment) is calculated and added to the stock
(Account Balance), causing the balance to accumulate over time.

3.3 Formulating Rate Equations

The core logic of a simulation model is contained in the rate equations, which define how the flows change
over time based on the state of the system. These equations determine the dynamic behavior of the model.
Common structures for rate equations include:

●​ Rate as a fraction of a stock: This structure is used when a flow is proportional to its source stock.
○​ Formula: Rate = Stock x Constant
○​ Example: Payment Rate = Savings x Fractional Interest
●​ Rate as a stock divided by an average period of time: This is common in processes where items spend
an average amount of time in a stock before flowing out.
○​ Formula: Rate = Stock / Average Time
○​ Example: Disease Rate = Individuals Infected / Average Time to disease
●​ Rate as an adjustment to a goal: This structure represents a balancing process where a system tries to
close a gap between its current state (the stock) and a desired state (the goal).
○​ Formula: Rate = (Goal - Stock) / Adjustment Time
○​ Example: Water Transfer Rate = (Target Water Quantity - Water Quantity) /
Water Transfer Average Time

3.4 Modeling Non-Linear Relationships and Delays

Real-world systems are rarely linear and often involve significant delays, both of which are critical drivers of
dynamic complexity.

●​ A Non-Linear Relationship is one where the effect is not proportional to the cause. For instance,
increasing an engineer's working day from 8 to 9 hours might increase output by 12.5%, but increasing it
from 8 to 12 hours will not increase output by 50% due to fatigue and burnout. These relationships are
modeled using Table Functions, which map a range of input values to corresponding output effects,
allowing the model to capture the changing strength of a relationship.
●​ Delays are pervasive in systems and ensure that the consequences of actions are not felt immediately.
There are two primary types:
○​ Material Delays: These represent the time it takes for physical items or resources to move through a
process. For example, newly recruited employees must pass through a training period (a delay) before
they become experienced and fully productive.
○​ Information Delays: These represent the time it takes to collect data, process it, and update
perceptions or beliefs. A company does not react to a single day's sales figures; it takes time to
recognize a sales trend based on multiple observations over a period.

Once these structural components are assembled into a formal model, the next critical step is to ensure that
the model is a trustworthy and credible representation of reality.

4.0 Model Validation and Verification (V&V)

Building a simulation model is only half the battle; ensuring its credibility is paramount for it to be accepted and
used by decision-makers. Validation and Verification (V&V) is the iterative process of building confidence that a
model is an accurate representation of the real system and is useful for its intended purpose. This process is
not a final step but rather an ongoing activity throughout the model development lifecycle.
4.2 The V&V Distinction

Although often used interchangeably, verification and validation are distinct concepts. Let's clarify the
difference.

Process Definition

Verification This answers the question: "Are we building the model right?" It is the process of ensuring
that the computerized simulation model is a correct implementation of the conceptual model or
formal design. As Mielczarek (2009) states, it is "a process of ensuring that the model
transformation from one form to another has been satisfactorily accurate."

Validation This answers the question: "Are we building the right model?" It is the process of ensuring
the model is a sufficiently accurate representation of the real-world system for the specific
problem it is intended to address. According to Robinson (2004), it is "a process of ensuring
that the model is sufficiently accurate in relation to the examined system and the purpose at
hand."

4.3 The Philosophy of Validation: "All Models are Wrong"

This leads us to a fundamental concept in modeling: "all models are wrong." Let's unpack what that really
means. By definition, a model is a simplification and an imperfect representation of reality. It includes
assumptions and operates within defined boundaries, meaning it can never be proven "correct" or "true" in an
absolute sense.

Therefore, the goal of validation is not to prove that a model is right. Instead, the goal is to build sufficient
confidence that the model is useful, illuminating, and fit for the purpose for which it was built. It is a process
of identifying and rectifying flaws to the point where the model becomes a credible tool for policy analysis and
decision-making.

4.4 Key Validation Tests

To build this confidence, modelers conduct a series of tests, each designed to answer a specific question about
the model's adequacy.

●​ Boundary Adequacy Test: "Are the important concepts for addressing the problem endogenous to the
model?"
●​ Structure Assessment: "Is the model structure consistent with relevant descriptive knowledge of the
system?"
●​ Parameter Assessment: "Are the parameter values consistent with relevant descriptive and numerical
knowledge of the system?"
●​ Dimensional Consistency: "Is each equation dimensionally consistent without the use of parameters
having no real world meaning?"
●​ Extreme Conditions Test: "Does the model respond plausibly when subjected to extreme policies,
shocks, and parameters?"
●​ Behavior Reproduction: "Does the model reproduce the behavior of interest in the system?"

While System Dynamics focuses on the continuous accumulation and depletion of resources, other systems
are better characterized by discrete events, which calls for a different modeling approach.

5.0 Discrete Event Simulation (DES)

Now we turn our attention to Discrete Event Simulation (DES), a powerful modeling approach suited for
systems where the state changes only at discrete, distinct points in time. It is particularly effective for analyzing
systems that involve processes, queues, and resource contention, such as manufacturing plants, call centers,
and transportation networks. This section will cover the core objects that make up a DES model and the
conceptual mapping tools used to define the system's logic.

5.2 Core Components of a DES Model

A DES model is constructed from a few fundamental types of objects that represent the elements of the
real-world system.

●​ Entities: These are the individual elements of the system whose behavior is explicitly tracked as they
move through the process. Examples include passengers in an airport, cars in a factory, or patients in a
hospital. The simulation maintains information about the state of each individual entity.
●​ Resources: These are countable items that are required by entities to perform activities, but whose
individual behavior is not tracked. Examples include the number of workers on an assembly line, the
number of unloading bays at a depot, or the number of clerks at a ticket counter. The simulation simply
keeps a count of how many are available.
●​ Events: An event is an instant in time when a significant state change occurs in the system, such as the
beginning or end of an operation.
●​ Activities: These are the operations or tasks that entities engage in, often requiring resources. Activities
are initiated at events, have a specific duration, and change the state of the entities involved.

5.3 Mapping System Logic with Activity Cycle Diagrams (ACDs)

Activity Cycle Diagrams (ACDs) are a primary tool for building a conceptual model in DES. An ACD is a map
that illustrates the life history of each class of entity as a sequence of states, showing how different entities
interact with one another.

ACDs use two simple symbols to represent the states an entity can be in:

●​ Rectangles (Active States): Represent a state that involves the cooperation of different entities and has a
determinable duration (e.g., a patient being treated by a doctor).
●​ Circles (Dead States): Represent a state where an entity is waiting for something to happen and involves
no cooperation with other entities (e.g., a patient waiting in a queue for a doctor to become available).
The "Harassed Booking Clerk" example illustrates how an ACD is built. The system has three classes of
entities: the Clerk, Personal Enquirers, and Phone Calls. Each has its own life cycle:

●​ Clerk Cycle: The clerk alternates between being Idle (a dead state) and either Service a personal
enquirer or Talk to a phone caller (both active states).
●​ Personal Enquirer Cycle: An enquirer starts Outside (dead), then goes through an Arrival (active),
waits in a Queue (dead), and is finally Serviced by the clerk (active).
●​ Phone Call Cycle: A call starts Elsewhere (dead), makes a Call (active), may have to Wait (dead), and
finally gets to Talk with the clerk (active).

By combining these individual cycles, a complete ACD for the booking system is formed, showing how the
Service and Talk activities require the cooperation of the Clerk with either an Enquirer or a Phone Call. This
diagram provides the logical blueprint for the simulation model.

After designing the conceptual model, the next step is to gather the practical data and statistics required to
build and run the simulation.

6.0 Data and Statistics for Simulation Models

The accuracy and reliability of any simulation model depend heavily on the quality of its input data. A model
with a perfectly designed structure can still produce misleading results if it is fed with inaccurate or
inappropriate data. This section covers the types of data required to build a simulation, methods for
representing real-world variability, and the statistical tests used to validate data assumptions.

6.2 Data Categories

The data needed for a Discrete Event Simulation (DES) model can be grouped into three main categories
based on availability and collectability.

●​ Category A (Data Available): This includes data that is already known or has been collected as part of
standard operations. Examples include the physical layout of a plant, technological process specifications,
or the number of machines in a factory.
●​ Category B (Data not available, but collectable): This is data that can be gathered through direct
observation and measurement of the system. Examples include service times for a bank teller, arrival
patterns of customers, or the time between equipment breakdowns.
●​ Category C (Data not available and not collectable): This category applies to data for systems that do
not yet exist or for events that are too rare to observe practically. For example, it is impossible to collect
data on the performance of a proposed factory layout, and impractical to wait 60 years to collect 30 data
points on a machine part that breaks down, on average, once every two years.

6.3 Representing Unpredictable Variability

Many processes within a system are subject to unpredictable, random variability. For example, the time it takes
to serve a customer is rarely the same for every customer. There are two primary ways to represent this
randomness in a simulation model.
 Method Description

Empirical This method uses a histogram of historical data collected from the real system. The
Distributions simulation model then samples values directly from this observed frequency distribution. It
is a direct representation of what has happened in the past but may not capture
possibilities that have not yet been observed.

Statistical This method uses mathematical functions (e.g., Normal, Exponential, Poisson
Distributions distributions) to represent the variability of a process. The simulation samples values from
these mathematical formulas. This approach is powerful because it can generate a wider
range of possibilities and is often based on underlying theoretical properties of the
process.

6.4 Goodness-of-Fit Tests

When choosing to use a statistical distribution, it is important to formally verify that the chosen distribution is a
good representation of the collected data. "Goodness-of-Fit" tests are formal statistical procedures used to
determine if a sample of observed data is compatible with a specific theoretical distribution. Two common tests
used for this purpose are:

●​ The Kolmogorov-Smirnov Test

●​ The Chi-Square Test

These tests help ensure that the statistical assumptions underpinning the model are sound, thereby increasing
the model's credibility.

With the conceptual logic defined and the necessary data gathered, the final piece is to understand how a
simulation program actually executes the model's logic over time.

7.0 Simulation Execution Mechanics

So, how does a simulation program actually manage all these moving parts? To fully appreciate how a model
operates, we need to look under the hood at the "engine" that drives it. This engine is responsible for
managing the flow of simulated time and ensuring that all events and activities occur in the correct sequence
according to the model's logic. This section describes how simulation software manages this complex task.

7.2 The Role of the Simulation Executive

The central component that controls the simulation is known as the Simulation Executive. Its primary function
is to govern the events and activities in which entities and resources engage. To do this, it maintains two key
components:
1.​ A simulation clock to keep track of the current simulated time.
2.​ A calendar (or event list) of all future events that are scheduled to occur.

The executive must perform two functions with perfect accuracy. First, it must schedule events to occur at the
correct time. Second, it must execute those events in the specified logical sequence, ensuring that all
necessary conditions for an activity are met before it begins.

7.3 The Three-Phase Approach

The Three-Phase Approach is a widely used and robust method for implementing the application-specific
logic in a Discrete Event Simulation. This approach categorizes events into two types to manage their
execution.

●​ B-Events (Bound or Booking): These are events whose timing can be predicted and scheduled in
advance. The end of an activity with a known duration is a classic B-event. For example, if a service activity
starts at time t and has a duration of d, its completion can be scheduled as a B-event at time t+d.
●​ C-Events (Conditional): These are events that cannot be scheduled in advance because they must wait
for certain conditions to be met. The start of an activity that requires both an entity (e.g., a customer) and a
resource (e.g., a clerk) to be available is a C-event. It can only occur when the required conditions are
satisfied.

The simulation proceeds by cycling through three distinct phases:

●​ A Phase (Advance): The simulation executive scans the event calendar and advances the simulation
clock to the time of the next scheduled B-event.
●​ B Phase (Bound): The executive executes all B-events that are due at the current clock time. Executing a
B-event (like the end of an activity) may release resources, which could in turn satisfy the conditions for a
C-event.
●​ C Phase (Conditional): The executive repeatedly scans the list of all C-events and executes any for which
the conditions are now met. This scan-and-execute cycle continues until no more C-events can occur in the
current moment. The simulation then returns to the A phase to advance time again.

This journey from high-level system concepts and conceptual diagrams to the detailed mechanics of model
execution provides a comprehensive overview of the principles of system simulation, a versatile and essential
tool for modern decision-making.

How can modelers best perform sensitivity analysis for uncertainties?

Sensitivity analysis is a critical process used by modelers to determine if their conclusions remain robust when
assumptions are varied over a plausible range of uncertainty. To perform this best, modelers should move
beyond simple parameter changes and adopt a rigorous, multi-faceted approach that tests the suitability,
boundary, and structure of the model.

1. Categorizing the Types of Sensitivity

Modelers must distinguish between three distinct types of sensitivity to understand how uncertainty affects their
results:
●​ Numerical Sensitivity: This occurs when changing assumptions alters the specific numerical values of
the results. While all models exhibit this, it is often the least important type in business modeling, where
the goal is usually to understand patterns rather than make point predictions.
●​ Behavior Mode Sensitivity: This is more significant, occurring when a change in assumptions shifts the
pattern of behavior generated by the model, such as moving from smooth adjustment to oscillation.
●​ Policy Sensitivity: This is the most critical for decision-making. It occurs when a change in assumptions
reverses the desirability or impact of a proposed policy.

2. Methodological Approaches to Testing

The sources recommend several techniques for effective sensitivity analysis:

●​ Univariate and Multivariate Testing: Univariate testing involves varying one parameter at a time, while
multivariate testing varies multiple parameters simultaneously to account for nonlinear interactions
where the combined impact of assumptions may not simply be the sum of their individual effects.
●​ Best and Worst Case Scenarios: Modelers should define scenarios where all parameters are set to their
most and least favorable values for a desired outcome. This identifies the plausible bounds of behavior
the system might encounter.
●​ Monte Carlo Simulations: By assigning probability distributions to uncertain parameters, modelers can
run hundreds of simulations to generate dynamic confidence intervals. This is especially useful for
identifying how uncertainty compounds during phases dominated by positive feedback.
●​ Automated Nonlinear Tests (ANT): This "broken model" test uses optimization software to search for
parameter combinations that might generate anomalous or unrealistic results, effectively stress-testing
the model's limitations.

3. Setting Plausible and Extreme Ranges

A Best practice is to test parameters over a range at least twice as wide as initial statistical or judgmental
estimates suggest. This is necessary to counteract the "overconfidence bias," where experts and statistical
tools often underestimate the true level of uncertainty due to measurement errors or faulty model
specifications. Furthermore, modelers should implement extreme condition tests, subjecting the model to
values like zero or infinity to ensure it behaves realistically (e.g., ensuring production stops if the workforce is
zero).

4. Broadening the Scope of Analysis

Modelers often focus too much on parameter values, but results are typically more sensitive to assumptions
about the model boundary and structure.

●​ Boundary Adequacy: Modelers must "challenge the clouds" by making exogenous variables endogenous
to see if adding feedback loops changes the policy recommendations.
●​ Structure Assessment: Testing should include varying the level of aggregation or the assumed
rationality of decision-making rules to see if these structural choices dictate the results.
5. Practical Utility of Analysis

The ultimate goal of sensitivity analysis is to guide resource allocation. If the analysis shows that results are
insensitive to an uncertain relationship, the modeler does not need to waste resources refining that
estimate. Conversely, if a parameter is identified as a high-leverage point—meaning small changes
significantly alter outcomes—it must be estimated with the highest possible accuracy.

In essence, performing sensitivity analysis is like testing a bridge's design. You don't just check if a single
bolt is the right size (parameter testing); you also simulate what happens if the wind hits at an angle you didn't
expect (boundary testing) or if the steel is half as strong as the manufacturer promised (extreme conditions).
By trying to "break" the design in a virtual world, you gain the confidence to build it in the real one.

How can policy resistance lead to unintended side effects?

Policy resistance is the tendency for interventions in complex systems to be delayed, diluted, or defeated
by the system's own response to the intervention itself. It arises because well-intentioned decisions to solve a
problem often trigger unforeseen reactions from other people or nature, which can actually make the initial
problem worse. These unexpected dynamics lead to what are commonly called "unintended side effects."

The Nature of "Side Effects"

In a systemic sense, there is no such thing as a "side effect"; there are simply effects. When we take action,
we produce various consequences. The effects we anticipated or desired are labeled "intended," while those
we did not anticipate, which often feed back to undercut the policy or harm the system, are labeled "side
effects". The existence of these unintended consequences is a primary sign that our mental models—our
internal view of how the world works—are too narrow and flawed to cope with the actual complexity of the
system.

How Policy Resistance Generates Unintended Consequences

Policy resistance and its resulting side effects typically occur due to several systemic factors:

●​ Linear Thinking vs. Feedback Loops: Most people view the world as a series of events with simple
causes (e.g., "inventory is high because sales fell"). However, we are actually embedded in a web of
feedback loops where our results define the situation we face in the future. Policy resistance arises when
we fail to understand the full range of these feedbacks; as we alter the state of the system, other agents
react to restore the balance we upset.
●​ Dynamic Complexity: This refers to counterintuitive behavior that emerges from the interaction of system
elements over time. In complex systems, the short-term consequences of a policy are often the opposite
of its long-term effects. High-leverage policies often exhibit "worse-before-better" behavior, while
low-leverage ones provide transitory improvement before the problem returns even more severely.
●​ Narrow Model Boundaries: Policy resistance occurs when we act as if cause and effect are closely
linked in time and space. In reality, consequences are often distant in time and space from the original
action. By ignoring these distant feedbacks, modelers and decision-makers "cut" the loops that lead to
side effects.
●​ Intended Rationality: Decisions are often intendedly rational, meaning they make sense from a local,
narrow perspective. However, when multiple agents all act with local rationality, their interactions can
 create vicious cycles. For example, firms cutting prices to fill capacity during a slump can inadvertently
trigger a ruinous price war.

Concrete Examples of Policy Resistance

The sources provide several stark examples of how policy resistance leads to disastrous side effects:

●​ Romanian Population Policy: In 1966, the Romanian government banned abortion to increase the birth
rate. While birth rates initially soared, the population resisted by practicing illegal, unsanitary birth control,
leading to a tripling of maternal deaths and a 300% increase in neonatal deaths. Thousands of
unwanted children were placed in state cages, eventually contributing to an AIDS epidemic and a violent
revolution.
●​ Traffic Congestion: Building new motorways to reduce congestion often results in more traffic. The new
capacity makes driving more attractive, encouraging people to take more discretionary trips, buy more
cars, and move further into the suburbs. This feedback loop ensures that traffic volume grows until
congestion is bad enough to deter further travel, effectively negating the benefit of the new road.
●​ Project Management (Brooks' Law): Project managers often hire more staff to speed up a late project.
However, the new staff require training and disrupt existing work, leading to even more delays.
●​ Healthcare Costs: Limiting the drugs that managed-care systems can prescribe can have the unintended
effect of increasing overall costs as patients' health deteriorates without the necessary medications.
●​ Wildfire Suppression: Policies of total fire suppression lead to the accumulation of dead wood, resulting
in larger, hotter, and more dangerous forest fires than if frequent small fires were allowed to occur
naturally.

Avoiding Policy Resistance

To avoid these unintended effects, decision-makers must adopt Systems Thinking, which conceptualizes the
world as a complex set of interconnected elements where "everything is connected to everything else". By
expanding the boundaries of our mental models and using formal computer simulations, we can learn to
anticipate the feedback that lead to policy resistance and identify high-leverage points that lead to
sustainable improvements.

In summary, policy resistance leading to side effects is like trying to squeeze a balloon to make it smaller.
Because you are only looking at the part of the balloon under your fingers (the symptoms), you don't realize
that your pressure is increasing the air density elsewhere, causing another part of the balloon to expand (the
unintended consequence). To actually change the volume, you have to understand the properties of the air and
the rubber as a whole system.

How do time delays impact the speed of organizational learning?

Time delays are a fundamental driver of dynamic complexity and represent one of the most significant
barriers to organizational learning within a system. Because all learning depends on feedback—a cycle of
decisions, actions, and information processing—the speed and quality of that learning are directly dictated by
how long it takes for a system to respond to an intervention.
1. Reduction in the Frequency of Learning Cycles

The most immediate impact of time delays is that they reduce the number of times an organization can cycle
through the learning loop. Learning is an iterative process of invention, observation, reflection, and action.
Long delays between a decision and its observable outcome slow the ability of a team to accumulate
experience and test new hypotheses. For example, in manufacturing, processes with short delays (like
operator errors) have improvement half-lives—the time required to cut defects in half—of only a few months,
whereas complex processes with long delays (like product development) can have improvement half-lives
extending for several years.

2. Confounding of Cause and Effect

Organizational learning is often thwarted because cause and effect are distant in time and space. Human
mental models tend to be "event-oriented" and rely on heuristics that look for causes in close temporal
proximity to the symptoms they seek to explain. When a delay is present, the immediate consequences of an
action may be positive while the long-term results are disastrous, a phenomenon known as
"worse-before-better" behavior. These long delays garble the "reflective conversation" between the learner
and the situation, leading managers to misattribute the causes of success or failure. Consequently,
organizations often redouble their efforts on ineffective "short-term fixes" because the delayed negative
feedback has not yet manifested.

3. Generation of Instability and Oscillation

Time delays in balancing (negative) feedback loops are a primary cause of instability, overshoot, and
oscillation in organizations. When there is a delay in perceiving a discrepancy or a delay in the response to a
corrective action, decision-makers often continue to intervene even after enough action has been taken to
reach the goal. This results in oscillatory behavior, such as "stop-and-go" traffic, the "spiral of impossibility" in
utility capacity, or the "boom and bust" cycles in real estate and commodity markets. This inherent instability
makes it nearly impossible for an organization to control for confounding variables or discern true causal
relationships, further stagnating the rate of learning.

4. Garbling of Feedback and Perception

Delays also exist in the measurement and reporting of information, meaning organizations are often making
decisions based on "stale" data that reflects the state of the system weeks or months in the past. Perceptions
and beliefs are information delays; they do not update instantaneously upon the receipt of new data. If an
organization experiences a failure, the delay in collecting and analyzing that information can mean that by the
time the mental models are updated, the system has already evolved into a different state, rendering the new
knowledge obsolete.

5. Overcoming Delays via Virtual Worlds

Because real-world experimentation is often prohibitively slow, expensive, or dangerous, organizations

increasingly turn to Discrete Event Simulation (DES) and System Dynamics (SD) to create "virtual worlds"
or management flight simulators. These simulations allow for the compression of time, enabling an
organization to gain years of simulated experience in just a few minutes or hours. By dramatically reducing the
delays in the learning loop, virtual worlds provide high-quality, immediate, and undistorted feedback,
allowing teams to discover the long-term consequences of their policies and identify high-leverage intervention
points that would otherwise remain hidden behind real-world delays.

To understand how delays impact learning, imagine steering a massive cargo ship in the fog. Because there
is a long delay between turning the wheel and the ship actually changing course, a novice captain will likely
keep turning the wheel until they see the ship move. By then, they have oversteered so significantly that the
ship will swing far past the intended heading, forcing a violent correction in the other direction. Organizational
learning is like that of a captain: without the ability to "simulatedly" see where the ship is going before the delay
elapses, the organization will continue to overreact to its own momentum, perpetually oscillating between
crises instead of reaching a stable destination.

How to Construct an Activity Cycle Diagram?

An Activity Cycle Diagram (ACD) is a conceptual modeling tool used in Discrete Event Simulation (DES) to
qualitatively describe the structure of a system. It serves as a map that displays the life history and interactions
of each class of entity.

To construct an Activity Cycle Diagram, follow these essential steps:

1. Identify the Entities and Resources

The first step is to distinguish between the objects whose behavior is explicitly tracked and those that are
simply counted.

●​ Entities: These are the individual elements of the system being simulated (e.g., passengers in an airport
or cars in a factory). During the simulation, the computer maintains the state of each entity separately.
●​ Resources: These are countable items whose individual behavior is not tracked (e.g., the number of
workers in a factory). A modeler must decide whether to model an element as an entity or a resource
based on the simulation's objective.

2. Define the States for Each Entity

Each class of entity is considered to have a life cycle consisting of a series of alternating states.

●​ Active States (Rectangles): These represent periods where an entity is engaging in an operation, usually
involving cooperation between different classes of entities. The duration of an active state is known in
advance or can be determined by a probability distribution.
●​ Dead States (Circles): These represent periods where an entity is waiting for something to happen and
involves no cooperation with other entities.

3. Map the Individual Activity Cycles

Draw the life cycle for each entity class as a continuous loop of alternative active and dead states. For
example, in a theater booking system, the Booking Clerk entity may have a cycle consisting of an Idle (Dead)
state, followed by a Servicing (Active) state, then returning to Idle. Entities move from state to state as time
progresses in the simulation.

4. Merge Individual Cycles into a Complete ACD

The combined ACD is created by linking the individual cycles at the points where they interact. This occurs at
active states, where two or more entities must be available to cooperate. In the theater example, the "Service"
rectangle would be the meeting point for both the "Booking Clerk" cycle and the "Personal Enquirer" cycle.

5. Apply the Logic of Events (Three-Phase Approach)

To prepare the ACD for computer implementation, you must understand the logic of how activities start and
end:

●​ C-Events (Conditional): Active states on an ACD typically start with a C-event. These cannot be
scheduled in advance because they depend on the availability of entities and resources.
●​ B-Events (Bound/Scheduled): Active states typically end with a B-event. Because the duration of an
active state is determined at its start, its finishing time can be predicted and scheduled on the simulation's
calendar.
●​ Special Case (Arrivals): Active states that generate new entities, such as Arrival states, are often
treated as a continuous series of B-events driven by an "imaginary machine" with a fixed gestation period.

6. Realization and Data Collection

The final construction involves translating the qualitative ACD into a computerized model using software like
Simul8 or a programming language like C++. This requires collecting data on activity cycle times, arrival
patterns, and system rules to move the model from a conceptual map to a functional simulation.

How to Construct a Causal Loop Diagram?

Causal Loop Diagrams (CLDs) serve as an essential tool in System Dynamics for representing the feedback
structure of a system. They are primarily used to quickly capture hypotheses about the causes of complex
dynamics, elicit mental models from individuals or teams, and communicate the important feedbacks believed
to be responsible for a specific problem. To construct an effective and accurate CLD, modelers must follow a
rigorous set of principles and conventions.

1. Variable Selection and Naming

The first step in constructing a CLD is identifying the key elements of the system, which are represented as
variables.

●​ Use Nouns or Noun Phrases: Variable names should always be nouns, never verbs or action phrases,
because the arrows in the diagram represent the action. For example, use "Costs" rather than "Costs
Rise".
●​ Clear Sense of Direction: Choose names for which the meaning of an increase or decrease is
unambiguous and measurable.
●​ Positive Sense: Use the positive sense of a variable whenever possible (e.g., "Morale" instead of
"Unhappiness").
●​ Right Level of Aggregation: Choose a level of detail that is sufficient to illustrate the logic without
overwhelming the audience with excessive detail.
2. Mapping Causal Relationships

Once variables are identified, they are connected with causal links, represented by arrows.

●​ Causation vs. Correlation: Every link must represent a genuine causal relationship as believed by the
modeler, not merely a statistical correlation from past data. Correlations can break down when policies
change, whereas the underlying causal structure should remain robust.
●​ Intermediate Links: If a causal link is confusing to an audience, disaggregate it by making intermediate
concepts explicit to clarify the reasoning.

3. Assigning Link Polarity

Every causal link must be assigned a polarity, indicated by a plus (+) or minus (-) sign, to show how the
dependent variable changes when the independent variable changes.

●​ Positive Polarity (+): A positive link means that if the cause increases, the effect increases above what
it would have been, and if the cause decreases, the effect decreases below what it would have been.
●​ Negative Polarity (-): A negative link means that if the cause increases, the effect decreases below
what it would have been, and if the cause decreases, the effect increases above what it would have
been.
●​ Unambiguous Polarity: Every link should have a single, clear polarity. If a relationship can be both
positive and negative depending on the circumstances, the different causal pathways must be shown
explicitly.

4. Identifying Feedback Loops

A feedback loop exists when a chain of causal links circles back to the original variable. All dynamics in
complex systems arise from the interaction of two types of loops:

●​ Reinforcing Loops (Positive/R): These loops amplify change, leading to exponential growth or decline.
●​ Balancing Loops (Negative/B): These loops counteract change and seek stability, balance, or a
specific goal.

5. Determining and Labeling Loop Polarity

After loops are identified, their polarity must be determined and labeled with an "R" or "+" for reinforcing loops
and a "B" or "-" for balancing loops.

●​ The Fast Way: Count the number of negative links in the loop; if the number is odd, the loop is negative
(balancing), and if the number is even, the loop is positive (reinforcing).
●​ The Right Way: Trace the effect of a small change in one variable around the entire loop; if the feedback
reinforces the original change, it is positive, and if it opposes the change, it is negative.
●​ Naming Loops: To increase clarity, give each important loop a number and a name (e.g., "Burnout Loop"
or "Midnight Oil Loop") to help the audience understand its function.

6. Advanced Structural Elements

To enhance the realism of a CLD, modelers should incorporate elements that drive dynamic complexity:
●​ Represent Delays: Indicate important time delays in causal links, as they are critical in creating
oscillations and instability.
●​ Explicit Goals: Make the target or goal of every balancing loop explicit, as these goals are often
themselves part of the feedback structure and can change over time.
●​ Actual vs. Perceived Conditions: Distinguish between the true state of the system and the perception
of that state by actors, which is often subject to measurement error, bias, and reporting delays.

7. Layout and Presentation Principles

Graphic design significantly impacts the effectiveness of a CLD.

●​ Curved Lines: Use curved lines for causal links to help the reader visualize the feedback paths.
●​ Circular Paths: Organize important loops into circular or oval paths.
●​ Build in Stages: Rather than presenting one large, complex diagram, build the model in stages using
smaller diagrams that correspond to individual parts of the story.
●​ Avoid Chart Junk: Do not put unnecessary symbols or shapes around variables unless you are explicitly
representing a stock and flow structure.
●​ Iteration: Expect to redraw the diagram many times as your understanding of the system's variables and
interdependencies improves.

8.0 Glossary of Key Terms

This section provides definitions for the key technical terms used throughout this guide.

●​ Activity Cycle Diagram (ACD): A conceptual modeling tool in Discrete Event Simulation that maps the life
history of each entity class as a sequence of active and dead states, showing how entities interact.
●​ Balancing (Negative) Feedback Loop: A feedback structure that counteracts change and seeks a goal or
equilibrium, acting to stabilize a system.
●​ Bounded Rationality: The principle that the human mind has limited capacity to process information,
making it impossible to accurately infer the behavior of a complex system even when its full structure is
known.
●​ Causal Loop Diagram (CLD): A diagram used in System Dynamics to visualize the feedback structures of
a system, showing the causal links between variables and the polarity of the feedback loops.
●​ Deterministic System: A system whose behavior is completely known and predictable, with no random
elements.
●​ Discrete Event Simulation (DES): A simulation methodology that models a system where the state
changes at discrete points in time, typically used for systems involving queues and resources.
●​ Dynamic Complexity: The counterintuitive behavior that arises from the interactions among a system's
elements over time, especially when short-term and long-term consequences of actions differ.
●​ Entities: The individual elements in a DES model whose behavior is explicitly tracked as they move
through the system (e.g., passengers, products).
●​ Flow: In System Dynamics, a rate that changes a stock over time. A flow would become nil if time were
frozen.
●​ Policy Resistance: The tendency for well-intentioned interventions or decisions to yield counterintuitive or
negative results due to the complexity of the system.
●​ Reinforcing (Positive) Feedback Loop: A feedback structure that amplifies any change in its variables,
leading to exponential growth or decline.
●​ Simulation: The process of experimenting with a simplified imitation of a real-world system on a computer
as it progresses over time, for the purpose of understanding or improving its performance.
●​ Stock: In System Dynamics, a variable representing an accumulation or level at a point in time. A stock
would remain if time were frozen.
●​ Stochastic System: A system whose behavior is not completely predictable and involves random
variables, which are often described by probability distributions.
●​ System Dynamics (SD): A simulation methodology focused on understanding the dynamic behavior of
complex systems over time, with an emphasis on feedback loops, stocks, and flows.
●​ Three-Phase Approach: A method for executing a DES model that cycles through three phases:
advancing the clock (A Phase), executing scheduled events (B Phase), and executing conditional events
(C Phase).
●​ Validation: The process of ensuring that the simulation model is a sufficiently accurate representation of
the real-world system for its intended purpose ("building the right model").
●​ Verification: The process of ensuring that the computer model is an accurate implementation of the
conceptual model or formal design ("building the model right").