Support Engineering in the Concept Phase
What follows below has been extracted from a more detailed paper addressing Support Engineering in the Concept Phase of a system's life cycle which will be published on the Aspire Web Site in due course. This will be one of a planned series of papers addressing a Systems and Systems Engineering approach to Support Engineering. This is not a new departure for Aspire, we have been promoting such an approach for over 20 years now, but the intent now to align, in far as it is practical and desirable, this approach with that defined in ISO 15288, the international standard for Systems and software engineering - System life cycle processes. In addition to ISO 15288 Aspire have been reviewing a wide range of other texts such as the INCOSE Systems Engineering Handbook and the NASA Systems Engineering Handbook, to name just two, with the intention of adopting and adapting any good ideas that they might have.
Life cycle phases and systems engineering go pretty much hand in hand. Systems Engineering is about managing complexity and breaking a complex process down into defined stages is one mechanism (of many) by which that complexity can be brought under control. Such an approach is therefore relevant to Support Engineering, a complex methodology, leading to a complex and critical product.
The Concept Phase however is probably one of the most challenging and critical of the life cycle phases. Challenging because we are starting with what appears to be a blank sheet of paper and critical, because the manner in which the programme is initiated will set the tone for the remainder of the programme.
The first thing we need to understand is just what is the purpose of a Concept Phase, i.e. before we start working out what to do, we need to be clear as to the "WHY". This is true of any stage of any programme of course, but when planning for any phase of a system life cycle we also need to be absolutely clear as to what the overall programme aims are, not just those of the present phase. I have however only addressed the outcomes of the Concept Phase in the diagram below, the "Product" of a Support Engineering programme, the "Support Solution" has been addressed in other papers and will be again in future papers in this series. The processes by which the Concept Phase outputs are developed is also addressed, albeit at a high level, in this rather busy diagram. Which I hope is readable when published on LinkedIn.
This approach follows some key concepts as defined in ISO 15288. Some of the terminology used may sound a little esoteric, but it is worth spending some time getting to understand these concepts, they are robust and logical. The key concepts are:
- Define the Problem Space
- Define the Solution Space
- Define Solution Classes
- Develop the Design and the Requirements in parallel, via an iterative and recursive process (hence both the solution and the requirements evolve as the options are narrowed)
These concepts are combined with others that are derived from sound Support Engineering practice. Namely:
- The concept of the Total System, for which we develop both requirements and the 'Design'.
- The need for mechanisms for capturing System Definitions and the use of these to establish system baselines (because so many support measures are probabilistic, i.e. they are statistical measures and as such wholly reliant on historical data).
- The need for, and the role of, support models in order to replicate and to understand the complex interactions that occur between the elements of the Total System. This being essential if meaningful trade offs and investment appraisals are to be carried out.
- The initiation of the Support Case
Concept Phase activities may in practice be very curtailed, Support Engineering activities in particular may be 'put off' until later phases or indeed not implemented at all. There is a strong argument that such shortcuts lead to very significant cost and operational penalties downstream.
Now it is time for organisations to review Support Engineering practices and those that could be and should be implemented in the Concept phase in particular, if we get these right, the rest of the programme is likely to follow in a similar vein.
Salma Suleyman CEng Salma, many thanks. My focus is very much on Defence and yes the double diamond model complements systems engineering approaches and as such, it is applicable to Defence programmes. The model could be used, 'as is' for small projects; for complex projects the diamonds overlap and are addressed iteratively. Illustrating the enormously complex processes that underpin major defence programmed is a challenge, this model helps I think. Even a cursory look reveals that there are ideas here which could be usefully introduced (or re-introduced in some cases) into the Defence sector. I particularly like some of the ideas in the 'Discover' phase. The Project 13 information also looks very interesting although I have only skimmed over it so far. Once I have read the various reports properly I will report on any ideas that I think will bring benefit to the Defence sector. This wealth of information illustrates why I am keen to create a process "framework" for Support Engineering. This would enable us to extract ideas and insights from papers such as these and to consolidate them, by integrating them into the core framework. Thank you for engaging.
Thank you for sharing Peter. The diagram (which is readable on my screen) echoes the "The double diamond" that is well known and used in design. The first diamond is the divergent and convergent thinking to define the problem. https://www.designcouncil.org.uk/news-opinion/design-process-what-double-diamond It's effective to grow new ideas off established ones, they seem to get further - could the methods described above be positioned as a way to do the double diamond which is already an established approach? I can see your focus is on defence; you may be interested in Project 13 work in the infrastructure industry, which is promoting a system approach http://www.p13.org.uk/
"Concept Phase activities may in practice be very curtailed, Support Engineering activities in particular may be 'put off' until later phases or indeed not implemented at all. There is a strong argument that such shortcuts lead to very significant cost and operational penalties downstream." Agree. Do we have good data/studies to help with making the business case for improving this?
André Römer Andre, I’m out of the office all day tomorrow but I will send you a copy on Thursday.
Ian Gibson All too true Ian, which is of course one of the reasons for writing this. My sense is that, in the Defence sector at least, that all early life cycle phase activities are being somewhat neglected, not just Support Engineering. The level of investment in the Assessment Phase for example is also much reduced from where it was in the earlier days of the CADMID cycle. I have thought for many years now that there was a conflict between the original intend of SMART procurement - systems engineering principles, an iterative process etc - and a waterfall approach to procurement. I fear that the waterfall approach is winning out, driven in part by MoD commercial imperatives. The paper will be available online once we're done some rejigging of our website. Although the paper is officially complete, I'm still adding to it as new thoughts occur to me, so it will no doubt evolve over time. That said, my aim is to establish a robust systems engineering based framework for Support Engineering. A framework which can then itself evolve, a framework upon which we can accrete good ideas and best practice. If anyone wants a working copy of the paper I will be happy to email it to them in the interim, it would be good to get some early feedback.