Systems Engineering Organizational Strategy

From SEBoK
Jump to navigation Jump to search

Virtually every significant business or enterprise (BE) that creates products and/or services , benefits from performing a wide variety of SE activities to increase the value that those products and services deliver to BE owners, customers, employees, regulators, and other stakeholders . How the BE goes about organizing to conduct SE activities is important to their effectiveness. For example, every BE has a purpose, context, and scope determined by some of its stakeholders and modified over time to increase the value the BE offers to them. Some BEs are for-profit entities, while others work for the public good. Some BEs have a single site, while others are far-flung "empires" with locations around the globe. Some work in highly regulated industries such as medical equipment, while others work with little government oversight and can follow a much wider range of business practices. All of these variations in the purpose, context, and scope of a BE shape the strategy for performing SE within the BE.

To download a PDF of all of Part 5 (including this knowledge area), please click here.

Topics

The SE Organizational Strategy knowledge area contains the:

Primary Considerations

Like all thoughtful strategies, SE strategy is properly driven by the goals of the organization and the resources and constraints available to achieve those goals. SE strategy in particular is influenced by several considerations, especially:

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

SE Strategy Focus

Based on those general considerations, the SE strategy generally addresses:

  • How SE activities provide a value proposition for supporting the organizational purpose
  • How SE activities are allocated among the various organizational entities
  • What competencies are expected from the parts of the organization in order to perform these SE activities
  • How those parts of the organization gain these competencies, what the organization needs to do to improve, and how it does so
  • Who performs the SE activities within each part of the organization
  • How those who perform these SE activities interact with others in the organization.

The strategy is also impacted by the organizational structure, as explained in the next section.

Different Possible Structures for an Organization, and How the Choice Affects SE

Organizations 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, projects, and businesses. There are four common ways of organizing resources to support multiple projects: project organization, matrix organization, functional organization, and integrated organization (CM Guide 2009; Handy 1985; PMI 2008, section 2.4). A large organization would likely apply some combination of these four ways. (Browning 2009) provides a way to optimize project organizational structure.

Project Organization

A project organization is one extreme wherein 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 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 a variety of development experiences in different 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.

A Product Centered Organization

In accordance with the heuristic that “the product and the process must match” (Rechtin 1991, p. 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.

Some disciplines, such as reliability and safety, may not fit into this hierarchical structure. Separate teams, sometimes called analysis and integration teams (AIT) (glossary) are created for these disciplines. These teams are also sometimes called functional IPTs. There is commonly an AIT 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) (glossary) or an overarching IPT. The purpose of the SEIT or overarching IPT is to oversee all the lower level IPTs.

The diagram in Figure 1 shows a typical way in which a program organization maps to the system breakdown structure. This diagram shows only two levels, but in practice there may be many levels.

Figure 1. IPT-System Mapping Diagram (Figure Developed for BKCASE)

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, and the need to service these relationships determines the level of SE capacity and capability that needs to be maintained at the higher levels of the enterprise rather than lower level teams.

Table 1 – Systems Engineering relationships with other functions in businesses and enterprises (Figure Developed for BKCASE)
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;

Research and technology pull-through;

Prioritize research and technology to address capability gaps;

Tailored SE for research and technology 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 Management 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
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

References

Works Cited

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.

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

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

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

Primary References

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.

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

Additional References

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

< 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

Retrieved from "https://sandbox.sebokwiki.org/index.php?title=Systems_Engineering_Organizational_Strategy&oldid=34857"