Search

The UK Ministry of Defence (MOD) has embraced innovation as a means of leveraging operational advantage by pulling ideas through to operational capabilities more effectively and efficiently. As a result it has announced the Defence Innovation Initiative (DII) aimed at attracting investment from government and non-government sources and to improve value for money. This paper explores the challenges associated with delivering enterprise-level innovation and suggests that holistic systems approaches that are sensitive to the locus of innovation within an enterprise system are needed to secure superior value from ideas. Our early findings show the utility of addressing innovation system coherence through an understanding of the models, constructs and time constants within the innovation landscape when viewed from the perspective of the Operate function within the Defence Operating Model. The insights derived have the potential to inform the approach taken by the UK DII and, by generalisation, the design of innovation systems within the context of any complex adaptive system (CAS).

Agility is all the rage. Across the landscape, businesses request agility as a deliv- erable, make claims that they are agile, and (some) go so far as to assert they can provide agility to other corporate entities outside of their own sphere of influence. The challenge before us as a Systems Engineering Community is that (Enterprise) Agility, although well documented throughout engineering literature since the early 1990s, is often misinterpreted. Agility means many things to many people, and heretofore, has been used as a synonym for rapid develop- ment and delivery. Although speed is a byproduct of agility, speed in and of itself is not robust enough to encompass all that agility provides an organization, its customers, and partners. The goals of this paper are to shed light on agility in context to businesses, especially with Enter- prises engaged in Systems Engineering, and provide guidance as to how agility is best achieved regardless of the Enterprise's business or mission objectives.

Each of the major systems engineering standards and guides has a different focus, uses slightly different terms for the various needs and requirements artifacts, and reflects a different emphasis on each of the activities from the enterprise level down to the system level. While there is a lack of consistency among documents with the use of terms and artifacts (and all are internally inconsistent to some degree), the differences are not significant and mostly reflect the different emphases on particular levels or specific parts of the overall process. None-the-less, the disparate views result in considerable obscuration of the underlying process which can only be resolved after considerable study and deliberation. Worse, the lack of a common taxonomy in the early part of system/requirements engineering process adds confusion at a very critical time in the definition of the system of interest. This paper reviews the early processes and the needs and requirements artifacts described in the major systems engineering standards and guides. An improved (synthesized) taxonomy is proposed that clarifies the language used to describe the major processes and artifacts in the early portion of the system life cycle.

Extending the definition of quality, cost, and delivery (QCD) from the program or project level to the Business Unit and indeed to the Enterprise level establishes a framework to effectively assess the value of system engineering (SE) in commercial enterprises. Most of the value of SE lies at these higher corporate levels where business and technical metrics intermingle. The Enterprise QCD approach supports a clear definition of system engineering. Three major confounding factors must be dealt with in valuation. In commercial environments, much system engineering is conducted by individuals not carrying the title “system engineer.” Second, attempts to correlate benefits to the quantity of systems engineering will be confounded by the fact that high quality systems engineering reduces the needed quantity. And third, the stage of the enterprise in its life cycle must be taken into account when evaluating the role and value of systems engineering. Effective competitive benchmarking and before/after comparisons can get at the value of SE while minimizing confounding effects. Improvements in QCD should aim at large increases in performance.

Process literature has provided excellent guidance on what to include when writing new process descriptions, but very little has stated clearly what actions must be taken by companies during the course of developing usable, integrated processes. Countless hours have and are being spent on development of company processes, which end up sitting on shelves in their unopened, shrink-wrapped notebooks, or archived to sparsely accessed and often ignored internal web sites. Management assumes the processes must not be the right ones, or personnel would joyfully use them. The result is yet another extensive effort to “get it right” by re-writing the processes with a different slant. Why is it that processes are not well received or utilized by some companies, yet others embrace process with open arms? This paper explores the author's experienced pitfalls of integrated, system process development at an organizational level, whether that translates to a program, division, or enterprise level, and offers avoidance solutions to help remedy the maladies. This paper is intended to provide solutions to circumvent the common maladies associated with process development and process improvement.