Much is made today of contemporary systems engineering, how it is a branch of engineering, and how it is supposed to 'operate.' It is highly educational to look back and see how things were done in the heyday of systems engineering in the UK, the 1960, 70s and 80s. Great emphasis was placed, for example, on exploration of the problem or situation, and on the environment in which the solution system would be required to operate. This exploratory phase included:
- problem scoping, particularly because experience showed that the customer frequently misunderstood the situation, and declared the wrong problem, or failed to get to the root of the problem
- conceiving potential solution options
- exploring the various Concepts of Operations (CONOPS) which each option might invoke, with associated threats and risks
- conceiving operational systems design, both functional and functional/physical, together with systems integration facilities
- designing the complete solution to the customer's (real) problem, including the operational solution, operator simulators and trainers, servicing and maintenance facilities, publications, etc., etc.
There was a quite different attitude to the customer, too. Perhaps because the systems engineering team really got to understand the problem, the situation and the risks involved, they tended to feel that they knew what the customer, and particularly the user, needed better than the customer and current operators did. (Contemporary operators were inhibited by knowing only their contemporary facilities and situations, and were often unable to imagine how they might use completely new facilities in operations.) And, while customers had to be served, it was the future users and operators who were the real customers… or, so we believed.
One last difference: this early phase, which might last two years or more for a complex problem, issue or situation was of uncertain duration and so was not conducted to a fixed price. Instead, it operated under "cost plus" contracting conditions, with the contractor encouraged to go into as much detail as necessary to ensure accurate specifications and robust implementation plans.
Managing Systems Creation is a prize winning paper from 1986 which shows the fundamentally different attitude to the undertaking of systems engineering activities that existed at the time — to such a degree that some readers might find it difficult to reconcile this former view of systems engineering with their own, contemporary views. How could they possibly be the same subject?