Enabling Individuals

The purpose of this knowledge area is to point to the current body of knowledge on enabling individuals to perform systems engineering. Relationships to the team, business, and enterprise are discussed, and a summary of existing literature on SE roles and SE competencies is given. A guide to the literature on the assessment and development of SE competency of individuals is also provided.

Topics

The topics contained within this knowledge area include:

Individuals, Teams, Businesses, and Enterprises

The ability to perform systems engineering may reside in individuals, teams, businesses, and/or enterprises. Existing literature provides lists of systems engineering roles and competencies. An expert systems engineer might possess a full suite of these SE competencies. More likely, it is a team that performs the full list of SE roles, and individuals within the team are responsible for a smaller subset. Or, a business may have dedicated functions to perform specific SE roles. An enterprise may have a purposeful strategy for combining individual, team, and business abilities to execute systems engineering on a complex project.

The discussion of systems engineering competency, capability, capacity, and performance is complex. The human aspect of competency may be considered a subset of capability. Capability includes not just the human capital, but the processes, machines, tools, and equipment as well. Even if an individual has an outstanding level of competency, being able to perform within a limited timeframe might stunt the results. Capacity accounts for this. The final execution and performance of systems engineering is a function of competency, capability, and capacity. This knowledge area focuses on individual competencies (glossary).

Competency is built from knowledge, skills, abilities, and attitudes (KSAA). These are developed through education and experience. Traditionally, systems engineering competencies have been developed primarily through experience. Recently, education has taken on a much greater role in the development of systems engineering competencies. SE competency must be viewed through its relationship to the systems life cycle, the system engineering discipline, and the domain where the engineer practices systems engineering. Competency models for systems engineering must include the discipline and life cycle knowledge and skills. These models may also include an added dimension for the domain and mission areas where the systems are applied. Each competency model typically includes a set of applicable competencies along with a scale for assessing the level of proficiency of each competency or competency area in the model.

Purposes

Individual competency models are typically used for three purposes:

Recruitment and Selection – Competencies define categories for behavioral-event interviewing, increasing the validity and reliability of selection and promotion decisions.

Human Resources Planning and Placements – Competencies can be used to identify individuals to fill specific positions and/or identify gaps in key competency areas.

Education, Training, and Development – Explicit competency models also let employees know what behaviors are valued within their organization. Curriculum and interventions can be designed around desired competencies.

Competency Models

To date, a consensus on SE competencies and competency models has not yet emerged. Many of the competency models available were developed for specific contexts or for specific organizations, and these models are useful within these contexts. However, users of models should be aware of the development method and context for the competency model they plan to use, since the primary competencies for one organization might be different than the primary competencies for another organization.

Note that the long lists of competencies on existing models are not always intended to be fulfilled by one individual, but by groups of individuals. Team competency is not a direct summation of the competency of the individuals on the team, since team dynamics and interpersonal issues complicate the combination of individual competencies at the team level. The Enabling Teams to Perform Systems Engineering and Enabling Businesses and Enterprises to Perform Systems Engineering knowledge areas address grouping of individuals to fulfill the elements of the SE competency models.

The Nature and Role of Systems Engineering Standards

A major role of a profession is to standardize the terminology, measurement methods, and process methods used in national and international practice of the profession. The goal is to enable professionals, educators, and organizations to communicate internationally, and to improve the effectiveness and efficiency of professional practice. The knowledge area Systems Engineering Standards provides comprehensive description of standards that are related to the practice of systems engineering. As the systems engineering profession evolves, the corresponding competencies required to support the discipline also evolve.

Bodies of Knowledge

The definition of requisite SE competencies evolves as the body of knowledge evolves. A body of knowledge, describing the organization and principal elements of a discipline, provides a foundation for a profession that supports curriculum development, certification and licensing, continuing professional education, and a code of ethics and professional conduct. The following bodies of knowledge have been influential in systems engineering:

Guide to the Software Engineering Body of Knowledge (SWEBOK)[1]

Guide to the Project Management Body of Knowledge (PMBOK)[2]

BKCASE is intended to provide such a body of knowledge for systems engineering.

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.