Determining Needed Systems Engineering Capabilities in Businesses and Enterprises
Understanding the value that Systems Engineering can provide within the organisation in support of Organizational Purpose is the starting point for deciding the desired SE capabilities. Enterprise Systems Engineering techniques can be used to establish needed SE capabilities from first principles. The SEI Capability Maturity Models for Acquisition, Development and Services provide a framework for selecting systems engineering capabilities relevant to different types of business and enterprise. This topic summarizes the issues that drive the decisions about desired Systems Engineering capabilities for the business or enterprise. This has to take into account the factors that cause organisations to be different, so the topic also discusses the organizational “design” decision and issues that may arise; and also how SE may interact with other functional areas in the organization, and what needs to be done to ensure that Systems Engineering delivers maximum value to the organization.
Drivers
The table below provides a comprehensive list of factors and drivers to be considered when deciding on the desired SE capability for a business and enterprise.
| Environmental Factor | Examples |
|---|---|
| Where the SE activities are performed in the value chain:
See the discussion on "Organizational contexts for SE" in Enabling Businesses and Enterprises to Perform Systems Engineering. |
Whether the organization is:
the “Problem owner”, system operator, prime contractor, subsystem/component developer or specialist service provider |
| Where the business or enterprise operates in the lifecycle | Concept,
development, manufacturing, in-service, retired |
| Nature of responsibility to end users | Explicit - clear requirements, prescriptive legislation
Implicit – “fitness for purpose”, product liability |
| Nature of responsibility to customers | Outcome: deliver the intended benefits the system is expected to provide
Output: deliver or operate the system or part of it against agreed acceptance criteria Activity: perform specified processes Resource: provide specified resource. |
| Scale of systems | At which Hitchins level (Hitchins 2005) is the organization operating:
Level 1: Subsystem and technical artefacts Level 2: Project systems Level 3: Business systems Level 4: Industry systems Level 5: Societal systems? |
| Complexity of systems integration task -Stupples levels,
(Elliot et al, 2007) |
Within a discipline (e.g. software, electronics)
Multiple disciplines (software, hardware, optics, mechanical) Socio technical systems integration Environmental integration |
| Criticality of system and certification requirements | Safety, Security
Ethics, Environment etc |
| Nature of contract | Fixed price or cost plus;
Mandated work share arrangements |
| Nature and predictability of problem domain | Well defined and slowly changing “steady state”
Poorly defined and rapidly changing, operators subject to unpredictable and evolving threats (e.g. defense) |
| Fundamental risks and design drivers in solution domain | Stable, low rate of technology evolution, systems use mature technology;
Rapid technology evolution, pressure to bring new technologies rapidly to market/ into operational use Lead time expectations versus level of integrity/certification |
| competitive situation and business goals | Do existing business better
Recover from a competitive shock or a shift in clients' expectations Develop a new generation product or service Enter a new market Reposition the business or enterprise in the value chain |
| Type of system or service | Product or "productised service"
Bespoke solution (product or service) Tailored solution based on standard product and/or service elements |
Different possible structures for an organization , and how the choice affects SE
Organizations manage SE resource in many different ways. A key driver is the extent to which they seek to optimize use of resources – people, knowledge, and assets – across teams, projects and businesses. There are four basic ways of organizing resources to support multiple projects: Project organization; Matrix organization; Functional organization; and Integrated organization (CM Guide 2009), (Handy 1985), (PMI 2008 section 2.4).
Project organization
A project organization is one extreme where projects are responsible for hiring, training and terminating staff and managing all assets required for delivery. In this model, systems engineers on a project report directly or indirectly to the project manager, and resources are optimized for the delivery the project. However, it does so at the expense of sub optimizing how staff are deployed across the larger enterprise, how technology choices are made across projects, etc. The (DAU 2001) SE Fundamentals gives a recent DoD view of good practice project organizations.
Functional Organization
A functional organization is the opposite extreme, where projects delegate almost all their work to functional groups. This is appropriate when the functional skill is fast-evolving and dependent on complex infrastructure and is often used for manufacturing, test engineering, software development, financial, purchasing, commercial and legal functions.
Matrix Organization
Very often a matrix organization is used to give functional specialists a “home” between project assignments. This is a common approach in systems engineering organizations where a SE functional lead is responsible for workforce development and may manage career development by giving individuals variety of development experience in different assignments.
Integrated Organization
In an integrated organization, people do assigned jobs without specific functional allegiance. Those who perform SE tasks primarily identify themselves as another type of engineer such as a civil or electrical engineer. They are knowledgeable of systems engineering and use it in their daily activities as required.
A Product Centered Organization
In accordance with the (Rechtin, 1991, p. 132) heuristic that “the product and the process must match,” a common method for creating an organizational structure is to make it match the system breakdown structure (glossary) (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.
Some disciplines, such as reliability and safety, may not fit into this hierarchical structure. Separate teams, sometimes called analysis and integration teams (AITs) are created for these disciplines. These teams are sometimes called functional IPTs. There should be an AIT (glossary) for each level of the IPT hierarchy.
At the program level there is a top-level IPT commonly called a systems engineering and integration team (SEIT). The purpose of the SEIT (glossary) is to oversee all the lower level IPTs.
The attached diagram shows how a program organization maps to the system breakdown structure. This diagram shows only two levels, but in practice there may be many levels.
Interfaces with other functions in the business or enterprise
Systems engineering is relevant to and depends on other organizational functions. Some organizations see SE as purely about project delivery. Others see it as a key enabler for innovation for new and improved products and services. Typical relationships with other organizational functions are shown in the following table. These relationships should all add value to the business.
| SE contributes to other function | SE requires from other function | Areas where SE and other function should collaborate |
|---|---|---|
| Research and technology | ||
| Future client needs;
architecture road maps; SE architectural framework for managing dependencies and information flows; maturity criteria. |
Future technology capabilities;
predictions of standards evolution; concept demonstrators; tools and models. |
Future product architectures;
novel system concepts; R&T pull-through; prioritize R&T to address capability gaps; tailored SE for R&T projects; SE research; innovation platforms; technology road mapping |
| Human Resources | ||
| Define SE competencies;
report on staff performance; future SE staff needs; training requirements |
Definition of grade structure and hiring/ promotion criteria;
training budget; training provision |
Develop SE training for practitioners and other functions;
Managing team performance |
| Strategy and Business Development | ||
| Enterprise opportunity assessment;
product line architecting; understanding trends and implications of future needs; model/analyze extended enterprise value stream; critical SE and architectural dependencies; competitor capabilities |
Business case analysis;
future markets; preferred partners; preferred suppliers; priorities for SE capability development; customer feedback |
Enterprise opportunity identification and management;
“Make, team or buy” decisions; product road mapping; crisis management; business development; alignment of goals across the enterprise; managing external relationships |
| Bid and Program | ||
| As above at project level;
Systems engineering planning for whole system lifecycle; Architecture; Independent peer review; Technical metrics for SE process and system performance |
As above at project level;
task authorization and prioritization; Earned Value Mgt process. |
Detailed project planning and control;
risk identification and management; managing customer relationship; managing and controlling changes |
| Engineering Operations | ||
| Architecture constraints/ patterns;
Competence requirements for SE roles; SE process, tools, models, methods, coaching, reviewers; Validation of plans and design, standards; SE metrics requirements; shortfall/excess in forward load; requirements for SE enabling systems |
Metrics reports;
Forward load estimate;
Current SE issues in ops. |
Risk assessment;
“make team buy” decisions for subsystems and SE capabilities; load balancing and prioritization; anomaly resolution |
| Service delivery/Deployed operations (name TBC) | ||
| Change impact analysis
Design and validation of upgrades and reconfiguration for new missions |
Decommissioning;
Refurbishment; |
Changes to operational architecture, e.g. Force Realignment
Anomaly resolution |
Need for clarity of SE approach, and dangers in implementing SE
In any organization where activities and skills are shared there is always a danger of silos or duplication. One of the purposes of Systems Engineering is to reduce this risk – consider the interface or glue role (Sheard 1996), or the idea that “SE is good engineering with special areas of emphasis, … including interfaces between disciplines” (Blanchard and Fabrycky 2005).
It is important to have clarity on how the organization is doing its Systems Engineering. Typically, implementing SE may be part of an organisation improvement, so Kotter’s principles on creating a vision, communicating the vision and empowering the others to act on the vision are most relevant (Kotter 1995). The way an organization chooses to do Systems Engineering , should be part of the vision of the organization – and must be understood and accepted by all.
Many of the major obstacles in systems engineering deployment are cultural (see Culture)
Systems engineering will make a very powerful contribution to the organization’s quality goals. Embedding SE principles, processes and methods in the organization’s quality management system means that senior management and the quality system will help to embed systems engineering and make sure it is applied [(INCOSE 2010a), (ISO 2008) and cross ref part 1?].
One of the lean enablers for Systems Engineering (Oppenheim et al, 2010) is "Pursue perfection". The means of improvement at business or enterprise level is discussed in detail elsewhere, but the starting point has to be deciding the Systems Engineering capabilities the organisation wants
Citations for this topic
BROWNING, T. R. 2009. Using the Design Structure Matrix to Design Program Organizations. In: SAGE, A. P. & ROUSE, W. B. (eds.) Handbook of Systems Engineering and Management. Second ed. Hoboken, NJ: John Wiley & Sons.
INCOSE 2005 “Systems Engineering Leading Indicators Guide”, INCOSE-TP-2005-001-02 (NB this needs to change to the latest version)
INCOSE 2010 a. “INCOSE Systems Engineering Handbook”, Version 3.2
ISO, 2008, ISO/IEC 15288:2008, “Systems and software engineering - System life cycle processes”
Morgan, J. and Liker, J. 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”, accessible at http://cse.lmu.edu/about/graduateeducation/systemsengineering/INCOSE.htm
RECHTIN, E. 1991. Systems Architecting: Creating and Building Complex Systems, Englewood Cliffs, NJ, CRC Press.
References
Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.
Citations
List all references cited in the article. Note: SEBoK 0.5 uses Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.
Primary References
All primary references should be listed in alphabetical order. Remember to identify primary references by creating an internal link using the ‘’’reference title only’’’ (title). Please do not include version numbers in the links.
Additional References
All additional references should be listed in alphabetical order.