INCOSE SE COMPETENCY FRAMEWORK DEFINITION

COMPETENCY OVERVIEW

The terms "competency" and "competencies" focus on the personal attributes or inputs of an individual. They can be defined as the technical attributes and behaviors that individuals must have, or must acquire, to perform effectively at work.

"Competence" and "competences" are broader concepts that encompass demonstrable performance outputs as well as behavior inputs and may relate to a system or set of minimum standards required for effective performance at work (Chartered Institute of Personnel Development (CIPD) 2021b).

Competency is "a measure of an individual's ability in terms of their knowledge, skills, and behavior to perform a given role (p. xvi)." (Holt and Perry 2011).

Competency is distinct from competence, defined by Merriam-Webster as the ability to do something well (Merriam-Webster 2018). Competence, then, reflects the total characteristics of the individual, while "competency" reflects a single area; the sum of an individual's competencies makes up their competence (Holt and Perry 2011).

Although these terms are now regularly used interchangeably, in this document, the term "competency" is used to define the need ("requirement") and "competence" is used to characterize the "outcome" ("validation").

A "Competency Framework" is a structure that sets out and defines each individual competency required by individuals working in an organization or part of an organization (Chartered Institute of Personnel Development (CIPD) 2021b). This document defines a framework of competencies for the Systems Engineering discipline.

Note that "competence" differs from "capability." Capability is an organizational or organizational team attribute that refers to the ability to execute the organization's mission (i.e. deliver a product or service). Engineering capabilities are defined in terms of people (competencies), processes, facilities, and equipment, the integration of which leads to the ability to produce an engineered product or service.

Indeed, to be effective in any Systems Engineering task, an individual will normally require in addition:

• Supporting Skills and Techniques.
• Domain Knowledge.

Supporting skills and techniques help an individual perform a task effectively within a context. Skills and techniques may be organization, project, or role specific. For instance, the ability to use a company-standard "Requirements Management" tool may be central to performing a given role effectively within one organization, but this tool-specific skill will not help in another organization if it uses a different tool. However, possessing the knowledge, understanding, and experience (i.e. possessing competence) to perform Requirements Management effectively as a task goes beyond the specifics of using any one tool or technique. Indeed, competence may be gained through using a variety of tools. However, an individual organization is likely to require additional "tool-specific skills" for any practitioner to operate effectively within it. The definition of such required skills will form part of the organization-specific tailoring (i.e. the contextualization of the framework).

In a similar way, "domain knowledge" exists within an application or industrial context (e.g. automotive, healthcare, and space). This requires specialization appropriate to the domain addressing areas such as the commercial or organizational environment, the supply chain, and domain-specific technical standards/protocols.

Competence supports the ability to carry out a process, but it is not just about executing a defined process. Competence includes capitalizing on a wider understanding of the relationship between processes, understanding an individual's specific role in supporting their execution within the wider organizational structure, and the behavioral skills required to ensure that process activities are executed effectively. This document includes a mapping of competencies to INCOSE Systems Engineering Handbook processes (see SECF Figure 3) which clearly demonstrates the relationship is not one-to-one.

This framework excludes competencies associated with domain knowledge. Users of this framework can use the ideas defined herein, together with resources available within their domain to extend the scope of this framework by adding domain-specific competencies applicable to their project, business, organization, or domain area.

FRAMEWORK STRUCTURE

Competencies predominately associated with Systems Engineering have been identified and grouped into five themes which are summarized in SECF Figure 1. All competence areas are fully defined in a series of tables forming Annex D of this document.

Note that Annex D only defines the "requirements" which express competence at a particular proficiency level. Validation that requirements have been met (i.e. confirming competence at levels characterized in Annex D) needs to be performed by formally assessing an individual against these indicators.

Guidelines for competency assessment are defined in the INCOSE Systems Engineering Competency Assessment Guide (SECAG). Thus, the SECAG Guidelines can be interpreted as guidelines for "verification and validation" evidence required for SECF Annex D.

Although the specific nature of evidence provided will differ from organization and individual, each defined indicator has at least one possible element of potential evidence associated with it.

COMPETENCE PROFICIENCY LEVELS

Five "levels" of increasing competence have been defined in terms of levels of knowledge and experience for each competency area:

• Awareness

  The person displays knowledge of key ideas associated with the competency area and understands key issues and their implications. They ask relevant and constructive questions on the subject. This level characterizes engineers new to the competency area. It could also characterize an individual outside Systems Engineering who requires an understanding of the competency area to perform their role.

• Supervised Practitioner

  The person displays an understanding of the competency area and have either limited or historical experience. They require regular guidance and supervision.

  SECF FIGURE 1 Complete listing of competencies in the Systems Engineering Competency.

  This level addresses two categories of individuals:

• Individuals new to the competency who are "in-training" or inexperienced in the competency area.
• Individuals who gained experience as a Practitioner (or higher) level in the competency area in the past, but who have not been operating as a day-to-day Practitioner for an extended period. These individuals are currently not able to operate without some degree of regular supervision. Clearly, over time, their learning may progress at a faster pace than those in-training for the first time as skills, tools, and techniques are relearned.
• Practitioner

  The person displays both knowledge and practical experience of the competency area and can function without supervision on a day-to-day basis. They are also capable of providing guidance and advice to less-experienced practitioners.

• Lead Practitioner

  The person displays extensive and substantial practical knowledge and experience of the competency area and provides guidance to others including practitioners encountering unusual situations. Typically, this level is associated with an individual who is the "go-to" person for advice and to determine best practice within the competency area within an organization or business unit.

• Expert

  In addition to extensive and substantial practical experience and applied knowledge of the competency area, this individual contributes to and is recognized beyond the organizational or business boundary. Typically, this level is associated with an individual contributing to and defining regional or international best practices within the competency area.

  During a formal assessment of competence, in addition, there may be a need to record a level of

• "Unaware" meaning that the criteria for "awareness" have not been reached;
• "Not Applicable" which would be appropriate if the competence area is tailored out and not applicable to the business; and
• "Not Assessed" meaning that for whatever reason, the competency area was not covered as part of the assessment activity.

The assessment of competence is covered in the INCOSE SECAG.

LANGUAGE STANDARDIZATION WITHIN THE FRAMEWORK

In order to allow a common interpretation of indicators across the SECF, a common vocabulary has been defined and used in defining competency indicators and assessment evidence.

Where practicable, the terms use standard dictionary definitions although in some cases, these have needed to be adapted to reflect the activity within the context of the framework.

A list of key vocabulary used to define framework competency indicators is contained in SECF Table 1.

SECF TABLE...