^The Barriers to Systems Thinking

Richard Beasley,
Global Chief of Systems Engineering,
Associate Fellow Systems Engineering
Rolls-Royce plc
Richard.beasley@rolls-royce.com
Copyright 2012 Rolls-Royce plc. Published and used by INCOSE with permission.

Abstract : System Thinking is a pre-requisite to effective Systems Engineering, and is one of

the hardest elements to recognize, develop and use. This paper argues that this is because
Systems Thinking is hard, and actually unnatural. There are barriers in the way the human
brain is pre-disposed to act, and the current state of engineering can also be a barrier to
Systems Thinking. To deliver the value promised by Systems Engineering recognizing these
difficulties, and overcoming them is essential.
Based on experience implementing effective and explicit Systems Engineering into RollsRoyce plc the author suggests some ideas on overcoming the barriers. Systems Engineerings
greatest value comes from effective pre-work in the early stages of projects. But the most
effective place to learn the approach and quickly see the benefits is solving the problems (rework) created by its initial absence, as the scope is reduced. Systems Thinking needs to be
integrated into the processes, the knowledge and the roles within the organisation. Effective
leadership setting the expectation that Systems Thinking will be done is equally vital.

Introduction
This paper starts with a brief explanation of the value of Systems Thinking, and a rationale
for why this aspect of Systems Engineering needs more attention than other aspects
possibly because of the apparent difficulty in doing it.
A deeper analysis of the reasons for the difficulty in doing Systems Thinking is presented in
two sections. Firstly there is the nature of the human mind, in which Systems Thinking is not,
usually, natural. Secondly the current state of Engineering, Programme Management and
Systems Engineering itself create barriers.
Having introduced reasons why doing Systems Thinking is hard and difficult, the paper
introduces suggestions on how to improve its deployment, and create better understanding of
its place within the broader Engineering activities.

The Value of Systems Thinking

This paper assumes Systems Engineering is a worthwhile endeavour, and that Systems
Thinking is a key enabler. Honour (2011) has shown project success is strongly correlated by
the right amount of tailored and effective Systems Engineering. So the challenge is to do
effective Systems Engineering this paper focuses on Systems Thinking as one contributor
to effectiveness.
The INCOSE Systems Engineering competency framework (INCOSE 2010) defines Systems
Thinking as a way of dealing with increasing complexity. The fundamental concepts of
systems thinking involves understanding how actions and decisions in one area affect
another, and that the optimisation of a system within its environment does not necessarily
come from optimising the individual system components. A further description of its
importance can be found in the UK INCOSE Z guide (Godfrey and Woodcock, 2010).

Foundation work on Systems Thinking, especially Systems Dynamics can be traced back to a
number of sources e.g. the work of von Bertalanffy, Forrester and Sterman - for example
see (Bertalanffy, 1969) on System Theory, (Forrester, 1961) and (Sterman, 2011) for Systems
Dynamics.
In the training given in Rolls-Royce (Burge, 2011) it is argued that the benefit of Systems
Engineering (especially as pre-work) is to prevent expensive rework and undesirable
(sometime catastrophic) consequences from unwanted emergence. The causes of rework are:
a) Over-sensitivity to variation which can be addressed by design for 6 sigma
techniques, looking at causes (and then control) of variation that affect critical to
quality (CTQ) attributes. CTQs have to be elicited using Systems Engineering (and
Systems Thinking particularly to get functionality).
b) Sub-optimization either focusing on a single attribute to the detriment of others, or
(more commonly) concentrating on designing parts rather than systems.
c) Failure to recognise dynamic effects making mistaken assumptions of static
properties of system behavior.
Beasley and Partridge (2011) argued that there can be a lack of focus on Systems Thinking.
Figure 1, from that paper, shows the need for a balance between being systematic,
application of correct process as propounded in the INCOSE SE handbook (Hamelin,
Walden, Krueger, 2010), and being systemic applying Systems Thinking.
No invention / rework
Good
process
Being
Systematic

A very good chance

No real thinking, Systems

The right understanding of
process reduced to by the
problem skilled and appropriate
numbers, ineffective Systems use of process and method
Engineering
No chance

Poor
Process

No control

Cannot handle complexity and Skilled individuals uninterested

unlikely to do well!
in process so get no control,
critical things not done,
reinvention and some maverick
Poor Systems Skills

Good Systems Skills

Being Systemic
Figure 1 balance of systematic / systemic (from Beasley and Partridge, 2011)
It is the authors strong belief (which will be expanded below) that, of these two, Systems
Thinking is the hardest. That is not to underestimate the importance of developing and
implementing the right lifecycle view and being systematic. However, the focus of this paper
will be on the difficulty of being systemic, and so how to move to the right on Figure 1.

The human barriers to Systems Thinking

In this section a review of the nature of the human mind will be carried out, exploring why
doing Systems Thinking can be such a challenge.

Many of the ideas in this section are a synthesis from three specific books - The Black Swan
(Tesser, 2007), the Logic of Failure (Dorner, 1996), and Irrationality (Sutherland, 1992).
Direct quotes are specifically referenced, but take these as general references for this section.

Thinking not as natural as we think

The human mind is not pre-disposed to think and abstract information. There are many
descriptions of the different levels of function in the human mind. In The Ghost in the
Machine (Koestler,1967) there is a description of the three levels of the human brain
autonomous functions (e.g. breathing), the limbic / reactive function (the horses kick)
where there is an instinctive reaction, and finally the higher cognitive or reasoning function.
[As an aside, the reason for choosing the Koestler reference for this, where there are many
more recent / accessible texts is because it is also in this book that Koestler introduces the
concept of a holon, which is vital to systems thinking. A holon faces two ways a
component in a higher level system, and itself a complex system made up of a number of
interacting parts]. It is the limbic system that has enabled us, as a race, to evolve to a level
where we create complexity that requires more cognitive function. There is more survival
value in recognising a lion and running (limbic) than contemplating the purpose, nature and
danger of lions, and considering the possibility of taming lions (cognitive).
In the modern world this can have serious implications. The Black Swan (Tesser, 2007)
argues that we do not learn that we do not learn and the route cause lies in the structure of
our minds. We do not learn rules, just facts. This leads to an inability to automatically
transfer knowledge and sophisticated learning from one situation to another or from theory to
practice. It can be argued that we do much less thinking than we think we do. Worse, we
tend to scorn the abstract. Our minds cannot think and introspect (well enough). Thinking
can be seen as time consuming and a waste of energy. Our ancestors spend 100 million years
successfully evolving as non-thinking mammals, and that legacy is still with us.

The tendency to jump to conclusion and the availability error

The human mind wants positive progress. In engineering this is seen in the tendency to
prioritize developing solutions, and working the first feasible idea - an illusion of progress.
We must recognise that this is natural human behaviour, and take explicit steps to avoid it.
(Dorner, 1996) argues that under time pressure the type of psychology found is a tendency...
to apply overdoses of established measures. We find an inability to think in terms of
nonlinear networks of causation.... effectively mistakes of cognition so we dont
understand the dynamics of systems. As an example of the importance, it is suggested that
this was a significant factor in the Chernobyl nuclear reactor disaster.
This tendency to jump to conclusions is amplified by the availability error. We place far
too much emphasis on the data we have, rather than the data we dont know about so we
derive conclusions and verification of our conclusions from too little data. The scientific
method is focused on trying to disprove assertions (as no theory can ever be fully proven
the best is no evidence of problem) but we are not good at looking to disprove. A
relatively simple example of this is (Sutherland, 1992) is summarized below.
In an experiment cards are produced with letters on one side, and numbers on the other. The
assertion is made that any card with the letter A on one side will have a 3 on the other.
Individuals are given four cards, one way up, and invited to prioritize which cards to turn
over to test the assertion. The cards given show A, D, 3 and 7. The selections made were:
Card A clearly this is a sensible choice and was the most popular if there is no 3

on the back the theory is disproved, end of discussion.

Card D has no relevance, and sensibly this was least chosen.
Card 3 many picked this as a card to examine but it is immaterial. The theory
talks about a letter A having a 3 on the back so if any other letter has a 3 on the back
actually says nothing about the rule.
Card 7 few picked this card, but apart from A, this is the most likely to be useful
because if it is turned over and a letter A is found the rule can be shown to be false.
There are two issues here one the general attempt to show the theory is true, rather than
disprove it. The second is more subtle, and dangerous. The rule talks about the number 3
therefore that number is available and so there is a tendency to pick that card because it is
mentioned in the rule. Moreover, there is the tendency for us to make assumptions. To what
extent is the choice of the card with 3 driven by the erroneous assumption that whilst the rule
says cards with A have a 3 on the back there is the unstated rule that the inverse is also true?
A further illustration is the well known tendency to blindly miss grammatical or
typographical errors in text. The human mind can take very effective shortcuts because we
can see what is meant and our mind can run ahead. It is natural for the human mind to
leap to a feasible solution this is rapid progress, and the first to a solution should have the
advantage. Compounding this issue once we have an idea we are bad at looking for reasons
why it is wrong, and will seize / amplify any evidence suggesting our initial idea is correct.
In a broader sense we interpret what we see by what our conditioning expects us to see. This
can blind us to what message is actually trying to be communicated which is why such care
has to be taken with text based requirements.

Barriers to looking further for information

Not only do we have difficulties recognising the need for further information, but we also are
conditioned by our experience and see what our conditioning expects us to see.
It can be argued that what you do not know is far more relevant that what you do know
(consider the Rumsfeld known-knowns and unknown-unknowns description). What we
do not know has the greatest potential to really hurt. Any study of history can always show,
in retrospect, the important facts that at the time where not recognised as important. This
means that hindsight is perfect and we could have avoided issues if only wed had time to
stop and think. Typically we focus on avoiding the problems we encountered on previous
projects, but this condemns us to not spotting any new issues. The mistake is that we focus
on known problems, and not on problems that dont exist yet. It is less not knowing, more
not wanting to know due to thinking that focuses on active (available) problems.
Tesser (2007, p53) states that knowledge, even when it is exact, does not lead to appropriate
action because we forget what we know and how to process it properly. A little extra
information about a problem will simply increase the level of confusion. Increasing
confusion can be seen as a retrograde step, and we naturally try to avoid adding uncertainty,
as that makes us more uncomfortable. Popper (1972) argued that understanding how to act
under the condition of incomplete information is the highest and most urgent human pursuit.

Difficulties with Dynamics

Most systems are dynamic again see (Forrester, 1961) and (Sterman, 2001). In the Logic of
Failure (Dorner, 1996) it is suggested that the human mind is not able to cope with dynamic
situations very well. There is a tendency not to be able to recognize the momentum in a

system, and the inability to recognise the delays natural in a system. This is covered in detail
in p128-137, where Dorner explains an experiment where participants are asked to change a
regulator (with numbers that do not correspond to thermometer readings) to maintain a
constant temperature in a chilled store room. The temperature in the storeroom is not
immediately responsive to the climate control system there is a delay that can lead to
oscillations in the temperature. The proper course would be to try and work out the time
constant. Instead, many participants go to if temperature too low give maximum heating, if
too high maximum cooling, and get wild oscillations. Some hypothesised that the failure to
control the temperature was down to some malevolent deception by the experiment director.
This difficulty with dynamic behaviours is an example of a tendency to over-generalize from
experience, and to not be able to process all information available.

Organisation / Engineering barriers

This section describe some of the more specific issues relating to work and behaviours in
organisations, planning and engineering complex solutions to difficult challenges.

Changing is hard
It is well recognised that making change in organisations is hard. The Kotter change model
(Kotter, 2002) is part of the structure the author is applying to the plan to implement Systems
Engineering into Rolls-Royce. A couple of difficulties are described below:
a) Creating a sense of urgency. This is difficult when the company is successful, and
actually being held up as a exemplar of how business in the UK should develop.
b) There is a danger that the change can be seen as a revolution (create the urgency, and
so need change) which can throw out the baby with the bath water. Systems Thinking
is an addition to standard engineering, not a replacement so we need to avoid
appearing to want to remove all that is good currently (and there is plenty without it
Rolls-Royce would not be the company it currently is).
So when we set out to change we must remember the important things we wish to retain so
beware of turning the sense of urgency into a (wrong) sense of crisis.

The drive for progress and the nature of Programme Management

In any project, especially where there is an urgent timescale or an impatient customer, there is
a natural desire for visible progress. The understanding yielded by systems thinking, whilst a
significant enabler, is not visible as progress. This is compounded by what appears to be
the most common planning view the Gantt chart which presents a linear plan and any
iteration looks like rework (and so is seen as waste). However, Figure 2 (Conklin, 2006)
shows that a designer fluctuates between solution and problem much more rapidly and
iteratively than the standard linear model suggests.

Figure 2 Variation between problem and solution thinking (from Conklin,.2006)

Too linear an approach to the plan (the tyranny of the Gantt chart) can prevent Systems
Thinking. At the very least it would be good to have a milestone indicating the achievement
of an initial level of understanding of the problem, and subsequent milestones showing
improvements to that understanding. The need for iteration is well known to be at the very
foundations of planning e.g. the well known Plan, Do, Check, Act (or Deming) cycle.
Typically the program management approach to risk is not appropriate. A recent
conversation on integration of Programme Management, Risk Management and
Requirements Management processes in Rolls-Royce illustrates the issue. Risk Management
is a through-life process, but the question was raised of how to do risk assessment before a
solution (preliminary concept) is available. Common practice is to risk assess the concept to
see if it can be delivered, ignoring that a significant level of risk understanding can be derived
from the maturity of the requirements understanding. Absence of, or uncertainty in,
requirements is clearly a risk (because if you dont know what is wanted then successful
delivery is down to luck) and comparison with requirements from previous projects can give
significant input to understanding of the level of risk on a project. Previous work (Pickard et
al, 2010) on the cause of rework in Rolls-Royce has recognised risk assessment focusing too
much on cost and schedule risks in development projects, and not on technical risk.
There is a tendency to make decisions whenever it becomes possible rather than when the
decision is needed. Patrick Godfrey of Bristol University promotes the principle of last
responsible moment (Blockley and Godfrey, 2000, chapter 9, and Godfrey, 2007 slides 41
and 42). If we make a decision too soon we may be making it on incomplete information, or
leaving ourselves as a hostage to fortune as something may change causing the decision to be
reversed and hence rework / waste is created. We need to withhold judgement for longer
than we think we need to until it is really needed.
Obviously the drive for visible progress is important. Figure 1 emphasizes the need for
balance between systemic and systematic and purely systemic is not enough. Figure 1
suggests that purely good systemic is not given. A lack of interest in process can lead to
never moving forward Shakespeare captured this well in the famous to be or not to be
speech (Hamlet, Act III, scene 1)
... thus the native hue of resolution
Is sicklied oer with the pale cast of thought,
And enterprises of great pitch and moment

With this regard their currents turn awry,

And lost the name of action
To paraphrase at some point (the last responsible moment?) we have to just get on with it.

Nature of Engineering as a discipline

A stereo-typical view of Engineering is that there is significant pride in the practicality and
down to earth nature of the discipline. This means that engineers make significant
advances well in advance of theoretical understanding. George Stephensons work on the
application of steam blast to combustion in early locomotives in 1814 is an example of this.
The improvement in the intensity of combustion was cited as a principle reason for success of
the Rocket in 1829, and without which the impact of steam locomotion would not have
happened (Smiles, 1874). The principles of design for combustion aerodynamic performance
were not in place until the first comprehensive examination of steam-raising plant
performance carried out by Purdue University in 1908. On the negative side the author had
a long conversation with a senior engineer in Rolls-Royce describing Systems Engineering.
Finally the reaction came Ive got it you want me to pause and think followed by the
deflating if Id wanted to think Id have done Philosophy not Engineering at university!
The value proposition for Systems Engineering is the need for more prevention rather than
treatment of design issues, but acts of prevention are seldom rewarded. This can be
(partially) explained by considering that there is no way of seeing the chaos prevented by a
simple, rational decision made at the right time. It can be unfairly suggested that Engineers
like a fire fight. In an abductive study of Systems Engineering in Rolls-Royce (Dunford et
al, tbd) it is hypothesized that it is not that fire-fighting is a preference, but a natural reaction
to the pressurised project timescales and impatient customers. Effective fire fighting is an
important survival skill. Regardless of root cause, anyone who resolves a crisis (puts out a
fire) is naturally and correctly due for reward. Unfortunately, we tend not to see heroes in
those who focus on process, prevention etc rather than those who produce results.
In the introduction to Systems Engineering and Analysis (Blanchard and Fabrycky, 2005) it is
asserted that Systems Engineering is just good engineering, with special areas of emphasis.
This is entirely true (but not the best way to convert an established engineer - implying they
are not good). It means that Systems Engineering needs to be a core skill in all Engineering
rather than a separate group. So it is not a matter of training a small group of Systems
Thinkers. As a specialist Systems Thinker the author has to regularly point out that he cannot
do the thinking or the understanding for the engineers who need the situation understanding.
Pushing against the drive for linear progress discussed above it has to be recognised that
the design process is a wicked problem in many cases it is the action of creating aspects
of the solution that exposes the real nature of the requirements (see for example Conklin,
2006). This goes against the programme management drive, may be difficult when the
iteration is across an organisational or contractual barrier; and there is difficulty in getting
engineers to accept that the future is uncertain.
We need to recognise that the design process is actually one of developing maturity of
understanding throughout the lifecycle of the project. Solution, evidence and requirements
must mature together.

Nature of Systems Engineering

As a discipline Systems Engineering perhaps does not help itself. Discussion of Systems
Engineering roles (Sheard, 1999) emphasizes glue or interface roles. There is a danger

that Systems Engineering is seen to be trying to become a new breed of specialist. Instead,
Systems Engineering is a core skill needed in significant levels in many Engineering roles.
Therefore many Engineering roles (for example Chief Design Engineer) could legitimately be
described as Systems Engineering roles.
The language and techniques of Systems Engineering can be seen as a new breed of magic.
Some of the language / concepts can be seen as alien to an outsider. The author has heard
many criticisms of the difficult interpretation of the terms within Rolls-Royce, to the extent
of once being accused of being wilfully obscure with language.
Systems Thinking is a hard concept to pick up. In Rolls-Royce over 800 individuals have
attended an intensive one week Systems Engineering (with significant focus on Systems
Thinking techniques) training. Examination of what else needs to done to successfully
embed the approach (Dunford et al, tbd) has identified that the training, naturally, does not
give full confidence in the techniques. An analysis of survey results among engineers who
had been on the 5 day training (latest version Burge, 2011) at the Bristol site of Rolls-Royce
(in the Defence division) asked how well the training had prepared them for using the
approach in their work. The scale was 1 = not at all and 10 = completely. In experienced
(i.e had used Systems Engineering considerably) 30% chose 5 and 40% chose 7 for
everyone else the rating of 5 to 8 garnered between 15% and 25% of the vote with no other
options getting more than 10% (Dunford et al, 2012). Thus on the job use of what is
trained increases the appreciation of what is taught. The training (for sensible educational
reasons) is based on relatively simple problems, and an individual is not properly equipped to
use the techniques with confidence in the real world. This is reflected in a negative view of
the perceived time to do Systems Thinking. If done badly (due to inexperience) the
experience can have a negative impact on both this perceived amount of effort, and the view
of the value of the approach and methodology reducing any willingness to persevere and
devote time to learn / understand better (Dunford et al, tbd). Ways around this are discussed
in more detail below in some ideas on how to develop Systems Thinking.

Complex and large organisations

Large organizations organize into appropriate business groups. Just as breaking a physical
system into modules for ease of management, breaking up an organisation into sub-units
creates interface issues. Rolls-Royce is divided into Customer Facing Business Units
(CFBUs) which provide products to customers for a range of domains, Supply Chain Units
(which deliver integrated modules made up of integrated commodity components) and core
functions. Simply considering the top level systems Rolls-Royce (not the supply chain) the
author has worked with 4 different CFBUs on 7 sites (3 in the UK), and various core
functions, including test facilities and engineering improvements. In each case the domain
issues are different, and so the specific aspects of the Systems Thinking that are a priority are
different.
This introduces a problem of consistency, standardisation and sharing of Systems Thinking,
especially as the implementation of Systems Engineering can be thought of as a journey, with
a few wrong turns on the way. A common misinterpretation is that standardisation means
rigid inflexibility. There must be appropriate flexibility, but based on a common, shared
baseline as in Toyota (Morgan and Liker, 2006). Too often the excuse for a different
approach is geographical rather than the real variation in domain issues. Coordinating
development of a difficult skill across geographic and organizational divisions is a significant
challenge.

Some ideas on how to develop Systems Thinking

The sections above have described Systems Thinking as probably unnatural, difficult to
explain, and needing to be integrated into a large population. Applying the Systems
Approach is a key enabler, especially on complex problems or where the consequences of
mistakes (and hence the need to rework) are critical and / or expensive. If Systems Thinking
is so difficult perhaps we should abandon the attempt? It is the authors contention that the
prize of effective Systems Thinking is too great and so a planned and careful approach to its
introduction must be carried out.

Make it a core skill and process not just a SE department

In Rolls-Royce the authors task has been defined to make Systems Engineering the way
Rolls-Royce does engineering. This has led to the identification of the need for specialists to
facilitate Systems Thinking and to lead a focus on requirements understanding deployed in
a role called Project Systems Engineer. More importantly the task includes raising the
levels of Systems Engineering (and especially Systems Thinking) in a wide range of the
existing engineering roles. A significant problem to overcome is the barrier that creating a
role like a Project Systems Engineer makes. There has been a tendency to assume that these
roles are a SE department, and the rest of engineering carries on as normal. Even when a
group of System Designers have taken on board doing Systems Thinking the balance between
standard use of techniques (consistency) and tailoring the techniques to the situation, and then
sharing the learning / advances in Systems Practice in the community gets more difficult
but this is a good problem to have as it results from positive progress.
Getting systems thinking embedded in the process is vital. Work on requirements capture
and management is in place (Glazier, 2011), and further work is on-going making the whole
Rolls-Royce process set (so beyond engineering to programme planning and risk
management) reflect the need for Systems Thinking. This reinforces the point in Figure 1
regarding the need to balance systemic and systematic. We have been using Systems
Thinking to determine the purpose of the sets of processes and each individual process.
The need for experiential learning, identifying specific individual characteristics and
establishing the right supporting environment, has been established (Davidz and Nightingale,
2008). Detailed investigation into the application of Systems Engineering in one RollsRoyce business unit (Dunford et al, tbd), using grounded systems modeling has found that
Systems Practice is valued as a way of enabling quality in design but engineers find it
challenging to adopt because of: (1) their lack of experience with Systems Practice, (2)
logistical issues with its application and (3) with stakeholders appreciating its value.

The best place to learn Systems Thinking

To date over 800 individuals in Rolls-Royce have undertaken a five day Systems Engineering
training course with strong focus on Systems Thinking. This training uses relatively simple
problems to provide familiarity with the techniques (common systems examined are toasters,
Autonomous lawn mowers etc.). Obviously this does not equip the individuals with the
ability to use the techniques solo in a team.
Figure 3 describes different scenarios where systems engineering could be applied, to both
develop individual experience and deliver value. Short, simple cases are good for
introduction to the methodology, but insufficient for developing real confidence. Maximum
benefit from Systems Thinking practice comes by applying it at the beginning (pre-work) of a
large, complex system (e.g. a new large civil gas turbine) and continuing throughout the

project. However, that is not the best place to learn Systems Thinking. It is proposed that
using Systems Thinking to solve / understand emergent problems on projects in production /
service is a good place to quickly see the benefit as the scope of these issues can be more
bounded.
Resolving in-service
problems
Real world

Project
Type

Quicker results and faster

appreciation of power of
approach
Simple

Pedagogical Introduction / learning tools

and concept, but low domain
applicability
Short, Simple

Major projects
The highest value from SE, but
not the place to learn

Large case study worked

examples
Insufficient benefit in return for
the case
Long, complex

Project Duration and Complexity

Figure 3 Different types of project with route for developing confidence in
Systems Practice
The red arrow on figure 3 illustrates a path to learning. An introduction to Systems Thinking
should be on simple examples that allow understanding and appreciation of the method. This
does not leave the individual yet able to apply on the complex, real world. There needs to be
leadership support to encourage and pull forward use of the approach but individuals can
learn fastest on small re-work / modification issues, and develop proficiency and confidence
to apply where the impact is greatest. The small pieces of work can be used to build up a
detailed bank of knowledge of the context, purpose, functions and interfaces of parts of the
system which can be integrated together.
Evidence of this came from feedback from one exercise the author carried out this year. A
problem arose on an in-service engine, and to provide clarity for deciding on a solution
approach some Systems Thinking was requested. Context diagram and functional analysis of
the original design intent of the failing sub-system was carried out, followed by functional
failure analysis. This provided both abstract focus to see the whole picture of what was going
on, and a functional view to guide the creation and verification of a solution. The Systems
Thinking exercise was conducted in two one day workshops. One team member, considering
his next career step consulted the author - Thinking back, the experience that stands out the
most was the systems engineering approach that you introduced to our team to help focus our
design efforts on the right solution concepts. My managers and I are working to plan out the
next steps of my career, and I have expressed to them my interest in Systems Engineering.
In the analysis of survey results of Engineers on the Bristol site of Rolls-Royce responses
between people were self assessed as experienced or not experienced were analyzed for
significant differences. It was found that the experienced group: (1) found Systems
Engineering more relevant to their work and a follow-up question suggests when relevant
they almost always used it and (2) had used more techniques and found them more useful.
These results do not refute the hypothesis that more on the job use is crucial to becoming an

experienced practioner (Dunford et al, 2012).

Standardise and share

During implementation of Systems Engineering there are two issues that have to be addressed
around sharing and standardisation unnecessary variation in approach taken in different
areas, and sharing learning on the nature of the systems that are produced. But there are
dangers in standardization. Standardization must not be taken to mean a lack of flexibility, or
a one size fits all approach. Unless there is a common baseline then sharing on the journey
will be made unnecessarily hard as there will be a barrier to communication as different
terminology, roles, processes, techniques and even interpretations get in the way.
Another danger in sharing can be the temptation to let others do your thinking for you.
Picking up the output of someone elses systems thinking may prevent the necessary
engagement and understanding. But it is much better to start from someones model and
review / improve than unknowingly duplicate the work, and not even compare. Therefore
considerable effort is being put into sharing across Rolls-Royce (which is not without
challenges), and the 4 box model in Figure 1 can be extended to a third axis and make the 8
box cube shown in Figure 4 below:

No invention / rework

A very good chance

Low chance

No control

Figure 4 Fully balanced Systems Engineering - Systemic, Systematic and shared

Behaviours
The INCOSE competency framework (INCOSE 2010) limits itself to technical competencies
it lacks a consideration of behavior. There is some extant work, for example dstl research
that highlighted the need for emotional intelligence (Maddocks and Rogers, 2006), and a
NASA study (Williams and Derro, 2008) also called for focus on the human dynamics. The
INCOSE Competency Working Group has an intention to focus on the softer skills needed.
Based on the analysis contained above work is needed to ensure that the difficulties in doing

Systems Thinking are addressed. But more work is needed focusing on how to develop
Systems Thinking in SE specialists, in all engineering roles, and within an organisation.
The need for effective leadership buy-in and pull for Systems Thinking cannot be
underestimated. Where there has been real progress in Rolls-Royce this has been enabled by
senior engagement and commitment to communicating that Systems Thinking is key.
Getting the right understanding and then the setting of expectations for Systems Thinking by
the technical leadership is essential. Engineering Director and Chief Engineers, having been
given appreciation of the approach, are now increasingly calling for the use of Systems
Engineering giving momentum to the implementation journey.

Conclusions
Doing Systems Thinking is key to successful Systems Engineering and therefore project
success. Doing Systems Thinking is hard and implementing it into an established (and by
many standards successful) engineering organization is harder still. This paper has reviewed
the root causes behind these difficulties, and suggested some approaches to overcome.
The reasons for the difficulty in doing Systems Thinking are profound and should not be
underestimated. There are two classes of difficulty. The first is the nature of the human
mind which is much more reactive and unwilling to think than we would like. We are preconditioned to jump to conclusions and make inappropriate assumptions. Hence the truth in
the saying common sense is not common. The second reason is the nature of organizations
and the practical empiricism of an engineer. There is a strong need to see progress, and
iterations seem like rework. Organizations like to make neat partitions and so attempting to
introduce an idea that needs to be absorbed across the whole population has significant
challenges.
The first step to implementing Systems Thinking in an organisation is to recognise that it is a
journey, and most likely a long and hard one. Steps have to taken to reduce negative
pressures on effective Systems Practice (purposeful application of Systems Thinking).
Particular enablers identified include:

Ensuring a balance between process (being systematic) which includes getting the
process to recognise the need for Systems Thinking - and for the application of
Systems Thinking (being systemic).

Ensure sharing and standardization of Systems Thinking approaches and outcomes

across the organization so as to build on the learning of others, and to try to avoid
duplication of the learning pains. This must not lead to over-constraint and lack of
flexibility in the emphasis given to parts of Systems Thinking dependent on particular
domains.

An appropriate route to teaching, learning and embedding Systems Practice is needed

move from simple teaching cases to real, complex but short duration problems, such
as found when modifying or fixing an existing system.

Since a number of the problems in System Thinking are based in personal and
organisational behaviour, then work recognising and developing the right behaviors in
both is still needed.

On the implementation journey, the right leadership to set the expectation that
Systems Thinking WILL be done (because it IS of value) is essential to getting the
momentum to get over the learning and implementation hurdles.

Finally just because doing Systems Thinking and implementing it into an organization is

hard is no reason not to try. The benefits are there to be seized. It is important to manage
expectations, and realise that successful implementation (and so making Systems Engineering
the way engineering is done in an organisation) will be a long journey.

Acknowledgements
I would like to recognise all my Systems Engineering and System Design colleagues in RollsRoyce who have embarked on this difficult journey in particular Darren York, Charlotte
Dunford, Andy Pickard, and recently John Weaver who have helped me develop my ideas,
and challenged me as appropriate. Outside Rolls-Royce, I am heavily indebted to a number
of contacts made through INCOSE. I would especially like to recognise the generous help I
have received from Stuart Burge (Burges, Hughes and Walsh), Hillary Sillitto (Thales), and
Professor Patrick Godfrey (Bristol University).

References
Beasley, R, and Partridge, R. 2011 The Three Ts of Systems Engineering Trading,
Tailoring and Thinking, INCOSE international Symposium, Denver 2011
Bertalanffy, Ludwig von, 1969, General System Theory, George Braziller, New York
Blanchard, B. and Fabrycky,W. 2005 Systems Engineering and Analysis 4th edition, PrenticeHall International
Blockley, D. and Godfrey, P. 2000, Doing it Differently, Systems For Rethinking
Construction, Thomas Telford
Burge, Stuart, 2011, Systems Engineering Short Course, course delivered at Rolls-Royce plc.
Conklin .2006. Wicked Problems And Social Complexity, Cognexus Institute accessed at
www.cognexus.com
Davidz, H.L. & Nightingale, D.J., 2008. Enabling systems thinking to accelerate the
development of senior systems engineers. Systems Engineering, 11(1), pp.1-14. Available at:
http://dx.doi.org/10.1002/sys.20081 .
Dorner, Dietrich; 1996 The Logic of Failure Basic books, Perseus Publishing (Originally
published in Germany, in 1989 under the title Die Logik des Misslingens by Rowholt Verlag
GmbH)
Dunford, Charlotte, Yearworth, Mike, York, Darren M, Godfrey, Patrick. tbd. A view of
systems practices enabling Quality in Design. Submitted for publication to Systems
Engineering Journal
Dunford, C.N., Yearworth, M., York, D.M., Godfrey, P., Parsley, A., 2012 Using Systems
Practice to Enable Quality in Design 2012 IEEE International Systems Conference
proceedings, 19-22 March 2012 Vancouver Piscataway, NJ.
Forrester, Jay 1961 Industrial Dynamics Pegasus Communications, Waltham, MA

Glazier, Lee, 2011 Rolls-Royce Requirements process, presented at INCOSE ASEC

November 2011
Godfrey, P 2007 Plucking failure from the jaws of success, presentation given to INCOSE
Bristol Local Group, available online at
http://www.incoseonline.org.uk/Documents/Bristol/BLG070926_Systems_thinking_about_Mega_project
s.pdf
Godfrey, Patrick and Woodcock, Hazel. 2010. Z-7 Systems Thinking UK INCOSE
Chapter, Z-guide series, available at:
http://www.incoseonline.org.uk/Documents/zGuides/Z7_Systems_Thinking_WEB.pdf
Hamelin, R.D., Walden, D.D., Krueger, M.E, 2010.
INCOSE Systems Engineering
Handbook V3.2, Improving the process for SE practioners, Presented at the INCOSE
International Symposium in Chicago, USA
Honour, Eric 2011, Sizing Systems Engineering Activities to Optimize Return On Investment,
Presented at the INCOSE international Symposium in Denver, USA
INCOSE , 2010 Systems Engineering competencies framework (including annex A Guide
to competency evaluation) INCOSE TP-2010-003 INCOSE, San Diego, Ca, USA
Koestler, Arthur, 1967, The Ghost in the Machine, Hutchinson & co
Kotter , J. 2002 The Heart of Change Harvard Business Review Press, Boston, Ma
Maddocks, J and Rogers, R. (JCA occupation Psychologists), 2006 Systems Thinking Data
Analysis and results report for DSTL (report given to author in follow up discussion with B
Busby of DSTL after DSTL Systems skills symposium, April 2008, attended by author)
Morgan J.M., and Liker, J.K. 2006 The Toyota Product Development System Productivity
Press
Pickard, A., Nolan, A., and Beasley, R. 2010 Certainty, Risk and Gambling in the
Development of Complex Systems. Presented at the 20th INCOSE International Symposium in
Chicago
Popper, K. 1972 Objective Reasoning Clarendon press, Oxford
Sheard, Sarah. 1999 12 Systems Engineering roles Presented at the 6th INCOSE International
Symposium in Boston
Smiles, Samuel, 1874 The lives of George and Robert Stephenson
Sterman, John D., 2001 System Dynamics Modeling: tools for learning in a complex world,
California Management Review Vol 43 no 4, Summer 2001
Sutherland, Stuart, 1992. Irrationality, Constable and company

Taleb, Nassim, 2007 The Black Swan Random House Publishing

Williams, C and Derro, M-E, 2008 NASA Systems Engineering Behavior Study on line at
http://www.nasa.gov/pdf/291039main_NASA_SE_Behavior_Study_Final_11122008.pdf

Biography
Richard Beasley graduated with a Physics Degree from Bristol University in 1986, and then
joined Rolls-Royce as an engineer. He spent 14 years in Installation Aerodynamics for
Military Engines, during which time he gained an MSC in Gas Turbine Engineering from
Cranfield University. He then worked on Life Cycle Cost, Reliability and aspects of
designing products for Aftermarket / Service. He is now the Global Chief of Systems
Engineering, which includes being corporate skill owner for Systems Engineering in RollsRoyce, and in 2011 was made a Rolls-Royce Associate Fellow in Systems Engineering. He
is a member of the UK INCOSE chapter, chairs the Bristol Local Group in the UK chapter,
and attends the UKAB as the Rolls-Royce representative. He is a Chartered Engineer, Fellow
of the Royal Aeronautical Society, and a Visiting Fellow to the Systems Centre at Bristol
University.