Lecture 3.9: Integrated Product Teams (SEF Ch 18)

1. Lecture 3.9: Integrated Product Teams (SEF Ch 18) Dr. John MacCarthy UMBC CMSC 615 Fall, 2006

2. Introduction (non-SEF) Types of Teams Integrated Development (18.1) Integrated Product and Process Development (IPPD) and Integrated Product Teams (IPTs) (S18-A) Integrated Teams (18.2) Project Organization & Integrated Teams Team Organization and Development Team Maintenance (18.3) Team Membership, Roles and Maintenance Team Processes (18.4) Barriers to Integration (18.5) Government Role in IPTs (S18-b) Organizing and Integrating System Development (Ch. 18)

3. Informal Types of Teams (McConnell, Ch. 13): Creativity Team: Focused on exploring alternatives (Concept Development) Tactical Resolution Team: focus on carrying out a well-defined plan (Development, Analysis) Problem Resolution Team: Focused on solving a complex, poorly defined problem (Tiger Team) Formal Types of Teams: Integrated Product Team (IPT): A team from multiple organizations charged to develop some product (or set of products) Tiger Teams: A team, often from multiple organizations, charged with solving some problem, generally in a short period of time Working Groups (WGs): A team, often from multiple organizations, that is charged with planning, identifying solutions, assessing solutions, and/or providing recommendations Types of Teams Generally SE, Development, & T&E Teams will be either IPTs or WGs

4. The use of multi-disciplinary teams in design has become the DoD and Industry standard and is known by many names Such integration requires: Inclusion of the eight primary functions Technical process specialties such as quality, risk management, safety, information assurance, etc. Business processes such as finance, legal, contracts, etc. Characteristics of a well-integrated effort Customer focus Concurrent development of products and processes Early and continuous life cycle planning Maximum flexibility for optimization Robust design and improved process capability Multi-disciplinary teamwork Empowerment Seamless management tools Proactive identification and management of risk Integrated Product Teams (IPTs) are the approach used by DoD to accomplish multi-disciplinary integrated development Integrated Development (18.1)

5. DoD IPPD & IPTs (S18A) • Integrated Product and Process Development (IPPD) is a DoD policy for integrated system development • DoD oversight and multi-disciplinary integration and teamwork is accomplished through a hierarchy of IPTs consisting of three levels • Overarching IPT (OIPT) • Advises the DAE on issues related to programs managed at that level • Working Level IPTs (WIPT) • Advises the Program Manager in the area of concern • Program IPTs (PIPTs) • Teams that perform program tasks (e.g,. Develop artifacts) Note: WIPTs are often used as PIPTs Note: This applies to Government

6. Integrated Product Teams are composed of representatives from all appropriate functional disciplines working together to: Build successful Program Identify and resolve issues Make sound and timely recommendations to facilitate decision making Design successful and balanced products Develop the configuration for successful life cycle control Three Types of IPTs: Overarching IPTs (OIPT) Strategic Guidance Issue Resolution Program Assessment Program Level IPTs Program Execution Representatives from Government and Industry Working IPTs (WIPT) Identify and resolve program issues Determine/monitor Program status Seek Opportunities Integrated (Product) Teams

7. Levels of IPTs: DoD Acquisition DoD Oversight of Programs DoD Program Program Oversight Contractor Program Execution Notes: DoD and DoD Program level IPTs are DoD Policy. Use of IPTs by contractors is optional. Example Contractor-Level Requirements IPT Level: Contractor Level Purpose: Develop Requirements Document Lead: Systems Engineering Membership: Requirements Engineering Architecture Engineering Specialty Engineering (RAM, IA, etc.) Analysis Design/Development Test & Evaluation Program Control (Cost. Schedule and Risk Management) Customer Representative User Representative Other Stakeholders Levels of IPTs & Example Generally those in Bold are the most active participants

8. Engineering Review Board (an contractor OIPT) Program Control IPT: Acquisition Strategy, Project Management Plan Resource-loaded Schedule (IMS) & Cost Baseline Programmatic Metrics Reports Systems Engineering IPT: WBS, SEP, CMP, RMP TPM Reports Requirements IPT Architecture IPT Analysis IPT M&S IPT Design IPT Development IPT T&E IPT Deployment/Activation IPT Example Contractor IPTs and Products

9. IPT Development (18.2) • Team Organization: • Have a clear charter (e.g., list of products to be developed or overseen) • Use a disciplined system engineering approach • Include a Systems Engineering representative on all IPTs • Establish vertical and horizontal organizational/ enterprise communications • Include appropriate representatives from functional organizations • Include appropriate representation representatives from government, contractors, vendors, etc. • Limit individuals to membership on no more than 3-4 WIPTs • Team Leadership should be provided by the organization primarily responsible for the product (sometimes a government/ contractor co-chair is used) • Use of a Facilitator can ease the team building process • Note Teams typically go through5 stages: See next slide

10. Forming: Activities: Figure out how to accomplish task Characteristics: Ignorance of Tasks, Agendas, & Personalities Behavior: Optimistic Storming: Activities: Define tasks to be performed Characteristics: Group discovers task is harder than expected Group discovers personalities & agendas Unrealistic Goals Behavior: Argument, Impatience Norming: Activities: Group begins to perform tasks Characteristics: Team reconciles agendas and personalities Team begins to develop trust Team develops spoken and/or unspoken rules on how to proceed Behavior: Beginning acceptance Performing: Activities: Performing Tasks Characteristics: Acceptance of members’ strengths & weaknesses Trust, Satisfaction & Pride Behavior: Preventing problems Adjourning: Activities : Preparing for dissolution Characteristics: Bidding Farewell Behavior: Pride, Melancholy Team Stages (18.2) The objective should be to optimize the time the team spends in the Performing Stage

11. Team Maintenance (18.3) • Empowerment: • Teams and team members need to be empowered to do the assigned task • The responsibilities and constraints need clearly defined by higher-level teams • Membership Issues: • Team members need to be qualified • Team membership should avoid rapid turnover to reduce returns to forming/ storming stages • Long-lived teams need “new blood” • Teams should be able to remove a member (as a last resort) • Team Leader: • Provides team focus: clear vision of team objectives and performance criteria • Assures environment is present that allows team to perform at an optimal level • Principal interface to next level IPT and management • NOT A SUPERVISOR • Additional team leader roles are described in SEF 18.3 • Facilitator: • Focused on team dynamics and easing transition to the “Performing Stage” • NOT the team leader There is no “I” in TEAM !!

12. Characteristics of High Performance Teams • Shared, Elevating Vision or Goal • Sense of Team Identity • Results-Driven Structure • Competent Team Members • Commitment to the Team • Mutual Trust • Interdependence among team members • Effective Communications • Sense of Autonomy • Sense of Empowerment • Small Team Size • High Level of Enjoyment McConnell, Ch. 12

13. Team discussion is open with no secrets Qualified, empowered team members Team participation is consistent, success-oriented, and proactive Continuous “up-the-line communications” Team member disagreements must be reasoned: Focused on alternative plans of action, not simply opposition to the proposed plan (Formal or informal) Trade studies and other analyses are used to resolve issues Complaints about the team are not voiced outside the team; conflicts are resolved internally Issues are raised and resolved early Design results must be communicated clearly, effectively and timely Design results must be compatible with initially defined requirements Each team member must be familiar with all system requirements Everyone must work from the same database (=>there must be a common database) Only one member of the team has authority to change the controlled version of the document/ product All members have the same level of authority (one person, one vote) Note: Generally each functional organization has only one “member” and a number of supporting participants Some IPTs are set up so that the members provide the Lead their recommendations and the lead has the only “vote” Team Processes: IPT Rules (18.4)

14. (IPT) Meeting Management (18.4) • Guidelines: • Meetings should only be held for a specific purpose • Control meeting participants • Provide (2+ wks) advance notice of meetings (so participants can prepare) • Provide time-allocated Agendas as part of advanced notice • Participants should prepare for meeting by preparing and/ or reviewing required material • Distribute prepared material at least 1 wk prior to meeting • Stick to the agenda first, then cover new business • Transform issues into actions (to include responsible party(s) and a completion date) • Prepare “Meeting Summary” • Record meeting attendance, actions (issues), agreements, and decisions • Prepare draft agenda for next meeting • Frame issues for higher-level resolution • Distribute meeting summary within 1 day of meeting • Permit (2+ days) review and comment by participants (set response date) • Distribute final meeting summary within 2 days of receipt of comments

15. Barriers to Integration: Lack of top management Support Team members not empowered Lack of access to a common database Lack of commitment to cultural change Functional organizations no fully integrated into a team process Lack of planning for team effort Staffing requirements conflict with teams Team members not collocated Lessons Learned and successful practices not shared across teams Inequality of team members Inadequate resources Lack of required expertise Characteristics of Failed Teams (McConnell, Ch. 12): Lack of Common Vision Lack of Identity Lack of Recognition Productivity Roadblocks Ineffective Communications Lack of Trust Problem Personnel Barriers to Integration (18.5)

16. Breaking Barriers (18.5) • Education & Training • Use of a Facilitator • Early Management Support • Use of a Common Database • Establish/Formalize the IPT network that integrates the design and provides horizontal and vertical communications (should be described in the SEP) • Do not over-tax available resources • If competence is not available, hire it through a support contractor • If co-location is not possible: • Have regular (several day) working sessions (or TIMs) • Use of Telecon & Videocon can also help

17. Summary Comments (18.5) • Integrated system development is a systems engineering approach that integrates all essential primary activities through the use of multi-disciplinary teams • IPTs are the DoD approach to achieving integrated development • There are three types of government IPTs: OIPT, IPTs, & WIPTs • The IPT concept is applied at three levels: DoD, Government Program, & Contractor (only the first two are required) • Team building goes through five phases: Forming, Storming, Norming, Performing, and Adjourning • Team organization is difficult to build and maintain. It requires planning, management attention and commitment over the life of the team(s) • Generally, IPT Leaders guide teams, they do not dictate direction • IPTs and team members must be empowered • Team members must be qualified and committed

18. Working with People • Team success is heavily dependent on how well the team works together • To this end it is important to understand: • Types of People • What motivates people • Different types of people are motivated by different factors • What kills morale

19. There are many models for characterizing people I will address the Myers-Briggs Model It is one of the most widely used I am most familiar with it Four dimensions: Extrovert (E) -> Introvert (I) Sensing (S) -> Intuitive (N) Thinking (T) -> Feeling (F) Judging (J) -> Perceiving (P) Example: INTJ Scoring is done on a continuum (e.g., one may be VERY extrovert or only slightly more extrovert than introvert) Although the specific scoring tends to vary each time one takes the test, the end results are rather consistent Different Personality Types have different motivators and perceive different things as being important Different Personality Types generally have difficulty understanding each other: “Why can't X be more like me?” There is no “Best Personality Type.” Each has strengths and weaknesses. What is important is that teams be organized to take advantage of each individual’s strengths and minimize the impact of weaknesses. Part of your homework will be to take this test and develop a team profile. Types of People: Myers-Briggs

20. Top 5 Motivators (for Developers) • Achievement • Possibility for Growth • The Work Itself • Personal Life • Technical Supervision Responsibility • Advancement McConnell, Rapid Development, Ch 11

21. Morale Killers • Poor Work Environment (Hygiene Factors) (lighting, temperature, quietness, privacy, having a desk, up-to-date computer equipment, applicable software tools (legal copies), up-to-date communications support (e-mail, phones, conference rooms), technical support, office equipment, office supplies, access to reference materials, work hour flexibility, training) • Management Manipulation • Excessive Schedule Pressure • Lack of Appreciation • Inappropriate Involvement of Technically Inept Mangement • Not Involving Developers in Decisions that Affect them • Productivity Barriers • Low Quality • Heavy-Handed Motivation Campaigns

22. Summary and Conclusions • The ability of people to work together effectively as a team is critical to project success • This depends on an understanding of: • type of team • goals of the team • the types of people on the team • the factors that motivate them • the factors that kill their morale • Know the Type of Team and the Team’s Objectives (& resources) • Different people have different strengths, weaknesses and value systems. Know them and use them effectively. • Motivate People: • There are a number of techniques • Different types of people are motivated differently • Do not kill Morale “The beatings will continue until the morale improves” is not effective.

23. Questions

24. BACKUP

25. Team Models • Business Team • Chief-Programmer Team • Skunkworks Team • Feature Team: • problem resolution projects • Search and Rescue Team • SWAT Team: implement a solution using a well-known tool or practice • Professional Athletic Team: tactical-execution projects • Theater Teams: multimedia projects • Large Teams: create teams of smaller teams McConnell, Ch. 13

26. References • Steve McConnell, Rapid Development, Microsoft Press, 1996 • Excellent chapters on all aspects of project management and systems engineering • Excellent set of Best Practices • Becoming Dated

27. Top Motivators for Different Types • Programmer/Analyst • Manager • General Population McConnell, Ch 11

28. Government Role on IPTs (S18-B) • Not applicable to most of you