Make Systems Engineering the Way Engineering is planned and done

Speaker: Richard Beasley. Rolls Royce
Venues: Stockholm, Helsinki, Oslo

The benefits of Systems Engineering in terms of increasing probability of success and reducing rework are well established. The problem is how to embed and utilise the Systems Engineering practice into the work so that the advantages are realised. The talk addresses this important question. 
Systems Engineering must be embedded into the organisation – both in the way engineering is done and the way the work is planned. Systems Engineering specialists are needed, but a systems approach is integral to all the engineering work. Therefore there should not be talk of a Systems Engineering Management Plan, rather a Plan for the Management of the Engineering of a System, using a Systems Approach. 
For an organisation the important things are: 
• Define lifecycle model appropriate to the domain the organisation works in. 
• Appropriate process that recognises full lifecycle, and for all system levels and system elements allows iteration between requirements, design, verification in each element and between levels. 
• Planning guidance to allow for insights of Systems approach to be used, allowing for progressive maturation of understanding and confidence in solution. 
• Appropriate skills and knowledge in the workforce. As well as technical skills and domain knowledge, Systems Thinking is critical for all. 
There is much of importance in Systems Thinking. The key to Systems Thinking is to recognise the key properties found in systems generally, and apply these to the System of interest to gain insight and understanding. Especially important is that the engineers understand the concepts of context, emergence, a system is made of parts (in themselves systems) and is a part of a bigger system, and that there are realisation systems needed to support the enterprise of creating / exploiting the system of interest. 
The planning of system develop must recognise the business / operational purpose of creating the system, as well as addressing the technical needs of the customers / end users. Whilst different systems types need different approaches, there is always iteration between requirements and solution in each level. Therefore the plan must look at progressive maturation of the requirements, the solution, the evidence the solution meets the requirements and the derived needs on other systems (lower levels and the realisation systems). Using the V-model (especially the “Assurance V”) each iteration is s a maturation of the information. Therefore, even in hardware systems where progressive realise is not possible; each iteration can be seen as an agile sprint. The purpose and define what is “sufficient to proceed” for each iteration must be defined. The planning must take time to address emergence – reduce amount of unwanted, achieve desired, and adjust when unexpected emergence is found. 
People are central to the implementation of Systems Engineering in an organisation. The need to learn and develop systems expertise must be recognised. A systems approach is about making the upfront investment to prevent unwanted emergence. The organisation has to trust the investment is worthwhile, commit to making it, and most importantly plan to do it and utilise the insights achieved.