Systems Lifecycle Cost-Effectiveness

The Commercial, Design and Human Factors of Systems Engineering

Massimo Pica

• Editorial: Routledge
• Año: 2016
• ISBN:
  9781317047131
• Edición: 1
• Categoría: Negocios y empresa
• Categoría: Gestión de proyectos

Traditional costing models for new systems and new buildings in industry, defence or government, have tended to focus on the costs of acquisition and implementation, with scant regard for the costs of running the system or decommissioning after use. The pressure to minimize expenditure and provide value for money from reduced resources means that complex projects have to encompass a wide range of often conflicting issues and interests. Systems Lifecycle Cost-Effectiveness shows how to manage the difficulties that can arise. Optimizing the system lifecycle cost-effectiveness is complex and influenced by many factors. Massimo Pica presents a variety of models for calculating cost, benefits and risk in projects, and explains how the human factors associated with a system's design and consequent value are as important as the technical costs associated with its construction or creation. This comprehensive text can be used by students, experienced system engineers, cost analysts and managers to improve their understanding of the wide range of issues involved in the evaluation of system life cycle cost-effectiveness.

PART ONE

Basic Concepts

1

Systems Design and the Characterization of Systems Requirements

‘Seek first to understand. Then to be understood’ (S.R. Covey)

Systems Engineering, Human Systems Integration and Life Cycle Cost

The devil is in the cost details. At least, this is the case for systems users around the world who face the herculean task of procuring, deploying and maintaining systems, equipment and material in a reliable condition. If, generically speaking, we refer to a ‘system’ as every type – however complex – of asset released as a result of a design effort, system procurement processes are influenced, in most cases, not only by the initial purchasing cost of a system, but particularly by all costs arising before and after the system is delivered for operational use. This would also include a specific retirement stage at the end of the system life cycle. The total amount of these costs, for a single system, is referenced in this book as Life Cycle Cost (LCC).

Designing a system, component or process to meet desired needs is a decision-making process (usually iterative) in which the basic sciences, mathematics and the engineering sciences are applied to convert resources optimally to meet these stated needs.

Typical users expectations are for systems that comply with operational needs and are reliable and competitive from the point of view of costs (that is, LCC) throughout the system life cycle. Life Cycle Cost is (or, indeed, should be) the dominating economic element in the selection of affordable systems to be procured and delivered: in fact, this sort of decision is influenced not only by the initial unit acquisition cost but, more significantly, by all subsequent unit costs, including retirement. Therefore in principle – albeit ideally – all different parties empowered in the management of the whole life cycle of systems should be involved from the beginning in decisions affecting systems Life Cycle Cost.

While systems are primarily designed to accomplish specified functions and operations, Systems Engineering principles (in the broadest context of the terminology) are commonly applied to certain advanced technology areas such as aerospace, electronics, ICT, but a system can be nevertheless identified as the product of any generic, industrial or civil, engineering effort intended to implement more or less complex functions (namely, ranging from a process plant to a residential area).

In summary, one of the key objectives of Systems Engineering is to realize systems that can perform their mission as cost-effectively as possible, taking into consideration the whole performance – cost – schedule – risk targets over the system life cycle. The Systems Engineering Handbook of the INCOSE (International Council on Systems Engineering) notes that ‘As both complexity and change continue to escalate in our products, services, and society, reducing the risk associated with new systems or modifications to complex systems continues to be a primary goal of the systems engineer’; and subsequently: ‘New systems are designed, developed, manufactured, and verified over the span of many years, as in the case of a new automobile, or nearly two decades, as in the case of a submarine. Over such lengths of time, decisions made at the outset may have substantial, long-term effects that are frequently difficult to analyze’.

An understanding of the extent of information affecting systems design is also important for a cost-effective management of the Systems Engineering effort, in accordance with the following basic elements:

• Comprehensive knowledge of system life cycle objectives.

• Appraisal of System Requirements.

• System definition.

• System implementation and integration.

• System assessment.

The operational need and/or commercial opportunity is expected to be initially rather unclear, so that the Systems Engineering effort, taking also into account any specific contractual, financial or technical constraints, should be initiated by a thorough exploration of how operational needs or commercial opportunities are perceived by all interested parties, while resolving in a timely fashion any conflicting judgements or, possibly, preventing their unwanted occurrence.

Systems Engineering is applied iteratively in order to release to users systems satisfying operational needs or commercial opportunities. On the basis of an appropriate understanding of operational requirements, Systems Engineering supports the specification, design, development and integration of systems of interest in agreement with a ‘customer-centric’ perspective. The compliance of the system to the requirements will be finally assessed as the system is developed.

Systems Engineering is also focused on the reconciliation between two different positions, namely those of the customer and of the designer/manufacturer. The customer will look at system functions and system performance to achieve operational goals and at system operational availability, usability, safety and maintainability to optimize life cycle expenditures. The designer/manufacturer will, in turn, look at meeting commercial needs, at efficient producibility, at business growth potential and reputation.

Long-term system success and user satisfaction rely deeply upon demonstrated effectiveness of the total system inclusive of personnel. In all systems, failure to address long-term, life cycle issues can result in failure to accomplish the intended purpose/mission, a poor design, unnecessary manpower burden, increased incidence of human errors, excessive Life Cycle Costs and, in some cases, negative impacts to the environment and public health and safety. Moreover, economic penalties may include loss of customer confidence, reduced market share and occurrence of product liability. Without this total system approach, the system as an enterprise solution will not meet optimal total performance and/or Life Cycle Cost objectives.

On the other hand, system design is not exclusively based on engineering practices. Development of creativity, ability to approach open issues and other more personal skills are useful in safeguarding conformity to practical constraints such as economic factors, safety, reliability, aesthetics, ethics and social impact.

The widespread application of Human Systems Integration (HSI) to system life cycle is intended to optimize total system performance (that is, human, hardware and software), while accommodating the characteristics of the personnel that will operate, maintain and support the system, including appropriate support measures to reduce costs across the entire system life cycle.

Human Systems Integration helps designers focus on long-term costs since a major percentage of Life Cycle Cost is related directly to human performance. It is critical to include HSI early in system acquisition (specifically, in the timeframe of capabilities requirements generation) and continuously through the acquisition process to realize the greatest benefit to the final system solution and substantial LCC reductions.

HSI implementation emphasizes the role of human contribution to system cost effectiveness. In addition, HSI is one of the essential components of engineering practice for system acquisition, providing technical and management support to the acquisition process itself. Human considerations that need to be addressed in system acquisition should specify the number and type of personnel in the various occupational areas required and potentially available to train, operate, maintain and support the deployed system. The personnel community promotes pursuit of engineering designs that optimize the cost-effective use of human resources, keeping their costs at affordable levels. Determination of required personnel positions should recognize the developing burdens on humans (for example, in terms of cognitive, physical and physiological characteristics) and consider how technology can affect individuals integrated into a system.

Concurrent assessment of HSI issues across all the domains and against mission performance is needed prior to undertaking formal programmatic commitments. This approach alleviates the perspective of unintentional, negative consequences, including higher technical risks and ensuing costs.

HSI requirements should be effectively coordinated with other system requirements and should consider any constraints or capability gaps. The human (and, consequently, ergonomic) aspects identified in the requirements should address the capabilities and limitations of all personnel interacting with or within the system. HSI requirements should be reviewed, refined and modified as programme documents, system requirements and specifications are updated. If these actions are undertaken from the beginning, regularly and carefully, then this will positively contribute to the acknowledgement of the risks and costs associated with programme decisions. HSI should be part of the initial life cycle strategy and LCC and life cycle sustainment documents.

Systems designers and HSI specialists should be prepared to present accurate, integrated cost data whenever possible to demonstrate reduced Life Cycle Costs, thereby justifying trade-off decisions that may influence acquisition costs as a result of more accurate design.

Human Factors (HFs) are a direct application of ergonomics, which is the scientific study of human work. HFs have been defined by the International Ergonomics Association (IEA) as ‘the scientific disciplines concerned with the understanding of the interactions among human and other elements of a system and the profession that applies theory, principles, data and methods to design in order to optimize well-being and overall system performance’. HFs analyze systems with a human-based approach, looking at individual systems from the users perspective, designing interactions with a system in compliance with operator profiles. Operator interaction with the system is performed through the utilization of a Human Machine Interface (HMI) mechanism, by inserting information to setup system capabilities and checking operational results to monitor the system behaviour. Interaction means that the operator is an active entity of the system.

HF engineering (that is the set of activities concerning HFs related matters identified through Systems Engineering processes) is applicable to all human-operated equipment and systems, however simple they might be.

Definition of System Requirements

The system design shall offer facilities to provide the relevant information to the right operators. The pursuit of this key aspect should always drive the system design. Failure to recognize and address likely human performance characteristics often leads to systems that do not meet their requirements or that experience unwanted breakdowns or cost growth.

Better requirements, which are an essential part of the technical baseline of a system acquisition programme, provide a primary opportunity for improving the outcomes of the system life cycle in the usual terms of cost, schedule and product quality.

In the past, requirements problems were typically considered as the single biggest contributor to cost overruns, schedule slippages and loss of capability in systems and software projects. Current reports in the UK only partially agree with this statement and are attributing the biggest contributor to the impacts from schedule delay caused by indifferent or poor management decision making. This sort of debate is still continuing in light of financial budget cuts and this, in itself, has caused amendments to the requirements (bit of a causal loop).

Table 1.1 is a classification of typical requirements.

Table 1.1 Classification of typical requirements

TYPE OF REQUIREMENT	CRITERION
State/Mode	States the required states and/or modes of the system, or the required transition between one state and another state, between one mode and another mode, between mode in one state to mode in another state (A ‘state’ is a condition of something. A ‘mode’ is a group of functionality related to purpose).
Functional	States what the item is to do.
Performance	For a given function, states how well that function is to be accomplished by the item.
External Interface	States the required characteristics at a localized point, or region, of connection of the system to the outside world.
Environmental	Limits the effect that the external enveloping environment (natural or induced) is to have on the item and the effect that the system is to have on the external enveloping environment.
Resource	Limits the usage or consumption of an externally provided resource by the system.
Physical	States the required physical characteristics (properties of matter) of the system as a whole (for example: mass, size, volume)
Other Quality	States any other required quality of the item that is not one of the above types, nor is a design requirement.
Design	Directs the design (internal components of the system), by inclusion (‘build it internally this way’) or exclusion (‘do not build it internally this way’)

In this context, requirements and resulting operational concepts will be translated into preliminary design documents, models, and prototypes, accompanied by relevant life cycle schedule elements and by initial cost estimates.

System functions need to be specifically identified. The system will be required to perform certain operations and support functions; consideration will be properly given to how well the system is required to perform each function, to the conditions under which the system is to begin performing that function, is to be capable of performi...