Team Capability

The capability to perform systems engineering (SE) depends on such factors as having competent personnel, adequate time, sufficient resources and equipment, and appropriate policies and procedures. Each team needs a certain number of staff who are proficient in the needed competencies all working together with the right attitude, under the right organization, with appropriate tools, training, and processes such as configuration management, peer reviews, and a team charter. There are several aspects to successful team capacity:

• Organize the team
• Staff the team
• Develop the team
• Assess the team

Organize the team

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.

Within a project, a systems engineer or SE 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, SE 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)

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.

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 in which the team is operating (see Systems Engineering Organizational Strategy). 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 SE and integration team (SEIT), who purpose 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), and are created at various levels of the SBS as needed.

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).

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.

Staff the team

Once the organizational structure of the SE team is understood, the team can be staffed. 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.

In addition to individual competencies to perform SE roles, the collective SE competencies needed by a team 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 team. For example, collective SE competencies needed to develop the IT enterprise architecture for a small company are quite different from those needed to develop the architecture of an aircraft which will be engineered and manufactured in a distributed fashion around the world.

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;
9. Consult stakeholders to ask "what are we missing?"

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).

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. However, it is sometimes the needed competencies, in sufficient quantity, 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.

Develop the team

Before a team that performs SE can be effective, it needs to establish its own identity, norms, and culture. The well-known four stages of “forming, storming, norming, performing” (Tuckman 1965, 384-399) indicate that a SE team needs time to form, for the members to get to know and understand each other as well as the tasks to be performed, and to work out how best to work together. It is also important that care is taken to ensure, to the extent possible, assignment of roles and responsibilities allow SE team members to satisfy their individual goals (Fraser 2010).

The “cost and time to cohesion” can be minimized by good selection and management of the SE team, consistent training across the business so that team members have a common framework of understanding and language for their work, good “infostructure” to allow easy and useful sharing of information, and shared behavioral norms and values. Conversely, in cross-site, inter-company and international SE teams, more time must be allowed for team formation. (Fraser 2010) explains that SE teams are more effective if attention is given to ensuring that each member's work will satisfy their individual goals as well as the team and organizational objectives.

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 as individuals and as members of project teams.

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

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.

Assessing Systems Engineering Team Performance

Performance evaluation is most often conducted for individuals. Robbins (1998, 576) states that the historic belief that individuals are the core building blocks around which organizations are built. However, developing engineered systems and businesses usually requires a focus on team performance. Robbins offers four suggestions for designing a system that supports and improves the performance of teams, including systems engineering teams:

1. Tie the systems engineering team's performance and the overall project team's results to the organization's goals
2. Begin with the team's customer and the work process the team follows to satisfy customer's needs
3. Measure both team and individual performance and compare them to organizational norms and benchmarks
4. Train the team to create its own measures.

For systems engineering in particular, a team of individuals is typically employed to perform the full range of SE tasks. See the section on Systems Engineering Roles and Competencies for more information on SE tasks. Elaborating on the applicability of Robbins' four steps as they apply to SE:

First, the systems engineering and overall project team's results should be tied to the project's and the organization's goals. Use measures that apply to goals the team must achieve. For SE in particular, the team effort should be tied to the product or service which the organization seeks to deliver. The end product for the SE team should not be only the SE work products but the delivered products and services provided by the project. For more information on general SE assessment, see Systems Engineering Assessment and Control.

Second, consider the systems engineering team's customers and more broadly the key stakeholders stakeholder and the work processes that the systems engineering team follows to satisfy customer needs. Systems engineering's customers and stakeholders can be internal or external; the internal customers of systems engineering are the other project elements that depend on systems engineering work products and services, which can be evaluated for on-time delivery of quantity and quality. The process steps can be evaluated for waste and cycle time; i.e., efficiency and effectiveness.

Third, assess both individual and team performance. Define the roles of each systems engineering team member in terms of the tasks that must be accomplished to produce the team's work products. For more information on individual assessment, see Assessing Individuals.

Finally, having the team define its own measures that will be used to measure achievement of goals helps all members of the team to understand their roles, while also building team cohesion.

Example

As an example, NASA's Academy of Program/Project and Engineering Leadership (APPEL) provides a service where team performance is assessed and interventions are provided to the team for specific gaps in performance (NASA 2011). This performance enhancement service increase a project's probability of success by delivering the right support to a project team at the right time. APPEL offers the following assessments:

• Project/Team Effectiveness — Measures effectiveness of a team’s behavioral norms
• Individual Effectiveness — Measures effectiveness of an individual’s behavioral norms
• Project/Team Process Utilization — Measures the extent of a team’s utilization of key processes
• Project/Team Knowledge — Covers topics that NASA project personnel should know in order to perform in their jobs

The APPEL approach can be applied to assessing the performance of a systems engineering team and individual systems engineers.

Continuous development and improvement of systems engineering capabilities can be practiced all levels: individuals, teams , and businesses /enterprises . 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 (glossary) to perform SE is also dependent on morale and attitudes, at both the individual and team levels. This article addresses developing and improving team capability to perform systems engineering and identifies those who perform SE activities as systems engineers regardless of their official organizational title. Developing and improving SE capabilities of individuals is covered in Enabling Individuals, and at the business/enterprise level in Enabling Businesses and Enterprises.

Introduction

Ideally, a team that performs systems engineering tasks is a group of individuals who cooperatively perform those tasks based on a shared vision and a common set of engineering objectives. Not all groups that work together are effective teams. DeMarco and Lister (1999) discuss "teamicide" techniques by which management, perhaps unintentionally, practices "sure fire techniques to kill teams." Teamicide techniques include

• Physical separation of team members
• Fragmentation of time
• Unrealistic schedules
• Excessive overtime

Methods for developing and improving systems engineering capabilities within teams include building cohesive teams, conducting pilot projects, participating in and studying post-mortem analyses, and preparation and examination of lessons learned.

Building Cohesive Systems Engineering Teams

Members of a cohesive systems engineering team have a strong sense of commitment to the work and to the other team members. Commitment creates synergy, which results in performance greater than the sum of the performance of the individual team members. Some key indicators of a cohesive systems engineering team are (Fairley 2009, 411)

• Clear understanding of systems engineering roles and responsibilities
• Shared ownership of systems engineering work products
• Willingness of systems engineers to help one another and to help other project members
• Good communication channels among systems engineers and with other project elements
• Enjoyment of working together

Negations of these indicators are key indicators of a dysfunctional team:

• Confusion of systems engineering roles and responsibilities
• Protective ownership of systems engineering work products
• Unwillingness to help one another
• Absence of good communications among systems engineers and with other project elements
• Personal dislike of one or more other systems engineering team members

Techniques for building and maintaining cohesive systems engineering teams include

• An appropriate number of systems engineering team members
• A correct mix of systems engineering competencies
• Celebration of project milestones
• Team participation in off-site events
• Social events that include family members

Each of these techniques is discussed below.

Appropriate number of systems engineering team members

Having too few team members will result in too many tasks for each systems engineer. Overtime is the typical way of handling having too many tasks to perform. Excessive overtime leads to fatigue and loss of morale which then results in poor performance. The stress created by excessive overtime also limits the time available for learning new skills and decreases receptivity for new approaches. Having too many team members can also create problems. As Fred Brooks observed, in his seminal book The Mythical Man-Month (Brooks 1995, 25):

Adding manpower to a late software project makes it later.

Although Brooks admits that he is oversimplifying outrageously, this quotation became know as Brooks Law. His point is that having too many people on a software (or a systems) project creates increased complexity in partitioning of the work and the resulting complexity of communication and coordination. An old folk saying is "too many cooks spoil the stew." A cohesive systems engineering team has the correct number of team members -- not to many and not too few.

Correct mix of competencies

A competent systems engineering team has the correct mix of skills and abilities, at the necessary competency levels, to fulfill the roles that need to be played to accomplish the SE tasks. Competencies are developed and enhanced by education, training, and experience. Team members can increase the breadth of their competencies by engaging in a variety of tasks rather than becoming "stuck" in a particular job specialty. Balancing specialization with generalization is a challenging, but effective, way to develop and enhance systems engineering team capabilities.

Celebration of project milestones

Celebration of project milestones need not be gala events. An extended coffee break with pastries or a Friday afternoon get-together may suffice. Important milestones to be celebrated may include successful reviews, integration and demonstration of component increments, completion of end-item verification and/or validation, and project completion. Celebrating project milestones are important rituals that can enhance team cohesion, which creates synergy and increases team performance. Other rituals may include participatory morning and afternoon coffee/tea breaks and short, weekly stand-up status meetings.

Team participation in off-site events

Off-site events for systems engineering teams may include planning and review meetings, training classes, and preparation of proposals. The purpose of being off-site is to minimize interruptions and other distractions (no cell phones or email, please) and to provide opportunities for informal socializing. In some cases, extended lunches and breaks are planned to allow time for systems engineering team members to become better acquainted and to discuss common work issues. In other cases, off-site meetings allow members of different teams and cross-functional groups to interact. Some teams have reported that the most important aspect of off-site meetings is the opportunity to engage in informal interactions, rather than the officially stated purpose of the meeting.

Social events that include family members

Social events such as picnics, sporting events, and performances provide an opportunity for team members to interact in a different social setting and to thus become better acquainted, which can increase team cohesion and synergy. Not everyone wants to belong to family-oriented bowling leagues or a ball team but these kinds of social networks sometimes form spontaneously. While generally regarded as positive situations, care must be taken that exclusionary cliques do not develop within systems engineering teams.

Dealing with asocial team members

Some members of systems engineering teams, by virtue of their personalities and preferences, may not desire to be, or are not suited to be members of cohesive teams. In rare cases, these team members may be asocial or anti-social. It is sometimes possible that these individuals can be assigned tasks that do not require close interactions with other team members. These team members may have to reassigned to other duties that do not disrupt and destroy team cohesion.

Other Techniques

Other techniques for developing systems engineering capabilities within teams include conducting pilot projects, preparing of post-mortem analyses, and participation in, and study of lessons learned.

Pilot projects

Pilot projects are an effective mechanism by which systems engineering teams can build team cohesion, acquire new skills, and practice applying newly acquired skills to projects and programs. Pilot projects can be conducted for the sole purpose of skills acquisition, or additionally they can be conducted to determine the feasibility of a proposed approach to solving a problem. Feasibility studies and acquisition of new team skills can be combined in proof-of-concept studies. Primary inhibitors to conducting systems engineering pilot projects are the time required and diversion of personnel resources.

Post-mortem analysis

The purpose of a post-mortem analysis is to identify areas for improvement of systems engineering performance in future projects and programs. Inputs to a post-mortem analysis include personal reflections and recollections of project personnel and other stakeholders; email messages, memos, and other forms of communication collected during a project or program; successful and unsuccessful risk mitigation actions taken; and trends and issues in change requests and defect reports processed by the change control board. Team participation in a post-mortem analysis allows systems engineering team members to reflect on past efforts, which can lead to improved team capabilities for future projects or, if the present team is being disbanded, improved individual ability to participate in future systems engineering teams.

Inhibitors for effective post-mortem analysis include not allocating time to conduct the analysis, failure to effectively capture lessons-learned, failure to adequately document results, reluctance of personnel to be candid about the performance of other personnel, and negative social and political aspects of a project or program. Mechanisms to conduct effective post-mortem analyses of systems engineering projects include using a third party facilitator, brainstorming, Strength-Weakness-Opportunity-Threat (SWOT) analysis, fishbone (Ishikawa) diagrams, and mind mapping.

Lessons learned

Lessons learned in systems engineering include both positive and negative lessons. Experiences gained and documented from past projects and programs can be an effective mechanism for developing and improving the capabilities of a team that performs systems engineering tasks. Studying past lessons learned can aid in team formation during the initiation phase of a new project. Lessons learned during the present project or program can results in improved capabilities for the remainder of the present project and for future projects. Inputs for developing and documenting systems engineering lessons learned include results of past post-mortem analyses plus personal recollections of the team members, informal "war stories," and analysis of email messages, status reports, and risk management outcomes. Inhibitors for developing and using systems engineering lessons learned include failure to study lessons learned from past projects and programs during the initiation phase of a project, failure to allocate time and resources to developing and documenting lessons learned from the present project or program, and reluctance to discuss problems and issues.

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.

Fraser, D. 2010. Relationships Made Easy: How to Get on with The People You Need to Get on with...and Stay Friends with Everyone Else. Worchestershire, UK: Hothive Books.

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.

NASA. 2011. Academy of Program/Project and Engineering Leadership (APPEL), NASA APPEL Performance Enhancement. Accessed on September 15, 2011. Available at http://www.nasa.gov/offices/oce/appel/performance/index.html.

Robbins, S.P. 1998. Organizational Behavior: Concepts, Controversies, Applications, 8th Edition. Upper Saddle River, NJ, USA: Prentice Hall. p. 576.

Stephenson, J. and S. Weil. 1992. Quality in Learning: A Capability Approach in Higher Education. London, UK: Kogan Page.

Tuckman, B. 1965. "Developmental Sequence in Small Groups." Psychological Bulletin. 63(6): 384-99.

Primary References

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

Curtis, B., W.E. Hefley, and S.A. Miller. 2001. People Capability Maturity Model (P-CMM), Version 2.0. Pittsburg, PA, USA: Software Engineering Institute (SEI). CMU/SEI-2001-MM-01. Accessed on June 8, 2012. Available at http://www.sei.cmu.edu/cmmi/solutions/pcmm/

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.

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.

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.

NASA. 2011. Academy of Program/Project and Engineering Leadership (APPEL), NASA APPEL Performance Enhancement. Accessed on September 15, 2011. Available at http://www.nasa.gov/offices/oce/appel/performance/index.html.

Torres, C. and D. Fairbanks. 1996. Teambuilding: The ASTD Trainer's Sourcebook. New York, NY, USA: McGraw-Hill.

Additional References

Fasser, T. and D. Brettner. 2002. Management for Quality in High Technology Enterprises. New York, NY, USA: Wiley.

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

Annotation

Teambuilding: The ASTD Trainer's Sourcebook

There are many books and articles on team building. The Torres and Fairbanks book is one of the better ones. Topics include defining a team's mission, purpose, goals, and operating principles; the stages of team formation (e.g., forming, storming, norming, performing); dysfunctional team member behavior; team communications and problem solving; managing team conflict; self-organized team leadership (i.e., self-directed teams); and leadership effectiveness. The book also includes guidance for organizing team building workshops and participant handouts.

Managing and Leading Software Projects

The Fairley text includes two chapters that address team development: Chapter 10 Teams, Teamwork, Motivation, Leadership, and Communication; and Chapter 11: Organizational Issues. Although the text is about managing and leading software projects, these chapters are equally applicable to developing and maintaining a cohesive systems engineering team.

---

< 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