Systems Engineering Organizational Strategy

---

Lead Authors: Alice Squires, Dick Fairley, Hillary Sillitto, Contributing Authors: Art Pyster, Alan Faisandier, Deva Henry, Rick Adcock

---

Virtually every significant business (glossary) or enterprise (glossary) that creates products (glossary) or services (glossary) benefits from performing a wide variety of systems engineering (SE) activities to increase the value (glossary) that those products and services deliver to its owners, customers, employees, regulators, and other stakeholders. (See Stakeholder Needs and Requirements.)

A business is a specific type of enterprise, usually a legal entity with a management structure that allows for relatively tight control of its components...including how it enables SE. The term business is often used in this article in lieu of enterprise because specific actions to enable SE are typically done by businesses. This is discussed further in the parent article Enabling Systems Engineering. The strategy for organizing to conduct SE activities is important to their effectiveness. For example, every enterprise has a purpose, context, and scope determined by some of its stakeholders and modified over time to increase the value the enterprise offers to them.

Some enterprises are for-profit businesses. Others are not-for-profit businesses that work for the public good. Still others are non-traditional businesses, but more loosely structured entities without legal structure, such as a national healthcare system. Some enterprises are located at a single site, while some others are far-flung global "empires". Some work in highly regulated industries such as medical equipment, while others work with little government oversight and can follow a much wider range of business practices. All of these variations shape the strategy for performing SE.

Primary Considerations

SE organizational strategy is driven by the goals of the business and the resources and constraints available to achieve those goals. SE strategy in particular is influenced by several considerations:

• The purpose of the business
• The value the business offers its stakeholders; e.g., profits, public safety, entertainment, or convenience
• The characteristics of the system which the SE activities support; e.g., the size, complexity, primary design factors, major components, required products, critical specialties, or areas of life cycle
• The phases of the life cycle in which the SE activities are being performed; e.g., development, deployment, operations, or maintenance of a product or service
• The scale of the business, the systems and services of interest; e.g., is it a single site company or a global venture? Is the business creating a relatively modest product for internal use, such as a new Web application to track employee training, or a new hybrid automobile complete with concerns for engineering, manufacturing, servicing, and distribution?
• The culture of the business in which the SE activities are performed; e.g., is the business risk-averse? Do people normally collaborate or work in isolated organizations?
• The business structure and how well the current structure aligns with what is needed to create new products and services; e.g., does the structure of the business align with the architecture of its major products and services?
• The degree of change or transformation that the business is undertaking in its operation, products, and markets

Rouse (2006) offers a thorough look at enterprise strategy, especially as it relates to delivering value to the enterprise in various phases of the life cycle, beginning with research and development through operations. Rouse provides a number of techniques to determine and improve the value offered to enterprises using SE methods, especially useful when an enterprise is undergoing significant transformation rather than conducting "business as usual"; e.g., the enterprise could be trying to

• do current business better (drive down costs or improve quality of its current products and services);
• cope with a disruption in the market, a competitive threat, or changing customer expectations and ways of doing business;
• reposition itself in its value chain (move from being a part supplier to a subassembly supplier); or
• launch a new generation product or enter a new market.

Eisner (2008) provides a thorough look at different SE organizational approaches.

Systems Engineering Strategy Elements

Based on the primary considerations, the SE strategy generally addresses the following:

• How SE activities provide value to the business (See Economic Value of Systems Engineering)
• How SE activities are allocated among the various business entities (See Organizing Business and Enterprises to Perform Systems Engineering)
• What competencies are expected from the parts of the business in order to perform these SE activities (See Deciding on Desired Systems Engineering Capabilities within Businesses and Enterprises)
• How parts of the business gain and improve competencies (See Developing Systems Engineering Capabilities within Businesses and Enterprises)
• Who performs SE activities within each part of the business (See Team Capability)
• How people who perform SE activities interact with others in the business ((See Part 6: Related Disciplines)
• How SE activities enable the business to address transformation (See Enterprise Systems Engineering).

Depending on the business' approach to SE, there may not be a single coherent SE strategy common across the business. Different business units may have their own SE strategies, or development of a strategy may be delegated to individual projects. The SE strategy may not even be explicitly documented or may only be found in multiple documents across the business. Some businesses publish guidebooks and policies that describe their organizational strategy. These are usually proprietary unless the business is a government or quasi-government agency. Two public documents are NASA (2007) and MITRE (2012). The latter has a number of short articles on different topics including an article on Stakeholder Assessment and Management and another on Formulation of Organizational Transformation Strategies.

Product and Service Development Models

There are three basic product and service development models that most businesses employ:

1. Market-driven commercial
2. Product-line
3. Contract

The biggest differences between the three business models are where requirements risks lie and how user needs and usage are fed into the design and delivery process. SE support to the business varies in each case.

Market-driven commercial products and services are sold to many customers and are typically developed by organizations at their own risk. The requirements come from marketing based on understanding the market, relevant regulation and legislation, and good ideas from within the organization (Pugh 1991, Smith and Reinertsen 1997). Sillitto (1999) contends that market-driven commercial product development is a form of systems engineering with adapted techniques for requirements elicitation and validation.

Product-line products and services are variants of the same product and service, usually customized for each customer. Extra investment is required to create the underlying product platform. Architecting such a platform in a way that supports cost-effective customization is usually more complex both technically and organizationally than market-driven commercial products and services.

Systems engineers typically play a central role in establishing the platform architecture, understanding the implications of platform choices on manufacturing and service, etc. There are a number of examples of good practices in product line; e.g., automobile models from virtually all major manufacturers such as Toyota, General Motors, and Hyundai; Boeing and Airbus aircraft such as the B-737 family and the Airbus 320 family; and Nokia and Motorola cellphones. The Software Engineering Institute has done extensive research on product lines for software systems and has developed a framework for constructing and analyzing them (Northrop et.al. 2007). For a reference on product line principles and methods, see Simpson (et al. 2006).

Contract products and services often demand tailor-made system/service solutions which are typically specified by a single customer to whom the solution is provided. The supplier responds with proposed solutions. This style of development is common in defense, space, transport, energy, and civil infrastructure. Customers that acquire many systems often have a specific procurement organization with precise rules and controls on the acquisition process, and mandated technical and process standards. The supplier typically has much less flexibility in SE process, tools, and practices in this model than the other two.

Any single business or enterprise is likely to apply some combination of these three models with varying importance given to one or more of them.

Organizations That Use and Provide SE

There are five basic types of organizations that use SE or provide SE services:

1. A business with multiple project teams
2. A project that spans multiple businesses
3. An SE team within either of the above
4. A business with a single project team
5. An SE service supplier that offers a specific SE capability or service (tools, training, lifecycle process) to multiple clients, either as an external consultancy or as an internal SE function.

The kind of business determines the scope and diversity of SE across the organization. This is shown in abstract form in Figure 1, which illustrates the fundamental form of an extended enterprise. This also shows how organizational structure tends to match system structure.

Figure 1. Organization Coupling Diagram. (SEBoK Original (Adapted from Lawson 2010))

The problem owners are the people, communities, or organizations involved in and affected by the problem situation. They may be seeking to defend a country, to improve transportation links in a community, or to deal with an environmental challenge. The respondent system might be a new fighter aircraft, a new or improved transportation infrastructure, or a new low-emission electricity generation systems (respectively). The organizations responsible for the respondent systems would be the Air Force, transport operator or regulator, or electricity supply company. The prime role of these organizations would be to operate the systems of interest to deliver value to the problem owners. They might reasonably be expected to manage the entire system lifecycle.

This same concept is expanded in Figure 2.

Figure 2. Systems Enterprises and Organizations. (SEBoK Original)

Goals, Measures, and Alignment in a Business

The alignment of goals and measures within the business strongly affects the effectiveness of SE and the benefit delivered by SE to the business, and needs to be carefully understood:

• 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 provides a powerful technique for aligning purpose to customer value – provided the enterprise boundary is chosen correctly and considers the whole value stream (Womack and Jones 2003; Oppenheim et al. 2010).

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

• EIA 632 (ANSI/EIA 2003) advocates managing all the aspects required for the life cycle 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 six guiding principles for making systems that work: (1) debate, define, revise and pursue the purpose, (2) think holistic, (3) follow a systematic procedure, (4) be creative, (5) take account of the people, and (6) manage the project and the relationships.

• For organizations new to SE, the INCOSE UK Chapter has published a range of one-page guides on the subject, including Farncombe and Woodcock (2009a; 2009b).

Governance

SE governance is the process and practice through which a business puts in place the decision rights that enable SE to deliver as much business value as possible. Those rights may be codified in policy, implemented through the business structure, enforced through tools, and understood through measures of compliance and effectiveness.

SE governance in large businesses is often explicit and codified in policy. In small businesses, it is often tacit and simply understood in how the business works. One of the key implementation steps when a business defines its SE strategy is to establish its SE governance model, which should be tailored to the particular context in which the business operates and delivers value. Of course, in practice, this is often incremental and uneven, and subject to wide swings based on the current state of the business and the people occupying key management positions.

The term governance for development organizations was first popularized in reference to how Information Technology (IT) is overseen in businesses and enterprises (Weill and Ross 2006; Cantor and Sanders 2007). The recognition in the 1990s and the last decade that IT is a fundamental driver of performance and value for most corporations and government agencies led to the transformation of the Chief Information Officer (CIO) into a key senior manager.

Explicit governance of IT became important to enabling an enterprise to respond to new technology opportunities, emerging markets, new threats, and rapid delivery of new products and services. The term "governance" is now widely used to describe how SE is woven into an enterprise. Governance becomes especially challenging for complex projects in which there are high levels of uncertainty (Cantor 2006) or for system of systems projects in which responsibility for major decisions may be distributed over multiple organizations within an enterprise in which there is no single individual who is "in control" (see Systems of Systems (SoS)). Morgan and Liker (2006) describe the governance model for Toyota, which is one of the largest companies in the world.

SE governance establishes the framework and responsibility for managing issues such as design authority, funding and approvals, project initiation and termination, as well as the legal and regulatory framework in which the system will be developed and will operate. Governance includes the rationale and rules for why and how the enterprise policies, processes, methods and tools are tailored to the context. SE governance may also specify product and process measures, documentation standards, and technical reviews and audits.

The ways in which a team organizes to conduct SE activities either conform to policies established at the level above or are captured in that team’s own governance policies, processes, and practices. These policies cover the organizational context and goals, the responsibilities for governance, process, practices and product at the level of interest, and the freedom delegated to and governance and reporting obligations imposed on lower organizational levels. It is good practice to capture the assignment of people and their roles and responsibilities in the form of the Responsible, Accountable, Consult, Inform (RACI) matrix (PMI 2013) or something similar. Responsibility in large organizations can easily become diffused. Sommerville et. al. (2009, 515-529) discuss the relationship between information and responsibility, and describe methods to analyze 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 organizations responsible for developing or acquiring large complex systems, such as the US Department of Defense or the US Federal Aviation Administration, usually develop policies that describe governance of their SE activities and SE organizations. See DoD (2012) for the Department of Defense SE policies.

Government contracting typically brings additional regulation and oversight, driving a group to greater rigor, documentation, and specific practices in their SE governance. Development of systems or operating services that affect public safety or security is subject to constraints similar to those seen in government contracting. Think of the creation of medical devices or the operation of emergency response systems, air traffic management, or the nuclear industry. (See Jackson (2010) for example).

Governance models vary widely. For example, Linux, the greatest success of the open source community, has a governance model that is dramatically different than those of traditional businesses. Smith (2009) offers a cogent explanation of how decisions are made on what goes into the Linux kernel. All of the decision rights are completely transparent, posted on the Linux website, and have proven remarkably effective as they have evolved. The classic paper The Cathedral and The Bazaar by Eric Raymond (2000) provides great insight into the evolution of Linux governance and how Linus Torvalds responded to changing context and circumstances to keep Linux so successful in the marketplace with a governance model that was radically novel for its time.

The project management literature also contributes to the understanding of SE governance (see Systems Engineering and Project Management). For example, Shenhar and Dvir (2007) offer the "diamond model" for project management, which identifies four dimensions that should guide how development projects are managed: novelty, technology, complexity, and pace. Application of this model to SE governance would influence the available life cycle models for development projects and how those models are applied.

There are numerous examples of projects that went well or badly based in large part on the governance practiced by both the acquirer and the supplier organizations. Part 7 of the SEBoK has several examples, notably Singapore Water Management (went well) and FAA Advanced Automation System (AAS) (went not so well).

References

Works Cited

ANSI/EIA. 2003. Processes for Engineering a System. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA). ANSI/EIA 632‐1998.

Blockley, D. 2010. "The Importance of Being Process." Journal of Civil Engineering and Environmental Systems. 27(3).

Blockley, D. and Godfrey, P. 2000. Doing It Differently – Systems for Rethinking Construction. London, UK: Thomas Telford, Ltd.

Cantor, M. 2006. "Estimation Variance and Governance." In IBM developerWorks. Abstract accessed on April 24, 2013.

Cantor, M. and J.D. Sanders. 2007. "Operational IT Governance." In IBM developerWorks. Accessed on September 15, 2011. Available at http://www.ibm.com/developerworks/rational/library/may07/cantor_sanders/.

DoD. 2012. "Systems Engineering Policy". Accessed on August 4, 2012. Available at http://www.acq.osd.mil/se/pg/index.html.

Eisner, H. 2008. "Essentials of Project and Systems Engineering Management", 3rd ed. Hoboken, NJ, USA: John Wiley & Sons.

Elliott, C. et al. 2007. Creating Systems That Work – Principles of Engineering Systems for The 21st Century. London, UK: Royal Academy of Engineering. Accessed September 2, 2011. Available at http://www.raeng.org.uk/education/vps/pdf/RAE_Systems_Report.pdf.

Fasser, Y. and D. Brettner. 2002. Management for Quality in High-Technology Enterprises. Hoboken, NJ, USA: John Wiley & Sons-Interscience.

Farncombe, A. and H. Woodcock. 2009a. "Enabling Systems Engineering". Z-2 Guide, Issue 2.0. Somerset, UK: INCOSE UK Chapter. March, 2009. Accessed September 2, 2011. Available at http://www.incoseonline.org.uk/Documents/zGuides/Z2_Enabling_SE.pdf.

Farncombe, A. and H. Woodcock. 2009b. "Why Invest in Systems Engineering". Z-3 Guide, Issue 3.0. Somerset, UK: INCOSE UK Chapter. March 2009. Accessed September 2, 2011. Available at http://www.incoseonline.org.uk/Documents/zGuides/Z3_Why_invest_in_SE.pdf.

Jackson, S. 2010. Architecting Resilient Systems: Accident Avoidance and Survival and Recovery from Disruptions. Hoboken, NJ, USA: John Wiley & Sons.

Lawson, H. 2010. "A Journey Through the Systems Landscape". London, UK: College Publications, Kings College, UK.

MITRE. 2012. "Systems Engineering Guidebook". Accessed on August 4, 2012. Available at http://www.mitre.org/work/systems_engineering/guide/index.html.

Morgan, J. and J. Liker. 2006. The Toyota Product Development System: Integrating People, Process and Technology. New York, NY, USA: Productivity Press.

NASA. 2007. "NASA Systems Engineering Handbook". Accessed on April 24, 2013. Available at http://www.acq.osd.mil/se/docs/NASA-SP-2007-6105-Rev-1-Final-31Dec2007.pdf. Washington, DC, USA: NASA.

Northrop, L., P. Clements, et. al. 2007. A Framework for Software Product Line Practice, Version 5.0. With F. Bachmann, J. Bergey, G. Chastek, S. Cohen, P. Donohoe, L. Jones, R. Krut, R. Little, J. McGregor, and L. O'Brien. Pittsburgh, PA, USA: Software Engineering Institute.

Oppenheim, B., E.M. Murman, D.A. Secor. 2010. Lean Enablers for Systems Engineering. Systems Engineering. 14(1): 29-55.

PMI. 2013. A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5th ed. Newtown Square, PA, USA: Project Management Institute (PMI).

Raymond, E.S. 2000. The Cathedral and The Bazaar, version 3.0. Accessed on April 24, 2013. Available at http://www.catb.org/esr/writings/homesteading/cathedral-bazaar/cathedral-bazaar.ps.

Rouse, W. 2006. "Enterprise Transformation: Understanding and Enabling Fundamental Change." Hoboken, NJ, USA: John Wiley & Sons.

Shenhar, A.J. and D. Dvir. 2007. Reinventing Project Management: The Diamond Approach to Successful Growth and Innovation. Boston, MA, USA: Harvard Business School Publishing.

Sillitto, H. 1999. “Simple Simon Met A System”. Proceedings of the 9th Annual International Council on Systems Engineering (INCOSE) International Symposium, 6-10 June, 1999, Brighton, UK.

Simpson, T.W., Z. Siddique, R.J. Jiao (eds.). 2006. Product Platform and Product Family Design: Methods and Applications. New York, NY, USA: Springer Science & Business Media, Inc.

Smith, J.T. 2009. "2.4 Kernel: How are Decisions Made on What Goes into The Kernel?" Available at http://www.linux.com/feature/8090.

Smith, P.G. and D.G. Reinertsen. 1997. Developing Products in Half the Time. New York, NY, USA: Wiley and Sons.

Sommerville, I., R. Lock, T. Storer, and J.E. Dobson. 2009. "Deriving Information Requirements from Responsibility Models." Paper presented at 21st International Conference on Advanced Information Systems Engineering, Amsterdam, Netherlands.

Weill, P. and J.W. Ross. 2004. IT Governance: How Top Performers Manage IT Decision Rights for Superior Results. Boston, MA, USA: Harvard Business School Publishing.Pugh, S. 1991. Total Design: Integrated Methods for Successful Product Engineering. New York, NY, USA: Addison-Wesley.

Womack, J. and D. Jones. 2003. Lean Thinking: Banish Waste and Create Wealth in Your Corporation, Revised Edition. New York, NY, USA: Simon & Schuster.

Primary References

Blockley, D. and Godfrey, P. 2000. Doing It Differently – Systems for Rethinking Construction. London, UK: Thomas Telford, Ltd.

Cantor, M. and J.D. Sanders. 2007. "Operational IT Governance." In IBM developerWorks. Accessed on September 15, 2011. Available at http://www.ibm.com/developerworks/rational/library/may07/cantor_sanders/.

Eisner, H. 2008. Essentials of Project and Systems Engineering Management, 3rd ed. Hoboken, NJ, USA: John Wiley & Sons.

Elliott, C., et al. 2007. Creating Systems That Work – Principles of Engineering Systems for The 21st Century. London, UK: Royal Academy of Engineering. Accessed September 2, 2011. Available at http://www.raeng.org.uk/education/vps/pdf/RAE_Systems_Report.pdf.

Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College, UK.

Morgan, J. and J. Liker. 2006. The Toyota Product Development System: Integrating People, Process and Technology. New York, NY, USA: Productivity Press.

Northrop, L., P. Clements, et al. 2007. A Framework for Software Product Line Practice, version 5.0. With F. Bachmann, J. Bergey, G. Chastek, S. Cohen, P. Donohoe, L. Jones, R. Krut, R. Little, J. McGregor, and L. O'Brien. Pittsburgh, PA, USA: Software Engineering Institute. Accessed on April 25, 2013. Available at http://www.sei.cmu.edu/productlines/frame_report/index.html.

Rouse, W. 2006. Enterprise Transformation: Understanding and Enabling Fundamental Change. Hoboken, NJ, USA: John Wiley & Sons.

Shenhar, A.J. and D. Dvir. 2007. Reinventing Project Management: The Diamond Approach to Successful Growth and Innovation. Boston, MA, USA: Harvard Business School Publishing.

Additional References

Chastek, D., P. Donohoe, and J.D. Mcgregor. 2009. Formulation of a Production Strategy for a Software Product Line. Pittsburgh, PA, USA: Software Engineering Institute, CMU/SEI-2009-TN-025. Accessed on September 14, 2011. Available at http://www.sei.cmu.edu/reports/09tn025.pdf.

Sillitto, Mazzella, and Fromenteau. 2001. "The development of Product Lines in THALES: methods, examples, lessons learnt," Paper presented at the INCOSE UK Spring Conference.

---

< Previous Article | Parent Article | Next Article > SEBoK v. 2.1, released 31 October 2019