1 Lecture 2.6: Organization Structures Dr. John MacCarthy UMBC CMSC 615 Fall, 2006

2 Lecture Agenda Organization Models Functional Organization Structure Product-Line/Project Organization Structure Matrix Organization Structure Integrated Product Teams Structuring System Engineering in an Organization

3 Overview of Organizational Structures Types of Organizational Structures Functional Organization Structure: Organized by activities that need to be performed Typical Organization for: a project a department Product-Line/Project Organization Structure: Organized by Market Areas, Projects, and/or Products/Components Typical Organization for: a company with many projects a development organization Matrix Organization Structure: Organized by both Function and Product Typical Mid-Level Organizational Structure Integrate Product Teams: Typically a “mini-matrix organization” within an organization Levels of Organizational Structure Companies Divisions Projects Departments

4 Functional Organization Structure Primary building block for most organizational patterns Classical or traditional approach Groups specialties or disciplines into separately identifiable entities Perform similar activities within one organizational component From Dr. Philip Barry’s SYST 530

5 Functional Organization Structure Advantages Easier to train within functional area Better technical capability Mentoring Cohesive Managers and engineers understand each other Disadvantages Lack of cross-pollination Many problems will require multiple functions to contribute Lack of emphasis on project Lose top-down orientation Hard for engineer to move to another discipline Requires large staff to support Slack will cause higher overhead From Dr. Philip Barry’s SYST 530

6 Product-Line/Project Organization Structure From Dr. Philip Barry’s SYST 530

7 Product-Line/Project Organization Structure Each project self-sufficient relative to system design and support Contains its own management structure, its own engineering function, its own production capability, its own support function, etc. Each project may replicate the functional organization structure From Dr. Philip Barry’s SYST 530

8 Product-Line/Project Organization Structure Advantages Team strongly focused on end- product Strong emphasis on project Emphasis on customer, better understanding of customer Continuity of personnel, loyalty to project More emphasis on applied knowledge in specialty area Disadvantages Duplication of effort Barriers to passing of knowledge Difficult to broaden product base Technology transition Less emphasis on technical advances in specialty area Energy expended in defending product line Engineers could become stagnant From Dr. Philip Barry’s SYST 530

9 Matrix Organization Structure Project A Program Manager Project B Program Manager Project C Program Manager Project D Program Manager - Program management - Planning & scheduling - Configuration management - Data management - Supplier management - Project review & control Project Management Systems Engineering Design Engineering Design Assurance Integrated Logistic Support Software Engineering Production & Test Company DEF Project responsibility Functional responsibility From Dr. Philip Barry’s SYST 530

10 Matrix Organization Structure Tries to combine advantages of pure functional and pure project organization Pure functional emphasizes technology and sacrifices project Pure project emphasizes project and sacrifices technology Functional managers responsible for maintaining technical excellence and sharing it across projects Project managers has overall responsibility and accountability for project success From Dr. Philip Barry’s SYST 530

11 Matrix Organization Structure Advantages Plug in right people to right job at right time Brings high level of domain and functional expertise together Share valuable expertise across a number of projects See disconnects in the design earlier Ensure customer satisfaction Disadvantages Two bosses, two customers Possibility for infighting between project and functional managers Competition for resources More managers, more overhead From Dr. Philip Barry’s SYST 530

12 Varying Importance of Organizational Functions Through Life Cycle Preliminary System Design Conceptual Design Detail System Design & Development Production and/or Construction Operational Use & System Support Systems Engineering From Dr. Philip Barry’s SYST 530

13 Creating the Organizational Environment for Systems Engineering Characteristics to consider when developing an organizational structure for the systems engineering group: Personnel must be highly professional, senior level, varied backgrounds, wide breadth of knowledge in research, design, manufacturing, system support Group must have vision, creativity, be innovative, have strong general problem solving skills There must be spirit of teamwork including mutual trust and respect There must be high degree of communication, both internally and with external functions, both vertical and horizontal To create a favorable environment: Must start from the top, president or general manager level Appropriate level of responsibility, authority and resources must be delegated down to head of systems engineering The right balance on the spectrum of autocratic to democratic leadership must exist between VP of engineering, the PM, & the SEM From Dr. Philip Barry’s SYST 530

14 Functional Considerations For Systems Engineering Systems Engineering Management Architecture Development Requirements Engineering System Subsystem/Design Software Interface Configuration Management and Interface Control Risk Management Technology Assessment System Analysis System Modeling & Simulation CMMI Processes & Procedures Design and Development Interfaces Integration and Test Interfaces Specialty Engineering Information Assurance Security Reliability, Availability, Maintainability …

15 Artifact Considerations for Systems Engineering Plans: Systems Engineering Plan Configuration Management Plan Risk Management Plan Test and Evaluation Master Plan Processes & Procedures Requirements Documents System Requirements Documents Design Requirements Software Requirements Interface Requirements Architecture Artifacts Simulation and Models Trade Studies and Analyses

16 Other Considerations for Systems Engineering Organization The “Systems Engineering” activities and artifacts identified in the previous two charts may be assigned to a “Systems Engineering” Organization or to other organizations depending on: Project Manager Customer Customer Organizational Structure Systems Engineering Artifacts Desired/ Funded

17 Sample Systems Engineering Organization Core SE Functions: SE Management Requirements (Analysis Development & Management) System Concepts and Analysis System Architecture* System Modeling and Simulations* Specialty Engineering* Optional SE Functions: Configuration Management Risk Management

18 Integrated Product/Process Teams (IPTs) Typical IPT is formed to develop a specific product or process It is composed of representatives from each of the stakeholder organizations Generally all IPTs will include a Systems Engineer to ensure that SE is being integrated into the activities of the IPTs and the IPT artifacts are integrated into the SE process Example: Systems Engineering IPT (for SE Artifacts) Design/Development IPT (for Des/Dev Artifacts) Integration and Test IPT (for T&E Artifacts) Modeling and Simulation IPT (for M&S Artifacts)

19 Summary and Conclusions Generally a Project should organize itself in a way that is compatible with its Customer.