Enabling Systems Engineering

Systems engineering (SE) activities that support an organization's needs and deliver intended value are enabled (glossary) by many factors, such as the organization's culture, SE workforce competencies, and how the organization grows and deploys its workforce in order to arm it with those competencies. There are as many different ways to enable (glossary) SE performance as there are organizations, and every organization's approach is highly detailed and unique. Nevertheless, the many common practices, methods, and considerations that organizations use can provide a framework to structure the relevant knowledge.

Beyond individuals, there are two levels of organizational structures defined in the SEBoK: teams (which include project teams, program teams, etc.) and businesses /enterprises . A business is a special type of enterprise which usually has a legal structure; e.g., as a corporation or a unit of a company or government agency that creates products or offers services. An enterprise may be a business, but can also cross traditional business boundaries; e.g., the healthcare system of a nation. Teams are usually formed for a specific purpose of limited duration, such as creating a new system or upgrading an existing service or product. Once the new system has been created and delivered or the existing service or product has been upgraded and fielded, the team responsible for that effort is usually disbanded and the individuals associated with the effort are assigned to new tasks. For example, the U.S. Federal Aviation Administration formed a team in the last decade to create a new enterprise resource planning system for its operations and dispersed the team after the system was fielded. However, there are exceptions; e.g., the U.S. Air Force's SE Center of Excellence persists indefinitely and the team stays together on successive projects. On the other hand, BEs typically have permanence. They usually offer a portfolio of products and services, introduce new ones, retire old ones, and otherwise take steps to grow the value of the business or enterprise when appropriate. They may offer their products and services to a single customer; e.g., a small supplier that makes a single product solely for a large manufacturer. Sometimes, a single product or service has such value and longevity that it spawns a business or enterprise just for its creation, maintenance, and support; for example, the Eurofighter Typhoon aircraft was developed by a consortium of three companies that formed a holding company specifically for the purpose of providing support and upgrade services throughout the in-service life of the aircraft.

Part 5 discusses businesses/enterprises, teams, and individuals, and begins with an articulation of strategies that enable SE to be performed well by a business/enterprise.

Knowledge Areas in Part 5

The four knowledge areas in Part 5 explore the relationships between BEs, teams, and individuals in more depth and point the reader to important information in the literature. They are:

• Systems Engineering Organizational Strategy
• Enabling Businesses and Enterprises to Perform Systems Engineering
• Enabling Teams to Perform Systems Engineering
• Enabling Individuals to Perform Systems Engineering

Key Concepts and Relationships in Part 5

1. A BE has context, scope, and purpose; for example, the purpose and scope of Federal Express is the delivery of letters and packages quickly and reliably. There are several other private package delivery companies with which it competes in addition to the public U.S. Postal Service. In a SE sense, these competing companies are part of Federal Express' context.
2. A BE creates value for its participants, shareholders, customers, society, and other stakeholders. The relevant stakeholders vary for a BE; e.g., Federal Express is a publicly traded company headquartered in the U.S. Its most important stakeholders include its shareholders and the millions of customers it serves daily. The presumption, of course, is that SE activities add value to the BE and that the value is greater when SE activities are well aligned to the BE context, scope, and purpose, and operate consistently with the BE culture.
3. A BE assigns resources and services to teams which have context, scope, purpose, responsibilities, and accountabilities. Some of those teams may be devoted to SE activities; e.g., a team that develops system requirements or a system architecture. Other teams may have a broader role, but still include SE activities; e.g., the team that negotiates terms and conditions with a major subcontractor may be led by a specialist in contracting and negotiation, but may include systems engineers who provide technical insights into the system performance and requirements.
4. Teams have various roles that require specific competencies for effective execution; e.g., a SE team that develops a system architecture will require strong competencies in the most critical technologies on which the architecture is dependent and in the application domain of the system, such as finance, transportation, or communication.
5. Individuals who fill those roles have personal competencies; e.g., the chief systems engineer on a project typically possesses strong communication and leadership competencies.
6. Teams have team dynamics that are influenced by the culture of the organization and by the specific individuals on the team and their competencies.
7. Overall performance is driven by the team context, scope, purpose, team dynamics, and the team's composition.
8. A BE implements governance to ensure that SE actualizes the overall strategy for the BE; e.g., the BE may decide what authority the chief systems engineer on a project has and how decisions made by the chief systems engineer are reviewed.
9. The structure of the BE is driven, at least in part, by the strategy.
10. Finally, there is an implicit recursion in the relationships between BEs, teams, and individuals; for example, a BE which is a large global company may have component BEs, many of which may have further component BEs. A large program team may have component subprogram teams, many of which may have further component project teams, and so forth. Each level of the recursion is enabled and constrained to some degree by the structure, governance, context, and other SE concepts from both higher and lower levels. The specific nature of these constraints varies across organizations.

Key relationships among the main concepts in Part 5 are illustrated in Figure 1 below. BEs, teams, and individuals are the central concepts in the diagram.

Figure 1. Businesses, Teams, and Individuals in SE (Figure Developed for BKCASE)

References

Works Cited

No citations have been identified for version 0.5. Please provide any recommendations on additional references in your review.

Primary References

No primary references have been identified for version 0.75. Please provide any recommendations on additional references in your review.

Additional References

No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.

---

<- Previous Article | Parent Article | Next Article ->