Difference between revisions of "Organizing Business and Enterprises to Perform Systems Engineering"

From SEBoK
Jump to navigation Jump to search
m (Text replacement - "SEBoK v. 2.9, released 13 November 2023" to "SEBoK v. 2.9, released 20 November 2023")
 
(171 intermediate revisions by 14 users not shown)
Line 1: Line 1:
−
Each organization 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.  A standard way of describing the capabilities needed is based on the Toyota (Morgan and Liker 2006) approach of considering people, processes and tools. This division is used to structure this topic, with the addition of some specific issues about SE and the enabling organization.
+
----
 +
'''''Lead Authors:''''' ''Richard Beasley, Art Pyster, Hillary Sillitto'', '''''Contributing Authors:''''' ''Alice Squires, Heidi Davidz, Scott Jackson, Quong Wang''
 +
----
 +
In order for a {{Term|Business (glossary)|business}} or {{Term|Enterprise (glossary)|enterprise}} to perform {{Term|Systems Engineering (glossary)|systems engineering}} (SE) well, the team must decide 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 described in [[Systems Engineering Organizational Strategy]], which both impacts and responds to the SE [[Culture|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, as well as commercially and nationally sensitive material. Different cultures and personal styles use information in different ways and in different orders. (Levels of abstraction, big picture first or detail, principles first or practical examples, etc.) 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, as well as 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 ensures consistency of information over time and between different teams.
  
−
==Components of business and enterprise SE capability==
+
System information needs to be maintained throughout the life of the system and made available to relevant stakeholders – including those designing new systems that must 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.
  
−
=== Governance of Systems engineering ===
+
"Infostructure" (information infrastructure) to support the system lifecycle will include the following:
−
[[Systems Engineering 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.
+
*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 party IPR and enforce necessary protective working practices while allowing efficient access to information for those with a need to know
  
−
=== Definition of Roles ===
+
SE is a knowledge activity. Systems engineers need appropriate facilities for accessing, sharing and capturing knowledge, as well as for interacting effectively with the whole set of stakeholders.  Warfield (2006) describes collaborative workspaces, environments and processes for developing a shared understanding of a problem situation.
−
Systems engineering organizations need to establish a career structure for people management to cover three key issues for business success: how people are recruited, trained, allocated, supervised, promoted, and rewarded; how to optimize use of expertise, across projects and business units; and how to develop SE skills.
 
  
−
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 systems engineering roles and the characteristics required of them, in the context of the wider engineering and business professional landscape.
+
=== Enabling Infrastructure ===
  
−
Systems engineering exists within an enterprise “ecosystem”. There are two key points to consider:
+
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:  
  
−
*Nurture and value the systems engineer.  Doing systems engineering well is 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).
+
*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 environments
−
*The organization must “pull” value from the systems engineering, rather than the systems engineers “push”.
+
*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, ordinance, etc.  
 +
*Training and support infrastructure – training simulators, embedded training, tools and test equipment for operational support and maintenance, etc.
  
 
=== People ===
 
=== People ===
−
The roles people fill are defined by the organization (see Definition of Roles subtopic above); the way people are used in teams is described in [[Enabling Teams to Perform Systems Engineering]]; and the development of individuals' SE competence is described in [[Enabling Individuals to Perform Systems Engineering]]. The key point to recognize here is that the roles, and the systems engineering competencies required in those roles, need to be defined at the organizational level.
+
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; [[Enabling Individuals]] describes the development of an individual's SE competence.
  
−
=== Knowledge and information===
+
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.
  
−
There are two kinds of knowledge: explicit and tacit. Explicit knowledge can be written down or incorporated in computer codes, and can be treated as an asset. Much knowledge is tacit.  Tacit knowledge only exists within the heads of people and in the context of relationships that people form with each other. So the ability of an organization to create value is critically dependent on the people it chooses to employ, what they know, how they work together, and how well they are organized and motivated to contribute to the organization’s purpose.
+
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?
  
−
Fasser & Brettner (2002) discuss knowledge management extensively and emphasize the value of numerous mechanisms for informal knowledge transfer. 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”.
+
=== Process ===
  
−
A “learning organization” aims to absorb, diffuse, generate, and exploit knowledge (Sprenger and Have 1996). Organizations need to manage formal information and facilitate the growth and exploitation of tacit knowledge. They should learn from experience and create a form of “corporate memory” – including process, problem domain and solution space knowledge, and information about existing products and services. (Fassner and Brettner 2002, 122-124) suggest that “shared mental models” are a key aspect of corporate knowledge and culture.
+
Many SE organizations maintain a set of organizational standard processes which are integrated in their quality and business management system, adapted to their business, and with tailoring guidelines used 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) is concerned with organizational definition and tailoring of the SE lifecycle processes (discussed in detail elsewhere in this document) and Organizational Process Focus (OPF), which is concerned with establishing a process culture in an organization.
  
−
Organizations need to manage SE know-how, integration of SE with other organizational processes and activities, and knowledge of their business domain. Typical strategies include internal networks of SE leaders, experts, practitioners, reviewers, trainers, assessors; links from knowledge to organizational training and people development; and IT “Infostructure” to facilitate distributed working and cross-site collaboration. The INCOSE Intelligent Enterprise Working Group did a lot of work on knowledge management in an SE context, producing a “Concept of Operations for a Systems Engineering Educational Community” (Ring et al. 2004)
+
To document, assess, and improve SE processes, businesses often establish a systems engineering process group. Members of such groups often create standard process assets and 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/IEC 9000 (2000) and CMMI (SEI 2010).  The Software Engineering Institute, which created the CMMI, offers many free technical reports and other documents on CMMI at http://www.sei.cmu.edu/cmmi.
  
−
Information has to be both shared and protected in complex organizations. Sharing is key to effective collaboration; it 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.
+
Assessment and measuring process performance is covered in [[Assessing Systems Engineering Performance of Business and Enterprises]].
  
−
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.
+
=== Tools and Methods ===
  
−
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. Elliot et al. (2008) suggest that information management is the dominant problem in systems engineering for 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.
+
SE organizations often invest in SE tools and models, develop their own, and/or integrate 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 proper configuration and management of the information so that people are working on common and correct information.
  
−
===Managing Organizations in a High-Risk Environment===
+
It is important that methods are used as well as tools, particularly to support [[Systems Thinking]].
  
−
Many industrial domains are subject to catastrophic events. Special managerial skills are required to manage these organizations and minimize these events. Organizations that possess these skills are called [[High Reliability Organizations (HROs)(glossary)]], a term coined by Weick and Sutcliffe (2001, p. 3). [[HROs (acronym)]] are “organizations that operate under trying conditions and have fewer than their fair share of accidents.” Example HROs include “power grid dispatching centers, air traffic control systems, nuclear aircraft carriers, nuclear power generation plants, hospital emergency departments, and hostage negotiation teams.”
+
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.
−
Weick and Sutcliffe (Weick and Sutcliffe, 2001, p. 10) identify five hallmarks of HROs:
 
  
−
====Preoccupation with failure====
+
== Fitting It All Together ==
 +
The concept map in Figure 1 below shows the relationships between the various aspects of organization, resource, responsibility, and governance.
  
−
[[HROs (acronym)]] do not ignore errors, large or small. They encourage reporting of errors. They learn from near misses. They avoid complacency. They avoid the temptation to reduce margins of safety.
+
[[File:Part_5_(Organization)_Concept_maps_additions_hgs_15_Aug.png|thumb|center|750px|'''Figure 1. Businesses, Teams, and Individuals in SE.''' (SEBoK Original)]]
  
−
====Reluctance to simplify interpretations====
+
== 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 across 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 2013, section 2.1.3). 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.
  
−
[[HROs (acronym)]] simplify less and see more. They position themselves to see as much as possible. They “encourage skepticism towards received wisdom.” They pay attention to the nuances that diverse people detect.
+
===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.
  
−
====Sensitivity to operations====
+
===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, 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.
  
−
[[HROs (acronym)]]pay attention to possible latent conditions, defined by James Reason (Reason, 1997) to be deficiencies in the system that have not yet resulted in an accident but are waiting to happen. They have well developed situational awareness and make continuous adjustments to keep errors from accumulating and enlarging.
+
===Matrix Organization===
−
   
+
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.
−
====Commitment to [[resilience]]====
+
===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.
  
−
[[HROs (acronym)]] keep errors small and improvise “workarounds that keep the system functioning.” They have a deep understanding of the technology and constantly create worst case situations to make corrections.
+
=== Product Centered Organization ===
 
   
 
   
−
====Deference to expertise====
+
In accordance with the {{Term|Heuristic (glossary)|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 {{Term|System Breakdown Structure (glossary)|system breakdown structure (SBS)}}. According to Browning (2009), at each element of the SBS there is an assigned {{Term|Integrated Product Team (IPT) (glossary)|integrated product team (IPT)}}. Each IPT consists of members of the technical disciplines needed 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.
−
[[HROs (acronym)]] “push decision making down.” Decisions are made “on the front line.” They avoid rigid hierarchies and go directly to the person with the expertise.
 
  
−
=== Process ===
+
=== 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.
 +
 
 +
*'''Customer Interface Organizations:''' These are organizations with titles such as Marketing and Customer Engineering. They have the most direct interface with current or potential clientele. 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 for quality product.  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 ed. Upper Saddle River, NJ, USA: Prentice Hall.
 +
 
 +
Browning, T.R. 2009. "Using the Design Structure Matrix to Design Program Organizations." In A.P. Sage and W.B. Rouse (eds.), ''Handbook of Systems Engineering and Management,'' 2nd ed. Hoboken, NJ, USA: John Wiley & Sons.
 +
 
 +
Construction Management (CM) Guide. 2009. ''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), U.S. 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 & Sons.
  
−
Most systems engineering 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.  
+
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.
−
This is supported by a process group who develop and maintain the process assets, and support their deployment into business units and projects.  
 
−
Guidance on organizational process management is provided by Capability Maturity Model Integration (CMMI) (SEI 2010) which has two process areas on organizational process: OPD (Organizational Process Development), which is concerned with organizational definition and tailoring of the SE lifecycle processes discussed in detail elsewhere in this document; and OPF (Organizational Process Focus) which is concerned with establishing a process culture in an organization.
 
  
−
Systems engineering performance should be assessed and measured at organizational level (see [[Assessing Systems Engineering Performance of Business and Enterprises]]). SE performance should be evaluated as to how well it 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). It may be necessary to sub-optimize the systems engineering aspects in order to optimize the performance of the whole enterprise. SE measurement to date has focused more on measuring SE than on measuring the benefits SE delivers to the business.  
+
Fasser, Y. and D. Brettner. 2002. ''Management for Quality in High-Technology Enterprises''. Hoboken, NJ, USA: John Wiley & Sons.
  
−
CMMI also provides a means to measure performance of systems engineering projects. The Organizational Process Performance (OPP) process area provides guidance on managing process performance at an organizational level. Consistent process measurement across the business allows the development and calibration of parametric estimating models that improve the predictability of systems engineering projects. Leading indicators should be monitored at the organizational level to help direct support to projects or teams heading for trouble. For example, the INCOSE Leading Indicators (INCOSE 2010) provide a set that is useful at project level. Lean Sigma provides a tool for assessing benefit delivery throughout an enterprise value stream. Lean Enablers for Systems Engineering are now being developed (Oppenheim et al. 2010). An emerging good practice is to use Lean Value Stream Mapping to aid the optimisation of project plans and process application.
+
ISO/IEC. 2000. ''International standards for quality management.'' Genève, Switzerland: International Organization for Standardization. ISO 9000:2000.
  
−
=== Tools, models and "infostructure" ===
+
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.
  
−
Most SE organizations invest in SE tools and models, developing their own, and/or integrating off-the-shelf tools into their optimized processes. Tools are an essential part of the support for systems engineering. Conversely, risks with tools include the possibility that they may “lock in” inefficient and counterintuitive processes, fail to manage exceptions properly, and force people to service the tool instead of the tool serving the people. Tools require great attention to culture and training, to developing a consistent “style” of use so that people can understand each others’ work, and to configuration management of the information so that people are working on common and correct information.
+
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.
  
−
Tools and facilities to support the SE processes may include customer domain tools, e.g. Synthetic Environment; product domain tools, e.g. whole system models, specific models for critical functions; and domain-independent SE tools - requirements, architecture modelling, TPM tracking, SE metrics, configuration management etc.  
+
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.
  
−
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.  
+
PMI. 2013. ''[[A Guide to the Project Management Body of Knowledge|A Guide to the Project Management Body of Knowledge (PMBOK® Guide)]]'', 5th ed. Newtown Square, PA, USA: Project Management Institute (PMI).
  
−
"Infostructure" (information infrastructure) to support the system lifecycle will include:  
+
Rechtin, E. 1991. ''Systems Architecting: Creating and Building Complex Systems.'' Englewood Cliffs, NJ, USA: CRC Press.
−
*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 provision to protect own, customer, supplier and third party IPR and enforce necessary protective working practices while allowing efficient access to information for those with a need to know
 
  
−
Systems engineering 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. Often a systems engineer will need to “move into their world” to deal effectively with stakeholders. So visiting customer sites, using simulation facilities, etc, are important ways to engage with and understand operational and customer communities. Even such simple things as putting photographs of the operational systems and environment up on the walls can help to establish a common understanding that that leads to effective communication. (Warfield, 2006) describes collaborative workspaces, and environments and processes for developing a shared understanding of a problem situation.
+
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.  
  
−
=== Enabling infrastructure ===
+
SEI. 2010. ''Capability Maturity Model Integrated (CMMI) for Development,'' version 1.3. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU).
  
−
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 lifecycle will include:
+
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.
  
−
*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
+
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.
−
*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.
 
  
−
== Fitting it all together ==
+
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.
−
The concept map (below) shows the relationships between the various aspects of organization, resource, responsibility and governance.
 
  
−
[[File:Businesses,_teams_and_individuals_in_SE.png|1000px|Businesses, Teams and Individuals in SE]]
+
Sillitto, H. 2011b. ''Sharing Systems Engineering Knowledge through INCOSE: INCOSE as An Ultra-Large-Scale System?'' INCOSE ''Insight.'' 14(1) (April): 20.  
  
−
==References==
+
Warfield, J. 2006. ''An Introduction to Systems Science''. Washington, DC, USA:  The National Academies Press, World Scientific.
−
===Citations===
 
−
*Elliott et al, 2008 - In-Service Systems Engineering report, INCOSE UK Chapter in-service systems working group (HGS to confirm details of citation)
 
−
*Fasser, Yefim and D. Brettner.  2002. Management for Quality in High-Technology Enterprises.  Wiley
 
−
*System Engineering Leading Indicators Guide, Version 2.0, January 29, 2010, Editors: Garry Roedler, Lockheed Martin Corporation, Donna H. Rhodes, Massachusetts Institute of Technology, Howard Schimmoller, Lockheed Martin Corporation, Cheryl Jones, US Army. Published jointly by LAI, SEARI, INCOSE, PSM
 
−
*ISO/IEC.  2008.  ISO / IEC 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), Singapore, 2009.
 
−
*Morgan, J. and J. Liker.  2006. The Toyota Product Development System: Integrating People, Process and Technology.  Productivity Press.
 
−
*Oppenheim et al. 2010. INCOSE Lean SE WG. Lean Enablers for Systems Engineering.  Available at, <http://cse.lmu.edu/about/graduateeducation/systemsengineering/INCOSE.htm>.
 
−
*PMI. 2008. Project Management Body of Knowledge. 4th edition. ANSI/PMI 99-001-2008.
 
−
*Reason, J. 1997. Managing the Risks of Organisational Accidents. Aldershot, UK, Ashgate Publishing Limited.
 
−
*Ring, J. & Wymore, A. W. 2004. INCOSE-TP-2003-015-01: Concept of operations (conops) of a systems engineering education community (SEEC). INCOSE  INCOSE Intelligent Engineering Working Group, E&R TC Report. See: 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.  INCOSE 6th Annual Symposium, Boston. Available at,    http://www.incose.org/educationcareers/PDF/12-roles.pdf
 
−
*Sheard, S. 2000. The 12 Systems Engineering Roles Revisited.” Proceedings of the INCOSE Mid-Atlantic Regional Conference, April 2000, pp 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." INCOSE International Symposium, Denver, June 2011.
 
−
*Sillitto, H. 2011b. Sharing Systems Engineering Knowledge through INCOSE: INCOSE as an Ultra-Large-Scale System? INCOSE Insight, Page 20 Vol 14 Issue 1, April 2011
 
−
*Sprenger, C. and Have, S. Ten. 1996.  4 Competencies of a Learning Organisation. ‘Kennismanagement als moter van delerende organisatie’, Holland Management Review, Sept–Oct, pp. 73–89.
 
−
*Warfield, J, 2006; “An introduction to systems science”, World Scientific, 2006
 
−
*Weick, K. E. and K. M. Sutcliffe.  2001. Managing the Unexpected: Assuring High Performance in an Age of Complexity. San Francisco, Jossey-Bass.
 
  
 
===Primary References===
 
===Primary References===
−
None.
+
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''." ''Harvard Business Review''. 73(2): 59–67.''
 +
 
 +
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===
 
===Additional References===
−
*Blanchard, B. and W. Fabrycky. 2005. Systems Engineering and Analysis. 4th edition. Prentice-Hall International.
+
Blanchard, B. and W. Fabrycky. 2005. ''Systems Engineering and Analysis,'' 4th edition. Upper Saddle River, NJ, USA: Prentice Hall.
−
*CM Guide. 2009. Construction Management Guide. Project Organization Types.  Available at, <http://cmguide.org/archives/319>.
+
 
−
*Defense Acquisition University (DAU). 2001. Systems Engineering Fundamentals. Available at, <http://www.dau.mil/pubscats/PubsCats/SEFGuide%2001-01.pdf>.
+
Construction Management (CM) Guide. 2009. ''Project Organization Types.'' Accessed on September 6, 2011. Available at http://cmguide.org/archives/319.
−
*Handy, C.B. 1985. Understanding Organizations, Penguin Business, London.
+
 
 +
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.
 
----
 
----
−
====Article Discussion====
+
<center>[[Determining Needed Systems Engineering Capabilities in Businesses and Enterprises|< Previous Article]] | [[Enabling Businesses and Enterprises|Parent Article]] | [[Assessing Systems Engineering Performance of Business and Enterprises|Next Article >]]</center>
−
[[{{TALKPAGENAME}}|[Go to discussion page]]]
+
 
−
<center>[[Determining Needed Systems Engineering Capabilities in Businesses and Enterprises|<- Previous Article]] | [[Enabling Businesses and Enterprises to Perform Systems Engineering|Parent Article]] | [[Assessing Systems Engineering Performance of Business and Enterprises|Next Article ->]]</center>
+
<center>'''SEBoK v. 2.9, released 20 November 2023'''</center>
  
−
==Signatures==
 
 
[[Category: Part 5]][[Category:Topic]]
 
[[Category: Part 5]][[Category:Topic]]
−
Qing Wang
+
[[Category:Enabling Businesses and Enterprises]]

Latest revision as of 23:55, 18 November 2023

Lead Authors: Richard Beasley, Art Pyster, Hillary Sillitto, Contributing Authors: Alice Squires, Heidi Davidz, Scott Jackson, Quong Wang

In order for a businessbusiness or enterpriseenterprise to perform systems engineeringsystems engineering (SE) well, the team must decide 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 described 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, as well as commercially and nationally sensitive material. Different cultures and personal styles use information in different ways and in different orders. (Levels of abstraction, big picture first or detail, principles first or practical examples, etc.) 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, as well as 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 ensures 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 must 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 party 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. Systems engineers need appropriate facilities for accessing, sharing and capturing knowledge, as well as for interacting effectively with the whole set of stakeholders. Warfield (2006) describes collaborative workspaces, 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 environments
  • 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, ordinance, 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; 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 which are integrated in their quality and business management system, adapted to their business, and with tailoring guidelines used 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) is concerned with organizational definition and tailoring of the SE lifecycle processes (discussed in detail elsewhere in this document) and Organizational Process Focus (OPF), which is 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 and 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/IEC 9000 (2000) and CMMI (SEI 2010). The Software Engineering Institute, which created the CMMI, offers many free technical reports and other documents on CMMI at http://www.sei.cmu.edu/cmmi.

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

Tools and Methods

SE organizations often invest in SE tools and models, develop their own, and/or integrate 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 proper configuration and management of the information so that people are working on common and correct information.

It is important that methods are used as well as tools, 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 across 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 2013, section 2.1.3). 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, 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

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 heuristicheuristic 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)system breakdown structure (SBS). According to Browning (2009), at each element of the SBS there is an assigned integrated product team (IPT)integrated product team (IPT). Each IPT consists of members of the technical disciplines needed 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.

  • Customer Interface Organizations: These are organizations with titles such as Marketing and Customer Engineering. They have the most direct interface with current or potential clientele. 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 for quality product. 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 ed. Upper Saddle River, NJ, USA: Prentice Hall.

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

Construction Management (CM) Guide. 2009. 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), U.S. 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 & 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.

ISO/IEC. 2000. International standards for quality management. Genève, Switzerland: International Organization for Standardization. ISO 9000:2000.

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. 2013. A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5th 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.

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.

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, DC, 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." Harvard Business Review. 73(2): 59–67.

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. 2.9, released 20 November 2023
Retrieved from "https://sandbox.sebokwiki.org/index.php?title=Organizing_Business_and_Enterprises_to_Perform_Systems_Engineering&oldid=70255"