Team Capability
Introductory Paragraph(s) ==Determining Systems Engineering Competencies for Projects and Programs Note: proposed change of title==
This article describes the ways in which needed systems engineering competencies can be determined for projects and programs that are conducted to develop a new product, a new enterprise endeavor, or a new service; or to develop a significant enhancements to an existing product, enterprise endeavor, or service. The competencies needed and the competencies that are available influence the ways in which systems engineering teams, projects, and programs are organized and enabled.
As noted in Section 4.2.1, competency is manifest in the knowledge, skills, abilities, and attitudes needed for an individual to perform a specific task efficiently and effectively. Competencies include occupational competence, social competence, and communication competence. Competent systems engineers, for example, have systems engineering knowledge, skills, and ability; engage in systems thinking; possess emotional intelligence; and have good communication and negotiation skills. In addition, competent systems engineers are typically competent within specific domains (e.g. aerospace, medicine, information technology) and within specific process areas of systems engineering (e.g., requirements, design, V&V). Section 4.2 of this Guide provides models of systems engineering competence. [insert link]
In addition to individual competencies to perform systems engineering roles, the collective competencies needed by a systems engineering team for a product, enterprise, or service depend on additional factors, including the domain, the stakeholders, the scope of the effort, criticality of outcome, new initiative versus enhancement, and the responsibilities and authority assigned to the SE team. For example, SE competencies needed to develop an IT enterprise architecture are quite different from those needed to support a mission-critical product at multiple sites. In the former case, the SE team might be organized to play the leadership role in working with senior managers, business process analysts, and other stakeholders at the organizational level, with participation of solution implementers (who may be internal or external to the organization), solution maintainers, and one or more vendors. In the latter case (supporting a mission-critical product at multiple sites), the SE team may consist of a centrally located lead systems engineer with a team of SE members, each deployed to one of the geographically dispersed sites.
The collective set of competencies needed for a systems engineering team to conduct a project or program can be determined as follows:
- Identify the context, to include:
- domain,
- stakeholders,
- organizational culture
- scope of effort,
- criticality of the product, enterprise endeavor, or service,
- new initiative or sustainment project
- Clarify the responsibilities and authority of systems engineering
- Establish the roles to be played by systems engineers, as determined by context, responsibilities, and authority
- Determine the required competencies and competency levels needed to fill the roles
- Determine the number of systems engineers needed to provide the competencies and competency levels for each role
- Determine the availability of needed systems engineers
- Make adjustments based on unavailability of needed systems engineers
- Organize the systems engineering team in a manner that facilitates communication and coordination within the SE team and throughout the project or program [link to article 4.3.1]
As indicated, the set of competencies needed to accomplish systems engineering for a product, enterprise, or service are established by first determining the scope of effort, the responsibilities and authority of the systems engineering team and the roles to be played by systems engineers. Competency models and skills inventories, such as the INCOSE SE Competencies Framework 2010-0205 can be used as a checklist to assist in determining the needed competencies and competency levels for a product, enterprise, or service. [link to 4.2].
Having determined the needed competencies and competency levels, one of two situations will arise: in the optimal case, the number of systems engineers who have the needed competencies and competency levels to fill the identified roles will be available and can be mapped into one of the organizational models presented Article 4.3.1.
However, it is sometimes the case that some of the needed competencies, in sufficient quantities, are either unavailable or cannot be provided because of insufficient funding. For example, a new initiative may need a lead engineer, a requirements engineer, a systems architect and a systems integrator-tester to accomplish systems engineering tasks. Budgetary constraints may indicate that only two of the four roles can be supported. Some compromises must be made; perhaps the system architect will be the lead engineer and the requirements engineer will also be assigned the tasks of system integration and testing even though he or she does not have the desired skill and experience (i.e., competency level) in integration and testing.
Similar considerations apply to systems engineering of enterprise endeavors and services. First the context is established (domain, stakeholders, responsibilities, and so forth). Then the responsibilities and authority of systems engineering is determined, roles to be played are identified, and the number of personnel needed to fill the roles, at various competency levels (skills and experiences) is determined. Availability of personnel may result in some adjustments to the optimal arrangement.
Citations
None noted