Space Systems Engineering

The Pareto Principle, or 80-20 Rule, is a very useful rule of thumb in many disciplines. It represents the common observation that typically 80% of the effort in any endeavour goes into reaching the last 20% of the desired performance. Or, looked at another way, 80% of the value of something comes from 20% of its content. 

Aerospace technology, and the field of Space Systems Engineering in particular, often provides clear examples of this principle. New space missions are complex, expensive and often high-profile. The temptation is often for mission objectives to be set at the limit of what is possible. As a result, the technical requirements are inevitably very challenging, with a constant risk of spiralling costs.

Good Systems Engineering processes provide the discipline to manage these requirements, from their initial definition, through to their ultimate validation in long-term service. The term “Systems Engineering” is widely misused as a catch-all for any technical activity that doesn’t fit neatly into other areas. Although it is a broad discipline, because it inevitably has to consider a project or system as a whole, the objectives of the Systems Engineer are very simple:

• Understand precisely what the system is intended to deliver,
• Then steer the most appropriate route to achieving that mission.

It sounds very simple, and yet it is rarely done well. At JAYLAMBDA we have the experience and skills needed to help those developing complex missions to avoid the common pitfalls waiting for less experienced Systems Engineers such as:

• Inadequately specified requirements – the most common problem
• Over-specified requirements – often manifesting as incompatible technical specifications at sub-system procurement, which leads to contractual as well as technical problems
• Inflexible requirements – The whole Systems Engineering team need to understand which requirements are sacrosanct, and which can be pushed back slightly for the overall good of the programme.
• Considering the need and constraints of the eventual system users and operators too late – Bringing in the requirements for the long-term support of a system after the technical architecture has been fixed is a good way to waste money for many, many years.