Team Capability
The capability to perform systems engineering includes factors such as having competent personnel, adequate time, sufficient resources and equipment, and appropriate policies and procedures. Team capability requires both competency and capacity to perform the team's collective job functions. Team competency requires the collective aptitudes, intelligence, and skills among team members be used to perform their assigned duties. Capacity requires sufficient numbers of team members and sufficient time within their schedules to perform their duties. A team's capability to perform SE is also dependent on morale and attitudes, at both the individual and team level. Other dimensions of capability include having appropriate tools, team training, and team processes such as configuration management, peer reviews, and a team charter.
Overview
There are many articles and textbooks on teams and teamwork. For example Stephenson and Weil (1992) describe capable people and their attributes; xxx describes the attributes of cohesive teams. This article describes the special considerations that enable teams to perform systems engineering.
There are three forms of teams that perform systems engineering: teams of systems engineers, cross-functional teams that include one or more systems engineers, and teams in which one or more individuals perform systems engineering but are not identified as systems engineers.
Systems engineers within a team may play a leadership role or may provide a consulting or coaching function. The authority and influence of a systems engineer within a team may thus vary from project to project.
Teams within businesses that have strategies based on Figure 5.1 and the accompanying text (see the Strategy article) will have pre-defined governance models and organizational frameworks that can be tailored and adapted to fit the needs of each project. Businesses hat lack one or more elements of Figure 5.1 will, of necessity, establish those elements for the project. Failure to do so typically results in a chaotic project.
next: value added, measurement, see the 16 questions in Art's email
According to Stephenson and Weil (1992), capable people are:
those who know how to learn; are creative; have a high degree of self-efficacy, can apply competencies in novel as well as familiar situations; and work well with others. In comparison to competency, which involves the acquisition of knowledge and skills, capability is a holistic attribute.
The results of a survey by Steward Hase (2000) concluded that the following factors are significant contributors to the human elements of capability:
- Competent People
- Working in Teams
- Visible Vision and Values
- Ensuring Learning Takes Place
- Managing the Complexity of Change
- Demonstrating the Human Aspects of Leadership
- Performing as Change Agents
- Involving People in Change
- Developing Management Talent
- Committing to Organizational Development
Determining needed team competencies
This article describes ways in which the SE competencies needed by a team to perform its SE duties 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 enhancement to an existing product, enterprise endeavor, or service. The competencies needed and the competencies that are available influence the ways in which a SE team , project , or program is organized and enabled.
Individual competencies
As noted in Enabling Individuals to Perform Systems Engineering, competency of an individual is manifest in the knowledge, skills, abilities, and attitudes needed for the individual to perform a specific task efficiently and effectively. Different levels of competency may be needed in different situations. 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). The article on Roles and Competencies includes a summary of systems engineering competency models. Based on the context, these competency models are tailored to match the needs of each project. The roles within the team are defined, and competencies are linked to the roles. The lists of competencies given in those models are most often distributed among the members of a systems engineering team. It is not often that a single individual will possess the full list of competencies given in these models.
Collective competencies
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.
Ways to determine the collective set of competencies needed by a SE team to conduct a project or program include:
- 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, authority, and communication channels of the systems engineering team
- Establish the roles to be played by systems engineers, and other project personnel as determined by context, responsibilities, and authority
- Determine the required competencies and competency levels needed to fill each of the systems engineering 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; see Organizing Teams to Perform Systems Engineering.
- Consult stakeholders to ask "what are we missing?"
As indicated, the set of competencies needed to accomplish SE for a product, enterprise, or service are established by first determining the scope of effort, the responsibilities and authority of the SE team and the roles to be played by systems engineers. Competency models and skills inventories, such as (INCOSE 2010), can be used as a checklist to assist in determining the needed competencies and competency levels for a product, enterprise, or service; see Roles and Competencies.
Accommodating team constraints
Having determined the needed competencies, competency levels, and capacities, 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 in Organizing Teams to Perform Systems Engineering.
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.
References
This article relies heavily on limited sources. Reviewers are requested to identify additional sources.
Works Cited
Hase, S. 2000. "Measuring Organisational Capability: Beyond Competence." Paper presented at Future Research, Research Futures: Australian Vocational Education and Training Research Association (AVETRA) Conference (2000). Accessed on September 14, 2011. Available at http://www.avetra.org.au/abstracts_and_papers_2000/shase_full.pdf.
Stephenson, J. and S. Weil. 1992. Quality in Learning: A Capability Approach in Higher Education. London, UK: Kogan Page.
Primary References
INCOSE. 2011. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.
Hase, S. 2000. "Measuring Organisational Capability: Beyond Competence" Paper presented at Future Research, Research Futures: Australian Vocational Education and Training Research Association (AVETRA) Conference (2000). Accessed on June 8, 2012. Available at http://www.avetra.org.au/abstracts_and_papers_2000/shase_full.pdf.
Annotation
Assessing Systems Engineering Performance of Teams
The NASA APPEL Performance Enhancement provides a service whereby the performance of a systems engineering team can be assessed and interventions can be provided to improve specific gaps in performance. This performance enhancement service increase a project's probability of success by delivering the right support to a systems engineering team at the right time.
There currently is no one accepted systems engineering competency model that is globally applicable and accepted widely within the discipline of systems engineering. To the contrary, the topic on Roles and Competencies has shown the best practice is for an organization to develop its own systems engineering competency model after evaluating its needs with its stakeholders, organization, and workforce within the context of its complete environment e.g., economic, social, political. Nevertheless, the process of developing an organization's systems engineering competency model can be greatly informed and aided by consulting the systems engineering competency models of other publicly available models. The NASA systems engineering competency model is an example from an organization that performs systems engineering on earth and space exploration, technology development, and scientific research projects.
Measuring Organisational Capability: Beyond Competence
This paper presents a method for measuring employee capability that involves a two step process; a qualitative approach to develop a theory followed by a quantitative approach to develop the measurement instrument. Although the paper presents a general approach to measuring organizational capabilities it cana be applied to measuring systems engineering capabilities within an organization.
Additional References
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.
SEBoK Discussion
Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.
If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.
blog comments powered by Disqus