8.3.1 Certainty, Risk and Gambling in the Development of Complex Systems

Abstract

AbstractOne of the few things certain about development of complex systems is the requirements for the system will remain uncertain late into the development program. Even though we recognize this, why do many programs assume that requirements will not change (gambling) or treat requirement change as a risk rather than a certainty? An analysis of gas turbine engine control systems requirements shows that typically 50% will change between Critical Design Review and Entry into Service. This requirements uncertainty manifests as technical risk to the programme. This paper evaluates the impact of not managing these uncertainties and describes how applying Systems Engineering principles can reduce this effect.Design iterations produce rework, and without technical risk management, ~50% of the effort will be wasted in producing unacceptable designs. In turn, correction of these errors will create more rework. This results in much iteration and cumulatively twice as much work is required to produce a mature design. With technical risk management, less than 10% of the design effort will result in rework, giving a mature product with far less iteration.Investigation into the source of the product development lifecycle problems indicates many escapes occur during requirements definition and review. Around twice as many changes are driven by errors in requirement definition by the developer, compared to customer‐driven requirements changes. In addition, many of these escapes are detected later in the product development lifecycle than they could have been found, resulting in further escalation of the cost of product development. This paper compares and contrasts the root causes for these escapes during system, software and hardware development and looks at the differences in consequences.The role of the Systems Engineer is critical in addressing these problems. In addition to effective elicitation of requirements from stakeholders, the Systems Engineer must manage volatility and apply robust design principles to protect against the impact of requirements changes. The Systems Engineer must flow requirements effectively from system to sub‐system, from sub‐systems to components and provide the “glue” that results in the integrated system being more than the sum of its parts.Some tools and techniques are presented to help Systems Engineers identify probable sources of uncertainty and provide effective mitigations. An approach is also presented for assessing the technical risk management “maturity” of a project, based upon ‘best practice’ approaches taken from those projects achieving low levels of engineering scrap and rework during their development phase.