Organizing Business and Enterprises to Perform Systems Engineering

To enable a business or enterprise to perform systems engineering (SE) well requires deciding which specific SE capabilities the business or enterprise needs in order to be successful and then organizing to deliver those capabilities. (In the rest of this article, business or enterprise is usually abbreviated to just "business" because a business is a specific type of enterprise that has sufficiently strong central authority and motivation to take steps to enable SE). SE capabilities and organizational approach should support the Systems Engineering Organizational Strategy and reflect the nature of the business, its products and services, various stakeholders, business leadership focus, etc. This topic, which is part of Part 5, Enabling Businesses and Enterprises, summarizes the factors used to organize a business to perform SE.

Components of Business and Enterprise SE Capability

Organization issues - culture, knowledge, information and infrastructure

The way SE is managed is descibed in Systems Engineering Organizational Strategy, which both impacts and responds to the SE Culture and approach.

Knowledge and Information

Knowledge and Information are key assets in a business, and their management is critical. Fasser and Brettner (2002) discuss knowledge management extensively. They assert that “we may think that knowledge transfer is just an information technology issue, but in actuality, it is also a psychological, cultural, and managerial issue – in short a human issue”; and “only information in action can create knowledge”. Organizations need to manage SE know-how, integration of SE with other organizational processes and activities, and knowledge of their business domain. The INCOSE Intelligent Enterprise Working Group's work on knowledge management in an SE context led to the publication of a “Concept of Operations for a Systems Engineering Educational Community” (Ring et al. 2004).

Information has to be both shared and protected in complex organizations. Sharing is key to effective collaboration and is constrained by the need to protect intellectual property and commercially and nationally sensitive material. Different cultures and personal styles make best use of information presented in different ways and in different orders (i.e. in levels of abstraction, big picture first or detail, principles first or practical examples). Sillitto (2011b) describes the knowledge management challenges for large multi-national organizations.

Projects need to manage project information and establish configuration control over formal contractual information; and the information that defines the product/service being developed, supplied, or operated. A key role of systems engineers is to “language the project” (Ring et al. 2004). Good data management and tool support will allow people to “document once, use many times”; and ensure consistency of information over time and between different teams.

System information needs to be maintained throughout the life of the system and made available to relevant stakeholders – including those designing new systems that have to interface to the system of interest - to allow system management, maintenance, reconfiguration, upgrade and disposal, and forensics after accidents and near-misses. Elliott et al. (2008) suggest that information management is the dominant problem in SE in service systems; and that the cost and difficulty of establishing “current state” and legacy constraints before starting to implement a change is often underestimated.

"Infostructure" (information infrastructure) to support the system lifecycle will include the following:

• Information assets such as process libraries, document templates, preferred parts lists, component re-use libraries, as-specified and as-tested information about legacy systems, capitalized metrics for organizational performance on previous similar projects, all with appropriate configuration control
• Modeling and simulation tools, data sets and run-time environments
• Shared working environments – workspaces for co-located teams, areas for people to interact with each other to develop ideas and explore concepts, work areas suitable for analysis tasks, meeting rooms, access control provision, etc.
• IT facilities - computer file structures, software licenses, IT equipment, computer and wall displays to support collaborative working, printers, all with appropriate security provision and back-up facilities, procedures for efficient use, and acceptable performance and usability
• Security provisions to protect own, customer, supplier and third part IPR and enforce necessary protective working practices while allowing efficient access to information for those with a need to know

SE is a knowledge activity and systems engineers need appropriate facilities for accessing, sharing and capturing knowledge and for interacting effectively with the whole set of stakeholders. Warfield (2006) describes collaborative workspaces, and environments and processes for developing a shared understanding of a problem situation.

Enabling Infrastructure

The ISO/IEC 15288 (ISO 2008) Infrastructure Management Process provides the enabling infrastructure and services to support organization and project objectives throughout the life cycle. Infrastructure to support the system life cycle will often include the following:

• Integration and test environment – bench and lab facilities, facilities for development testing as well as acceptance testing at various levels of integration, calibration and configuration management of test environment
• Trials and validation environment – access to test ranges, test tracks, calibrated targets, support and storage for trials-equipment, harbor, airfield and road facilities, safe storage for fuel, ordnance, etc.
• Training and support infrastructure – training simulators, embedded training, tools and test equipment for operational support and maintenance, etc.

People

The roles people fill are typically defined by the business/enterprise (see Determining Needed Systems Engineering Capabilities in Businesses and Enterprises), although those decisions may be pushed down to teams. Enabling Teams explains how people are used in teams; and Enabling Individuals describes the development of an individual's SE competence.

The implementation of these roles needs further consideration. Sheard (1996) lists twelve system engineering roles. 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. Sillitto (2011a) discusses a number of SE roles and the characteristics required of them, in the context of the wider engineering and business professional landscape.

Systems engineering exists within an enterprise “ecosystem”. Two key aspects to consider:

• How much should the business/enterprise nurture and value the systems engineer?
• How much should the business/enterprise pull value from systems engineers, rather than wait for systems engineers to "push" value on the business/enterprise.

Process

Many SE organizations maintain a set of organizational standard processes, integrated in their quality and business management system, adapted to their business, and with tailoring guidelines to help projects apply the standard processes to their unique circumstances. Guidance on organizational process management is provided by such frameworks as the Capability Maturity Model Integration (CMMI) (SEI 2010) which has two process areas on organizational process: Organizational Process Development (OPD), concerned with organizational definition and tailoring of the SE lifecycle processes discussed in detail elsewhere in this document; and Organizational Process Focus (OPF), concerned with establishing a process culture in an organization.

To document, assess, and improve SE processes, businesses often establish a systems engineering process group. Members of such groups often create standard process assets, may mentor teams and business units on how to adopt those standard processes and assess how effective those processes are working. There is a large body of literature on SE process improvement based on various process improvement models. Two of the most popular are ISO 9000 and CMMI.

Assessment and measure performance of performance is covered in Assessing Systems Engineering Performance of Business and Enterprises.

Tools and Methods

SE organizations often invest in SE tools and models, developing their own, and/or integrating off-the-shelf tools into their particular business/enterprise processes. Tools require great attention to culture and training, to developing a consistent “style” of use so that people can understand each others’ work, and configuration manage the information so that people are working on common and correct information. It is important that as well as tools there are methods, particularly to support Systems Thinking.

It is common practice in large SE organizations to have a tool support infrastructure which ensures that tools support the organizational standard processes and are fully integrated with training, and that projects and teams can use the tools to do their job and are not distracted by tool management issues that are more efficiently handled centrally. Smaller SE organizations often operate more informally.

Fitting it All Together

The concept map in Figure 1 below shows the relationships between the various aspects of organization, resource, responsibility and governance.

Figure 1. Businesses, Teams, and Individuals in SE. (SEBoK Original)

Enterprise Structures and their Effects on SE

Enterprises manage SE resources 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 and the enterprise as a whole. Five common ways of organizing resources to support multiple projects are: project, matrix, functional, integrated, and product centered (CM Guide 2009; Handy 1985; PMI 2008, section 2.4). A large enterprise would likely apply some combination of these five ways across its constituent sub-enterprises and teams. Browning (2009) offers a way to optimize project organizational structure. Eisner (2008) offers a good overview of different organizational models.

Project Organization

A project organization is one extreme in which projects are responsible for hiring, training, and terminating staff, as well as managing all assets required for delivery. In this model, systems engineers on a project report to the project manager and resources are optimized for the delivery of the project. This model has the advantage of strongly aligning the authority and responsibility of the project with the project manager. However, it operates at the expense of sub-optimizing how the staff is deployed across the larger enterprise, how technology choices are made across projects, etc. Systems Engineering Fundamentals (DAU 2001) offers a DoD view of good practice project organizations.

Functional Organization

A functional organization demonstrates the opposite extreme. In a functional organization, projects delegate almost all their work to functional groups, such as the software group or the radar group or the communications group. This is appropriate when the functional skill is fast-evolving and dependent on complex infrastructure. This method is often used for manufacturing, test engineering, software development, financial, purchasing, commercial, and legal functions.

Matrix Organization

Very often a matrix organization is used to give systems engineers a “home” between project assignments. Typically, a SE functional lead is responsible for career development of the systems engineers in the organization, a factor that influences the diversity and length of individual project assignments.

Integrated Organization

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

Product Centered Organization

In accordance with the heuristic that “the product and the process must match” (Rechtin 1991, 132), a common method for creating an organizational structure is to make it match the system breakdown structure (sbs) . According to Browning (2009), at each element of the SBS, there is an assigned integrated product team (ipt). Each IPT consists of members of the technical disciplines necessary to design the product system. The purpose of the IPT is to assure that the interactions among all the technical disciplines are accounted for in the design and that undesirable interactions are avoided.

Interface to Other Organizations

Outside official engineering and SE organizations within an enterprise, there are other organizations whose charter is not technical. Nevertheless, these organizations have an important SE role. Following are some examples:

• Customer Interface Organizations: There are organizations with titles such as Marketing and Customer Engineering. These are the organizations with the most direct interface with customers or potential customers. Their role is to determine customer needs and communicate these needs to the SE organization for conversion to product requirements and other system requirements. Kossiakoff and Sweet (2003, 173) discuss the importance of understanding customer needs.

• Contracts Organizations: These organizations interface with both customer and supplier organizations. Their role is to develop clearly stated contracts for the developer or the supplier. These contracts convey tasks and responsibilities for all SE roles of all parties. Technical specifications are attached to the contracts. Responsibilities for verification and validation are specified.

• Supplier Management Organizations: These organizations are responsible for selecting and managing suppliers and assuring that both contractual and technical products are in place. These organizations balance cost and risk to assure that supplier products are delivered, verified, and validated to assure quality products. Blanchard and Fabrycky (2005, 696-698) discuss the importance of supplier selection and agreement.

References

Works Cited

Blanchard, B. and W. Fabrycky. 2005. Systems Engineering and Analysis, 4th edition. Upper Saddle River, NJ, USA: Prentice Hall.

Browning, T.R. 2009. “Using the Design Structure Matrix to Design Program Organizations.” In Sage, A.P. and W.B. Rouse (eds.), Handbook of Systems Engineering and Management, 2nd ed. Hoboken, NJ, USA: John Wiley & Sons.

CM Guide. 2009. Construction Management Guide. Project Organization Types. Accessed on September 14, 2011. Available at http://cmguide.org/archives/319.

DAU. 2001. Systems Engineering Fundamentals. Ft. Belvoir, VA, USA: Defense Acquisition University (DAU), US Department of Defense (DoD). Accessed on September 14, 2011. Available at http://www.dau.mil/pubscats/PubsCats/SEFGuide%2001-01.pdf.

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

Elliott et al. 2008. INCOSE UK Chapter Working Group on Applying Systems Engineering to In-Service Systems, Final Report. Somerset, UK: INCOSE UK Chapter Working Group. Accessed September 6, 2011. Available at http://www.incoseonline.org.uk/Documents/Groups/InServiceSystems/is_tr_001_final_report_final_1_0.pdf.

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

ISO/IEC 2008. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008.

Kasser, J., D. Hitchins, and T. Huynh. 2009. Re-engineering Systems Engineering. Proceedings of the 3rd Annual Asia-Pacific Conference on Systems Engineering (APCOSE). 20-23 July 2009. Singapore.

Kossiakoff, A., and W.N. Sweet. 2003. Systems Engineering: Principles and Practice. Edited by A. Sage, Wiley Series in Systems Engineering and Management. Hoboken, NJ: John Wiley & Sons.

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

Rechtin, E. 1991. Systems Architecting: Creating and Building Complex Systems. Englewood Cliffs, NJ, USA: CRC Press.

Ring, J. and A.W. Wymore (eds.) 2004. Concept of Operations (conops) of A Systems Engineering Education Community (SEEC). Seattle, WA, USA: INCOSE Education Measurement Working Group (EMWG), INCOSE-TP-2003-015-01. Accessed on September 14, 2011. Available at http://www.incose.org/ProductsPubs/PDF/ConopsOfAnSEEdCommunity_2004-0315.pdf.

SEI. 2010. Capability Maturity Model Integrated (CMMI) for Development, version 1.3. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU).

Sheard, S. 1996. "12 Systems Engineering Roles." Paper presented at the Sixth Annual International Council on Systems Engineering (INCOSE) International Symposium. 7-11 July 1996. Boston, MA, USA. Accessed on September 6, 2011. Available at: http://www.incose.org/educationcareers/PDF/12-roles.pdf.

Sheard, S. 2000. "The 12 Systems Engineering Roles Revisited." Paper presented at the INCOSE Mid-Atlantic Regional Conference. April 2000. Reston, VA, USA. p 5.2-1 - 5.2-9.

Sillitto, H. 2011a. "Unravelling Systems Engineers from Systems Engineering - Frameworks for Understanding the Extent, Variety and Ambiguity of Systems Engineering and Systems Engineers." Paper presented at the 21st Annual International Council on Systems Engineering (INCOSE) International Symposium. 20-23 June 2011. Denver, CO, USA.

Sillitto, H. 2011b. "Sharing Systems Engineering Knowledge through INCOSE: INCOSE as An Ultra-Large-Scale System? INCOSE Insight. 14(1) (April): 20.

Warfield, J. 2006. An Introduction to Systems Science. Washington, D.C., USA: The National Academies Press, World Scientific.

Primary References

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

Kotter, J. 1995. Leading Change: Why Transformation Efforts Fail. Boston, MA, USA: Harvard Business Review (March–April 1995).

Sheard, S. 2000. "Systems Engineering Roles Revisited." Paper presented at the INCOSE Mid-Atlantic Regional Conference. April 5-8 2000. Reston, VA, USA. p 5.2-1 - 5.2-9.

Additional References

Blanchard, B. and W. Fabrycky. 2005. Systems Engineering and Analysis, 4th edition. Upper Saddle River, NJ, USA: Prentice Hall.

Construction Management (CM) Guide. 2009. Project Organization Types. Accessed on September 6, 2011. Available at http://cmguide.org/archives/319.

Defense Acquisition University (DAU). 2001. Systems Engineering Fundamentals. Fort Belvoir, VA, USA: Defense Acquisition University Press. Accessed on September 6, 2011. Available at http://www.dau.mil/pubscats/PubsCats/SEFGuide%2001-01.pdf.

Handy, C.B. 1985. Understanding Organizations. London, UK: Penguin Business.

---

< Previous Article | Parent Article | Next Article >

SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.

If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.

blog comments powered by Disqus