Systems Engineering and Project Management: a personal recollection
I have been a Chartered Engineer for 23 years and a Systems Engineer for somewhat longer, having completed my post-grad Weapons Engineering and Systems Engineering courses in 1988, shortly before being appointed to an ancient Leander-Class Frigate (for which the Systems Engineering Course was not required)! At that stage of my career I saw engineering and management problems in simplistic terms - cause and effect closely linked; and 'good leadership' the answer to many management problems. I felt very strongly that 'failures' (such as my 'botched' appointment) were inexcusable in a properly run Service and that 'bureaucrats' were at the root of most of the problems we faced in the Front Line.
This was what in effect prompted me to an interest in Project Management, then just starting to rear its head in Defence. When I finally went to the Ship for which I had been trained – a Type 42 Destroyer - I was faced with a warship leaving refit with innumerable incomplete repairs and upgrades and many 'workarounds' designed to overcome poorly executed systems design, procurement and implementation. Following the invasion of Kuwait, we added a further 47 enhancements to the warship (some of which we had not even heard of) before joining the coalition forces in the Gulf).
It became clear to me when I joined BMT in late 1991 and began working initially as a Combat Systems Design Engineer, and subsequently as a Risk Manager, that the underlying reasons for our Front-line problems were far more complex and ill-defined than I had appreciated. However, I was determined to apply my engineering common-sense to these problems and in the early days of Risk Management, working on the Future Frigate programme with a number of like-minded engineers and non-engineers, we created an approach which became in many ways the basis for the discipline across Defence.
The crucial step for me was the recognition that in order to provide an effective fighting system at sea, the much broader commercial, managerial, design, procurement etc. environments had to be considered as part of a larger system (or system-of-systems, although I did not become aware of that usage for another decade or so). The difficulties in these systems were not technical, but had problems of non-linearity, unclear cause and effect, uncertainty around key decision variables and all the other complexities which we have grown to know and love over the years.
Many took the poor performance of these procurement and management 'systems' as inevitable, but there had been a drive from the early-mid-80s to improve defence management, mainly through the introduction of more competition and private sector involvement. One flaw in this approach was that the classic competition approach tended to favour insufficient planning, a low price and a reliance on requirements change to make a profit. Project Management was fairly rudimentary at this stage - far less rigorous and organised than we are today - and Programme Management would have been equated by the majority with schedule management. Schedules were few and far between and seen as unnecessary by many.
In Future Frigate, our approach was to apply a 'systems thinking' perspective to the problem. A number of us with a systems engineering background were largely self-taught in Project Management (although I had done modules in my BSc and Naval training) and went back to basic principles to analyse the requirements for 'management systems' and then to design a structured approach to Schedule and Risk Management which aligned with the key sub-systems in 'product' and 'management' domains. Subsequently, we introduced a 'cost' dimension to our work which at the time we called 'Cost and Schedule Control System (CSCS)' and subsequently became rebadged as EVM.
The skillset developed as a systems engineer is also useful for a Project or Programme Manager. One of my main tasks as a practising Systems Engineer in a warship was to manage non-technical stakeholders while simultaneously reconciling the demands and realities of Engineers who needed time and materiel to keep their equipment functioning. This role as a go-between, with the need to act as advocate and interpreter in both directions and determine when to insist and when to concede, was great preparation for the role of Risk Manager and later Programme Manager. A systems engineering background enabled easier communications with even the most highly-specialised engineers, allowing real concerns from Commercial, Financial or other non-technical disciplines to be examined and understood more easily in the form of risks or issues.
In Summary, hopefully I have explained why I believe that Systems Engineering is both highly relevant to wider management disciplines and provides an excellent basis for mastering them.