Organizing Business and Enterprises to Perform Systems Engineering

note - preliminary edit from v0.25 - need to do citations, transfer figures and do a clean up edit. It is currently slightly over word count limit

Overview

Each organisation is unique. The type and scope of the overall organization determines the particular way Systems Engineering is deployed and carried out to suit the purpose of the organization. This topic summarizes the issues that drive the organizational “design” decision and issues that may arise, and what needs to be done to ensure that Systems Engineering delivers maximum value to the organization. This has to take into account the factors that cause organisations to be different.

A summary of the common environmental factors that drive is presented in the table below

Put in table 11 from v0.25

Different possible structures for an organization , and how SE interacts

Organizations manage SE resource in many different ways. A key driver is the extent to which they seek to optimize use of resources – people, knowledge, and assets – across teams, projects and businesses. There are four basic ways of organizing resources to support multiple projects: Project organization; Matrix organization; Functional organization; and Integrated organization (CM Guide 2009), (Handy 1985), (PMI 2008 section 2.4).

A project organization is one extreme where projects are responsible for hiring, training and terminating staff and managing all assets required for delivery. In this model, systems engineers on a project report directly or indirectly to the project manager, and resources are optimized for the delivery the project. However, it does so at the expense of sub optimizing how staff are deployed across the larger enterprise, how technology choices are made across projects, etc. The (DAU 2001) SE Fundamentals gives a recent DoD view of good practice project organizations.

A functional organization is the opposite extreme, where projects delegate almost all their work to functional groups. This is appropriate when the functional skill is fast-evolving and dependent on complex infrastructure and is often used for manufacturing, test engineering, software development, financial, purchasing, commercial and legal functions.

Very often a matrix organization is used to give functional specialists a “home” between project assignments. This is a common approach in systems engineering organizations where a SE functional lead is responsible for workforce development and may manage career development by giving individuals variety of development experience in different assignments.

In an integrated organization, people do assigned jobs without specific functional allegiance. Those who perform SE tasks primarily identify themselves as another type of engineer such as a civil or electrical engineer. They are knowledgeable of systems engineering and use it in their daily activities as required.

Systems engineering is relevant to and depends on other organizational functions. Some organizations see SE as purely about project delivery. Others see it as a key enabler for innovation for new and improved products and services. Typical relationships with other organizational functions are shown in the following table. These relationships should all add value to the business.

Include table 12 from V0.25

Goals and measures in an organisation

The alignment (or otherwise) of goals and measures across the enterprise strongly affects the effectiveness of systems engineering effort and the benefit delivered by SE to the enterprise. See for example

• (Blockley and Godfrey 2000) describe techniques used successfully to deliver a major infrastructure contract on time and within budget in an industry normally plagued by adversarial behavior.

• Lean thinking (Womack and Jones 1998, Oppenheim et al, 2010) provides a powerful technique for aligning purpose to customer– provided the enterprise boundary is chosen correctly and considers the whole value stream.

• (Fasser & Brettner 2002, 18-19) see an organization as a system and advocate three principles for organizational design: “increasing value for the ultimate customer”, “strict discipline”, and “simplicity”.

• EIA 632 (EIA 1999) advocates managing all aspects required for through-lifecycle success of each element of the system as an integrated “building block”. Similarly, (Blockley, 2010) suggests that taking a holistic view of “a system as a process” allows a more coherent and more successful approach to organization and system design, considering each element both as part of a bigger system of interest and as a “whole system” (a “holon”) in its own right.

• (Elliott et al, 2007) advocate 6 guiding principles for “making systems that work”: “debate, define, revise and pursue the purpose”; “think holistic”; “follow a systematic procedure”; “be creative”; “take account of the people”; and “manage the project and the relationships”.

Need for clarity of SE approach, and dangers in implementing SE

In any organization where activities and skills are shared there is always a danger of silos or duplication. One of the purposes of Systems Engineering is to reduce this risk – consider the interface or glue role (Sheard 1996), or the idea that “SE is good engineering with special areas of emphasis, … including interfaces between disciplines” (Blanchard and Fabrycky 2005).

Iit is important to have clarity on how the organization is doing its Systems Engineering. Typically, implementing SE may be part of an organisation improvement, so Kotter’s principles on creating a vision, communicating the vision and empowering the others to act on the vision are most relevant (Kotter 1995). The way an organization chooses to do Systems Engineering , should be part of the vision of the organization – and must be understood and accepted by all.

Many of the major obstacles in systems engineering deployment are cultural. There is more detailed discussion in culture (add link). A critical issue in effective organizational deployment of systems engineering is establishing and managing cultures, values and behaviours (Hofstede 1980), (Fasser & Brettner, 2002). A high degree of churn or imposed change can disrupt established cultures that are key to effective systems engineering. A safety or process culture can be damaged by too high a pace of change (see e.g. the Nimrod Crash Report (Haddon-Cave, 2009) or by perceived management imperatives. Jackson (Jackson 2010, chapter 5) uses the Challenger space shuttle disaster and many other case study examples to illustrate this point, and provides further references.

Definition of roles

Systems engineering organizations need to establish a career and people management structure to cover three key issues for business success: how are people recruited, trained, allocated, supervised, promoted, and rewarded; how to optimize use of expertise, across projects and business units; and how to develop SE skills. . Once these roles are defined then individuals need to occupy and develop in them (see 4.2) and teams need to use them (see section 4.3)

Sheard (Sheard 1996) lists twelve system engineering roles. Moreover(Sheard 2000) draws an important distinction between roles involved in the “discovery phase”, characterized by a high level of uncertainty, the “program phase”, which is more deterministic and defined, and the overall systems engineering “approach”. (Kasser et al 2009) identify five types of systems engineer distinguished by the need to work at increasing levels of abstraction, ambiguity, scope and innovation.

Systems engineering role will exist within an enterprise “ecosystem”. There are two key points to consider:

• Nurture and value the Systems Engineer. Doing Systems Engineering well, despite (or perhaps because of) it being apparently common sense, it very hard. There must be a reward mechanism for these experts, which may go against the normal reward mechanism (e.g. rewarding fire-fighters or heroes).

• The organization must “pull” value from the Systems Engineering, rather than the Systems Engineers “push”.

Governance of Systems engineering

SE governance establishes the SE culture and approach, and defines how and by whom SE decisions are made, monitored, and measured in order to deliver business value.

SE governance also establishes the framework and responsibility for managing issues such as design authority, funding and approvals, project initiation and termination, and the legal and regulatory framework in which the system will be developed and operate. Governance may also specify product and process measures, documentation standards [e.g. (MIL-STD 961E, 2003), (IEEE 1233-1998)], and technical reviews and audits e.g. (MIL-STD-1521B, 1985). These points are captured in the organization’s policies, processes, and practices, or conform to policies established at the level above. They should cover the organizational context and goals, the responsibilities for governance, process, practices and product at the level of interest, tailoring guidelines if appropriate, and the freedom delegated to and governance and reporting obligations imposed on levels below. It is good practice to capture assignment of people to roles and responsibilities in the form of a RACI (Responsible, Accountable, Consulted, Informed) matrix or similar. Responsibility in large organizations can become dangerously diffused. (Sommerville et al, 2009) discuss the relationship between information and responsibility and describe methods to analyse and model responsibility in complex organizations. Small organizations tend to have relatively informal governance documentation and processes, while larger organizations tend towards more structure and rigor in their governance approach. Government contracting typically brings additional regulation and oversight, driving a group to greater rigor and documentation and specific practices in their SE governance; as does developing systems or operating services that affect public safety or security, such as the creation of medical devices or the operation of an emergency response system, Air Traffic Management, and the nuclear industry, see for example (Jackson 2010).

Systems engineering performance should be measured and managed at business level. Evaluation should address how well Systems Engineering organization is supporting the business (doing the right things) as well as how well the SE process is delivering to its own targets and measures (doing things right). Any measures on Systems Engineering must be traceable back to the organization’s purpose. It may be necessary to sub-optimize the systems engineering aspects in order to optimize the performance of the whole business.

SE measurement to date has focused more on measuring SE itself than on measuring the benefits SE delivers to the business or the wider enterprise. Focusing entirely on project performance is itself a form of sub-optimization. A project may apply “lean” to their activities – anything that does not assist the delivery of the project goals is “waste”. This can prevent activities of value to the business – such as the learning of lessons, defining the standardization across the business, identifying short falls in capability and closing the gap through the projects.

The CMMI Organizational Process Performance (OPP) process area provides guidance on managing process performance across a business. General principles of measurement apply – look at balanced scorecards, and measure what is important rather than what can be measured. The following checks will help check for sub-optimization (as used in Toyota (Morgan and Liker 2006)): is the balance right between functional expertise and cross-function integration; do we build in learning and carry out continuous improvement; and how standardized is the organization – across projects and between different projects / functions?

Finally, those involved in the Systems Engineering part of organization must remember that the purpose of the SE is to help the organization achieve its purpose, not simply for the pursuit of perfect Systems Engineering. On the other hand, those not explicitly part of the Systems Engineering should remember why this part of the organization exists, and make use of it. Alignment of purpose and incentives is key to making the whole of an enterprise greater than the sum of its parts.

Citations in this topic

CM Guide 2009, Construction Management Guide “Project Organization Types”, on web at http://cmguide.org/archives/319

Handy C.B. 1985, “Understanding Organizations”, Penguin Business, London

PMI 2008, “Project Management Body of Knowledge”, 4th edition, ANSI/PMI 99-001-2008

DAU 2001. Defense Acquisition University, “Systems Engineering Fundamentals”, accessed on line at http://www.dau.mil/pubscats/PubsCats/SEFGuide%2001-01.pdf

Blockley, David, and Godfrey, Patrick, 2000, “Doing It Differently – Systems For Rethinking Construction”, Thomas Telford Ltd,

Womack, J and Jones, D, 1998, “Lean Thinking”, Simon Schuster, New York

Oppenheim et al. 2010, INCOSE Lean SE WG. “Lean enablers for Systems Engineering”, accessible at http://cse.lmu.edu/about/graduateeducation/systemsengineering/INCOSE.htm

Fasser, Yefim and Brettner, Donald, 2002 “Management for Quality in High-Technology Enterprises”, Wiley

EIA 1999 EIA 632 “Processes for engineering a system”

Elliott, Chris et al, 2007. “Creating systems that work – principles of engineering systems for the 21st century”, Royal Academy of Engineering, June 2007: http://www.raeng.org.uk/education/vps/pdf/RAE_Systems_Report.pdf

Sheard, Sarah. 1996, “12 Systems Engineering roles” Paper presented at the INCOSE 6th Annual symposium, Boston, http://www.incose.org/educationcareers/PDF/12-roles.pdf

Blanchard, B. and Fabrycky,W. 2005 “Systems Engineering and Analysis” 4th edition, Prentice-Hall International

Kotter, John P. 1995, “Change: Why Transformation Efforts Fail”, Harvard Business Review, March – April 1995

Jackson, Scott. 2010. “Architecting Resilient Systems: Accident Avoidance and Survival and Recovery from Disruptions”. Wiley

Sheard, Sarah. 2000 “The 12 systems engineering roles revisited” Proceedings of the INCOSE mid-Atlantic Regional Conference, April 2000, pp 5.2-1-5.2-9.

Kasser, Joseph, Hitchins, Derek and Huynh, T.V. 2009 "Re-engineering Systems Engineering" - proceedings of the 3rd Annual Asia-Pacific Conference on Systems Engineering (APCOSE), Singapore, 2009

MIL-STD-961E. 2003. "Defense and Program-Unique Specifications Format And Content", superseding MIL-STD 490A "Specification Practices", 1985

IEEE 1233-1998 Std 1233 “IEEE Guide for developing System Requirements Specifications”

MIL-STD-1521B 1985. “Technical Reviews and Audits for Systems, Equipments and Computer Software”

Article Discussion

[Go to discussion page]