^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 Rolls-Royce plc the author suggests some ideas on overcoming the barriers. Systems Engineering’s 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 (re-work) 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.

Good process

No invention / rework

No real thinking, Systems process reduced to “by the numbers”, ineffective Systems Engineering

A very good chance

The right understanding of problem – skilled and appropriate use of process and method

Being Systematic

Poor Process

No chance

Cannot handle complexity and unlikely to do well!

No control

Skilled individuals “uninterested” 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 author’s 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 horse’s 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 don’t 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 don’t 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 we’d 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 don’t 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 don’t 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 o’er 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 Stephenson’s 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 “I’ve got it – you want me to pause and think” – followed by the deflating “if I’d wanted to think I’d 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 author’s 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 author’s 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 Rolls-Royce 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.

Real world

Resolving in-service problems

Quicker results and faster appreciation of power of approach

Major projects

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

Project Type

Pedagogical

Simple

Introduction / learning tools and concept, but low domain applicability

Large case study worked examples

Insufficient benefit in return for the case

Short, Simple 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 else’s systems thinking may prevent the necessary engagement and understanding. But it is much better to start from someone’s 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:

 

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

No  invention  /  rework  

No  control  Low  chance  

A  very  good  chance    

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 pre-conditioned 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 Rolls-Royce 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 T’s 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, Prentice-Hall 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_projects.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 Rolls-Royce, 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.