Difference between revisions of "Enabling Systems Engineering"

From SEBoK
Jump to navigation Jump to search
Line 13: Line 13:
 
*[[Enabling Individuals to Perform Systems Engineering]]
 
*[[Enabling Individuals to Perform Systems Engineering]]
  
==Concept map showing key relationships in Part 5==
+
==Key Concepts and Relationships in Part 5==
 
Key relationships among the main concepts in this Part are illustrated in the diagram below.  BEs, teams, and individuals are the central concepts in the diagram:
 
Key relationships among the main concepts in this Part are illustrated in the diagram below.  BEs, teams, and individuals are the central concepts in the diagram:
  

Revision as of 13:16, 14 July 2011

SE activities that support an organization's needs and deliver intended value are enabled by many factors such as the organization's culture, SE workforce competencies, and how the organization grows and deploys its workforce armed with those competencies. There are as many different ways to enable SE performance as there are organizations - every organization's approach is, in detail, unique. Nevertheless, there are many common practices, methods, and considerations that organizations use, providing a framework to structure the relevant knowledge.

Beyond individuals, there are two levels of organizations defined in the SEBoK: team (which includes projects and programs among other types of teams) and business /enterprise (BE). Teams are usually formed for a specific limited duration purpose, 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 resources associated with that effort go on 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. On the other hand, BEs typically have permanence. They usually offer a portfolio of products and services, introducing new ones, retiring old ones, and otherwise taking steps to grow the value of the business or enterprise, however value is defined. Sometimes a single product or service has such value and longevity that it spawns a BE just for its creation, maintenance, and support; e.g., the Eurofighter Typhoon aircraft was developed by a consortium of three companies that formed a holding company specifically for this purpose. That holding company is expected to persist throughout the in-service life of the aircraft, providing support and upgrade services to the operators.

The primary structure of this Part is around BEs, teams, and individuals, with a fourth section at the beginning of the Part that articulates the overall strategy to enable SE to be performed well by a BE composed of teams and individuals.

Knowledge Areas in Part 5

Key Concepts and Relationships in Part 5

Key relationships among the main concepts in this Part are illustrated in the diagram below. BEs, teams, and individuals are the central concepts in the diagram:

  1. A BE has context, scope, and purpose; e.g., the purpose and scope of Federal Express is the delivery of letters and packages quickly and reliably, offering peace of mind to its customers. Part of its context is that there are several other private package delivery companies with which it competes in addition to the public U.S. postal service.
  2. A BE creates value for its participants, shareholders, customers, society, and other stakeholders. The relevant stakeholders varies with the 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 value is greater when SE activities are well aligned to the BE context, scope, and purpose and operate consistent with the BE culture.
  3. A BE assigns resources and services to teams which themselves 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.
  5. Individuals who fill those roles have personal competencies; e.g., the chief systems engineer on a project typically requires 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, and purpose, the team dynamics, and the team composition.
  8. A BE implements governance that includes SE governance to ensure that SE implements the overall strategy for the BE; e.g., the BE may decide by policy what authority the chief systems engineer on a project has and how decisions 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; e.g., 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 concepts from both higher and lower levels. The specific nature of those constraints varies across organizations.

The four knowledge areas of this Part explore these relationships in more depth.










a Businesses, Teams and Individuals in SE

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.


Article Discussion

[Go to discussion page]