Team Capability

 THIS BECOMES TEAM CAPABILITIES

The capability to perform systems engineering (SE) 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 three forms of teams that perform SE: teams of systems engineers, cross-functional teams that include one or more systems engineers, and teams in which one or more individuals perform SE but are not identified as systems engineers. Systems engineers within a project team may play a leadership role or may provide a consulting or coaching function. The authority and influence of a systems engineer within a project team will vary from project to project. Teams operate within the strategy established at the business level (see Systems Engineering Organizational Strategy). In some cases, that strategy is clear and explicit. Often a business will delegate substantial authority to a team to determine what capabilities it needs and to obtain staff and other resources to establish those needed capabilities.

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

These attributes of human capability are applicable to all members of an organization, including systems engineers, both individual and as members of project teams.

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, 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 SE 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, verification and validation) (see Part 3, Systems Engineering and Management for more information on specific process areas). The article on Roles and Competencies includes a summary of SE 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 SE 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 the following:

1. Identify the context, to include
   1. domain,
   2. stakeholders,
   3. organizational culture
   4. scope of effort,
   5. criticality of the product, enterprise endeavor, or service,
   6. new initiative or sustainment project
2. Clarify the responsibilities, authority, and communication channels of the systems engineering team
3. Establish the roles to be played by systems engineers, and other project personnel as determined by context, responsibilities, and authority
4. Determine the required competencies and competency levels needed to fill each of the systems engineering roles
5. Determine the number of systems engineers needed to provide the competencies and competency levels for each role
6. Determine the availability of needed systems engineers
7. Make adjustments based on unavailability of needed systems engineers
8. 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.
9. 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.

This topic addresses the ways in which project teams are organized to facilitate systems engineering (SE), considerations that influence the internal organization of teams that perform SE, and inhibitors to effective organization of teams. The internal structure of a team that performs SE, and the structure of a project or program that incorporates a SE team are influenced by the roles, responsibilities and authority of the team in relationship to managers, customers, component specialists, affiliated projects, subcontractors, and vendors; and those considerations, in turn, influence the ways in which stakeholders organize their relationships to software engineering teams (see Systems Engineering and Software Engineering). In this article, those who perform systems engineering tasks are referred to as systems engineers regardless of their titles within specific organizations.

Introduction

Project teams, and the roles of systems engineers within those teams, depend on factors such as the nature, size, and scope of the project, the organization's preferred way of organizing teams, and external constraints such as a larger program in which the project may be embedded. Options range from a dedicated team of systems engineers, to Integrated Product Teams, to teams that include other kinds of engineers that perform systems engineering.

Systems engineers and SE teams may play the roles of technical leads, consultants, or advisers; this also influences the ways in which SE teams are organized. In some organizations, systems engineers and SE teams provide technical leadership; they perform requirements analysis and architectural design, conduct trade studies, and allocate requirements and interfaces to the various elements of a system. In addition, they work with component specialists, develop integration plans and perform system integration, verification, and validation. Depending on the scope of effort, they may also install the system and train the operators and users; provide ongoing services to sustain the system; and retire/replace an aged system. Systems engineers may be housed within a functional unit of an organization and assigned, in matrix fashion, to projects and programs, or they may be permanently attached to a project or program for the duration of that endeavor. For additional information on organizational options see Deciding on Desired Systems Engineering Capabilities within Businesses and Enterprises.

In other cases, one or more systems engineers may provide consulting or advisory services, as requested, to projects and programs. These engineers may be dispatched from a central pool within an organization, or they may be hired from an outside agency.

An SE team can be organized by job specialization, where each SE team member (or each SE sub-team) plays a different role; for example, requirements engineering, system architecture, integration, verification and validation, field test, and installation and training; in this case the various job specializations are typically coordinated by a lead systems engineer.

Alternatively, an SE team can be organized by subsystem where each SE team member (or SE sub-team) performs the previously indicated functions for each of the subsystems with a top-level team to coordinate requirements allocation, interfaces, system integration, and system verification and validation.

Ideally, roles, responsibilities, and authority will be established for each project or program and used to determine the optimal way to organize the team. Sometimes, however, an a priori organizational, project, or program structure may determine the structure, roles, responsibilities, and authority of the SE team within a project or program; this may or may not be optimal.

Staffing relationships

Within a project, a systems engineer, or systems engineering team may occupy a staff position subordinate to the project manager, as indicated in Figure 1 or conversely, the SE team may provide the authoritative interface to the customer with the project manager, or management team, serving in a staff capacity, as indicated in Figure 2. In both cases, systems engineering and project management must work synergistically to achieve a balance among product attributes, schedule, and budget. For additional information see Systems Engineering and Project Management.

Figure 1. SE Team Subordinate to Project Management. (SEBoK Original)

Figure 2. Project Management Subordinate to Systems Engineering. (SEBoK Original)

Scaling up and scaling down

In scaling up to the program level, the considerations portrayed in Figures 1 and 2 can be generalized so that a top-level SE team provides coordination among the subordinate projects. In this case, each project has an SE team, and within each project the SE team members can be organized in either of the ways indicated in the figures. When scaling up to programs, each of the sub-systems in Figures 1 and 2 are separate, coordinated projects.

The models presented in Figures 1 and 2 can be scaled down to smaller projects, where an individual systems engineer performs the SE activities, either in the subordinate position of Figure 1 or the superior position of Figure 2. In this case, there is a single subsystem (i.e., the system) and the supporting functions may be provided by the systems engineer or by supporting elements of the larger organization.

Influence of the organizational strategy

The roles to be played by members of a SE team are influenced by the structures adopted as part of the organizational strategy of the business unit. In Product Centered Organizations, for example, an Integrated Product Team is assigned to each element of the system breakdown structure (SBS). Each IPT consists of members of the technical disciplines necessary to perform systems engineering functions for that element of the system.

At the program level there is a top-level IPT commonly called a systems engineering and integration team (SEIT). The purpose of the Systems Engineering and Integration Team (SEIT) is to oversee all of the lower level IPTs. Some specialists, such as reliability and safety engineers, may be assigned to a team to cover all elements within a given level of the SBS. These teams are sometimes called analysis and integration teams (AITs); they are created at various levels of the SBS as needed.

Additional information on organizational structures, including the roles played in IPTs is in Deciding on Desired Systems Engineering Capabilities within Businesses and Enterprises.

Communication and coordination

Organizing communication and coordination among a group of systems engineers should follow the well known 7 ± 2 rule because the number of communication paths among N engineers is N(N-1)/2; i.e., the number of links in a fully connected graph. (Brooks 1995). There are 10 communication paths among 5 engineers, 21 among 7 engineers, and 36 among 9 engineers. An SE team of more than 10 members (45 paths) should be organized hierarchically with a top-level team leader. Sub-teams can be partitioned by product subsystem or by process work activities (analysis, design, integration).

Teams larger than 7 ± 2 can be organized into sub-teams, with a single point of contact from each sub-team to the other sub-teams. In this case, the number of communication paths is p = n(n-N)/2N + N(N-1)/2 where N is the number of members per team and n is the number of teams. Three sub-teams of six member each would have 15 communication links within each team and 2 links from each team to the other teams. In contrast, a single team of 18 people, would have 153 communication links among the team members

When dividing the work among sub-teams it is important that the systems engineer, or systems engineering team, design the system so that requirements and interfaces can be assigned to each team so that the work of each team can proceed concurrently.

Organizational Considerations

Organizing for sustainment services

Systems engineers may also provide a variety of sustainment services, including chairing and coordinating one or more change control boards, ensuring that upgrades are made, supporting users and other stakeholders, and coordinating system functionality and interfaces with affiliated projects and programs.

One consideration for organizing teams to provide sustainment services is the distinction between low-level, on-going sustainment activities and projects that are formed to develop a significant upgrade or enhancement to a product, enterprise endeavor, or service facility. Some organizations use guidelines to determine the level of a sustainment effort that should be designated as a project that has allocated requirements, schedule, budget, and resources. A guideline might state, for example, that a sustainment effort requiring more than one person-month of effort (one person, one month; two people, two weeks) should be planned, organized, and conducted as an enhancement project.

Organizing systems engineering teams to perform enterprise systems engineering

In the commercial sector, enterprises exist to provide products and services to society, to provide jobs, and to create wealth. Non-profit and governmental enterprises exist to preserve and enhance the general welfare of society. Commercial, non-profit, and governmental enterprises may be local, national, or international in scope.

Responsibilities of systems engineers within enterprises vary widely. In some instances, systems engineers may have primary responsibility for planning, coordinating, and overseeing all aspects of workflow and information management for the enterprise. In other cases, systems engineers may participate as members of a business process-engineering group that includes senior executives, financial analysts, and human resource and information technology specialists.

Systems engineers and engineering teams may be specialized by domain. For example, within the domain of information technology, a systems engineering team might be responsible for all aspects of information flow for a global enterprise. Work activities might include specifying and designing an enterprise-wide network for information flow that includes both technological and manual processes, with special attention to issues of privacy and security; developing an enterprise-level information architecture; and working with solution developers to ensure that processes, infrastructure, and applications satisfy the constraints imposed by the enterprise architecture. In the health care domain, a systems engineering team might work with a health care provider to plan, coordinate, and enhance the overall technical, social, legal, and human aspects of health care delivery to patients.

Other considerations for organizing teams to perform enterprise systems engineering do not differ in significant ways from the considerations presented above.

Organizing teams to perform systems engineering of services

Service organizations take many forms including those that provide a service to a specific population, such as the United Service Organizations (USO) that provides morale and recreational services to members of the U.S. armed forces; fraternal organizations, both religious and secular, that provide opportunities for those who share common interests to affiliate; and service organizations that provide services such as repair and maintenance of other organizations’ computers or that provide billing services for small medical offices. Other forms of service organizations, in addition to independent service organizations, are those that provide of services internal to a larger organization; for example food services or IT services.

For independent organizations, systems engineering of services is typically concerned with analysis and design of all aspects of service delivery, including the mission and vision of the organization, the clients and other stakeholders, staffing requirements, physical facilities, information processing hardware and software, training of service providers; and coordination of services with other organizations or enterprises.

The roles of SE for services within an organization are typically determined by the various organizational entities. IT service delivery,for example, is concerned with all aspects of maintaining the IT infrastructure and providing methods, tools, and techniques to support IT users who include all personnel from senior executives to IT technicians to help desk and help phone personnel; or, SE may be usefully applied to the emergency room operations of a hospital; those involved may not think of their job as SE even though they perform (or should perform) many SE tasks.

Organizing for systems engineering of services can take any of the forms described above, depending on the nature of the service, ranging from an in-house SE group to and independent SE company that is hired to analyze and provide recommendations to a service facility. Other considerations for organizing teams to perform SE for services do not differ in significant ways from the considerations presented above.

Inhibitors

There are many possible inhibitors to organizing teams to perform systems engineering activities in an efficient and effective manner. DeMarco and Lister (1999) identify the following:

• Inadequate systems engineering skills and experience levels
• Incorrect systems engineering skill mixes
• Inadequate numbers of systems engineering personnel
• Unclear responsibilities among systems engineers and between systems engineering and other project elements
• Poor communication channels within a project
• Inappropriate process model for the work to be done

References

Works Cited

Brooks, F. 1995. The Mythical Man-Month. Anniversary Edition. Reading, MA, USA: Addison Wesley.

DeMarco, T. and T. Lister. 1999. Peopleware: Productive Projects and Teams, 2nd ed. New York, NY, USA: Dorset House.

Fairley, R.E. 2009. Managing and Leading Software Projects. Hoboken, NJ, USA: John Wiley & Sons.

Primary References

Brooks, F. 1995. The Mythical Man-Month, Anniversary Edition. Reading, MA, USA: Addison Wesley.

DeMarco, T. and T. Lister. 1999. Peopleware: Productive Projects and Teams, 2nd ed. New York, NY, USA: Dorset House.

Fairley, R.E. 2009. Managing and Leading Software Projects. Hoboken, NJ, USA: John Wiley & Sons.

Additional References

INEEL 2004. A Project Management and Systems Engineering Structure for a Generation IV Very High Temperature Reactor. Idaho Falls, ID, USA: Idaho National Engineering and Environmental Laboratory, NEEL/CON-04-02175. Accessed on September 14, 2011. Available at http://www.inl.gov/technicalpublications/Documents/2808490.pdf

References

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. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.

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 an example whereby the performance of a systems engineering team can be assessed and interventions can be provided to improve specific gaps in performance. Performance enhancement will increase the probability of of a project's success by delivering the right support to a systems engineering team at the right time.

Competency models can be used to determine needed kinds and levels of systems engineering competencies need throughout and organization and for individual projects. 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 Roles and Competencies has shown the best practice is for an organization to develop its own SE 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 SE competency model can be greatly informed and aided by consulting the SE competency models that are publicly available. The NASA SE competency model is an example from an organization that performs SE on earth and space exploration, technology development, and scientific research projects.

Additional References

None.

---

< Previous Article | Parent Article | Next Article >

SEBoK v. 1.9.1 released 30 September 2018

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