Organization

Functional teams serve several roles:

• participate on cross-functional teams to plan and implement product development programs

• provide technical resources and direction to product development teams through part and tool engineering, prototype builds and tests, and model changeover

• manage and implement nonprogram-related team-specific activities such as technology assessment, training, and budgeting.

Cross-Functional Teams

Functional team members are assigned to cross-functional management and development teams.

Action councils are composed of top company and functional managers. They set program objectives, allocate resources to teams, and resolve high-level conflicts. Each action council has a specific business focus, and some oversee product development programs.

Program management teams (PMIfe, also called work groups) coordinate high-level program planning and management activities. Teams include members from most functional teams and the United Auto Workers (UAW). Teams are led by marketing during the development phase and by engineering and manufacturing during the implementation phases.

The PMTs establish project centers to coordinate detailed design, design releases) and prototype builds and tests. They include members from engineering, Manufacturing, and program planning dedicated to one program.

Development Teams

Development teams can be single- or cross-functional depending on technical requirements.

Product development teams and design teams develop specific product systems (functional or vehicle—see work breakdown structure), components, or parts, and closely coordinate activities with other teams. They are responsible for meeting the objectives established by the program management teams and their functional teams.

Work Breakdown Structures

Development work is organized two ways to accommodate various planning and management requirements:

• by vehicle systems, organizing the product into areas with content crossing multiple functional teams

• by functional systems, organizing the product into functional content crossing multiple vehicle systems.

For example, a door is a vehicle system that contains electronics, body panels, interior trim, and coatings, each developed by and coordinated between different functional teams. The electric locks contained in the door are part of a functional system that must be coordinated with other electronics in the vehicle. ■

Two work breakdown structures allow program plans to be "sliced" both ways, to view requirements from both perspectives.

6Y6TEM8 v&KXE

SUBSYSTEMS

Code VEH SYSTEM/Subsvstem

6Y6TEM8 v&KXE

SUBSYSTEMS

FRONT OF VEHICLE

A1 FRONT COMPARTMENT

A11 Structure, Exterior, Lighting

A12 Hood

A13 Front Bumper

A2 ENGINE COMPARTMENT

i CENTER OF VEHICLE

B1 PASSENGER COMPARTMENT

B2 INSTRUMENT PANEL

B3 DOORS

B4 GREENHOUSE

REAR OF VEHICLE

C1 REAR COMPARTMENT

l UNDERSIDE OF VEHICLE

D1 UNDERSIDE OF VEHICLE

Vehicle System Breakdown

The vehicle system breakdown (VSB) structure organizes the vehicle into four areas. Within each area there are vehicle systems and subsystems. Multiple functional teams are involved in the work associated with a given subsystem.

A coding structure provides a way to uniquely identify elements within the VSB (see Figure 2).

Functional System Breakdown

The functional system breakdown (FSB) structure organizes the vehicle according to functional, or technical, systems. Within each functional system, there are assemblies and subassemblies comprised of parts. And how these are actually defined can vary widely between functional teams. Because each functional system is designed by the same functional team across all vehicle programs, the FSB is similar to an organizational breakdown structure and is used to assign responsibility.

A coding structure provides a way to uniquely identify elements within the FSB (see Figure 3).

Component Definition

The VSB and FSB as described are product breakdowns. Converting these to work breakdown structures is done by defining vehicle components and the steps required to develop each. A component, for this purpose, is defined as one part or a group of parts, subassemblies, or assemblies which:

• are developed as a unit by a single functional team

• are associated with a single vehicle system or subsystem

• contain parts not included in other components.

For each program, the FSB and VSB are used to develop a list of up to 200 components used for vehicle and functional planning. Component definitions vary from program to program depending on content and extent of changes from the current product (see Figure 4). Each component is developed using the GM product development process, "4-Phase Process/' which was adapted to Saturn's own approach and organization.

The process describes discrete activities and events that must be completed during each development phase:

FUNCTL SYSTEM/

01. STRUCTURAL

Code Assembly/Subassembly

•01 Spaceframe .01 Body Side .02 Framing .03 Underbody

.02 Cockpit/FOD

.03 Door Structures

.04 Coatings, Sealants, Raw Mtls

02 EXTERiOR PANELS

03 BODY

04 -operv-

05 ELECTRICAL

06 HVAC

07 INTERIOR

06 POWERTRAIN

09 CHASSIS

• Phase 0—technology and concept development

• Phase 1—product and process development

• Phase 2—product confirmation and process validation

• Phase*3—production and continuous improvement.

Each component development is defined with a standard list of twenty-three activities and events detailing Phases 0, 1, and 2. Because each component is uniquely associated with an FSB and a VSB element, the activities represent the lowest level of work breakdown for each of these structures.

Saturn has guided each new vehicle development to production using a variety of schedules maintained at different levels of detail by different parts of the organization. In the beginning, planning coordination was done informally—that is, by affected teams sitting with others to resolve specific interfaces. Because of the large number of interfaces, the need for a more formal means to coordinate schedules earlier was apparent.

This section describes the vision of how planning integration will be done at Saturn: how it will use the FSB and VSB structures to help teams plan their work and coordinate it with others7. While the schedules described exist in some form, the full vision has not yet been realized. The Implementation section of this paper describes the strategy being used; the Progress section describes where it currently stands.

Vehicle development planning is done with a schedule hierarchy based on the VSB (see Figure 5).

Vehicle Schedule !

Saturn uses a vehicle schedule to plan and track major program milestone dates. The schedule consists of approximately 200 activities and twenty to forty milestones. It is structured according to major vehicle systems and reflects the relative timing 1 Critical path method (CPM) scheduling is

Figure 4

not typically used because of the complex relationship between macro-level activities.

The vehicle schedule is used during program planning to:

• establish key program milestones, based on program content and objectives and past performance

• do strategic what-if analysis

• do macro-level budget and staff planning

• provide a framework for the development of the system schedule.

It is used during program implementation to:

• provide a hammock for updated system schedules

• use as a management reporting tool

• assess program status

• assess impacts of changes.

Vehicle System Schedules

Vehicle system schedules are used to plan and integrate all aspects of vehicle development activity and to coordinate systems and subsystems activity. Major components are included when their specific visibility is required.

A summary four-phase subnetwork for the work within each system, subsystem, and component is created. Constraints between these subnetworks reflect the general relationships between development teams based on experience and trust. No attempt is made to articulate detailed interfaces between teams. These are either defined in other Saturn business processes or too complex to capture effectively.

Vehicle system schedules consist of 500 to 1000 activities and events, each coded according to the VSB. The schedule reflects a viable means to achieve the milestones established in the vehicle schedule.

The vehicle system schedule is used during program planning to:

• validate vehicle schedule

• coordinate systems, subsystem, and selected componen' les

Project Management Casebook

Figure 5

• do tactical what-if analyses

• provide a framework for component schedule development.

It is used during program implementation to:

• provide a hammock for updated component schedules

• assess program status

• assess impacts of changes.

Component Schedules

Component schedules are developed based on dates in the vehicle systems schedule. They are constructed using the twenty-three activities described in the Component Definition section. This provides a framework, not a replacement, for detailed planning. Development teams are responsible for planning their work within this framework, coordinating technical interface, and advising when the framework is untenable.

Component schedules also provide a means to establish part-level target dates prior to detailed planning. These are loaded in the information management system (IMS) in which parts readiness dates are maintained. (Data are transferred via an upload from the project management software to IMS on the corporate mainframe.) Standard CPM network models were developed for the eight major functional systems. These models enable the rapid, consistent development of these schedules. As indicated earlier, a new program may have up to 200 components. Models are selected and adapted to component-specific requirements.

Because planning integration was done in the vehicle system schedule, component schedules are maintained independently. No constraints between component schedules are formally maintained.

Component schedules are used during program planning to:

• validate the system schedule

• provide specific direction to development teams

• provide target dates to the IMS.

They are used during program implementation to:

• provide a hammock for updated design schedules

• assess component status

• assess "local" impacts of detailed changes

• provide updates to the IMS.

Component schedules also provide the basis for functional team planning. Another schedule hier.why is developed using the FSB (see Figure 6).

Figure 6

Functional System Schedules

Functional system schedules are developed by functional teams to coordinate the activity across vehicle systems. While the vehicle system schedule was used to coordinate different functional teams' activities for a given subsystem, the functional system schedule is used to coordinate activity for a given functional system across multiple vehicle systems. The functional and vehicle systems schedules are developed in parallel, since changes to one may cause a conflict in the other.

To return to an earlier example, the electric door lock development may be delayed to coordinate it with other door design activities in the vehicle system schedule; however, it may result in a problem for the team developing the security and electronics systems, whose activities are coordinated in a functional system schedule.

Functional system schedules may also contain activities not covered by supporting component schedules. As a result, a resorting or summarization of component schedule activity is not adequate.

Functional system schedules are used during program planning to:

• validate the vehicle system schedule via the component schedules

• coordinate work between component schedules and other functional team activity, including other programs

• aggregate resource requirements within and across programs.

They are used during program implementation to:

• assess component and functional team status

• assess impacts of changes.

Design Schedules

Design schedules are when "the rubber meets the road," where plans are turned into action. Component schedules normally describe the development of groups of parts, each of which must be designed and engineered, each requiring specific tooling.

Standard component networks are often inadequate to plan and track these activities in detail. Design schedules are developed to provide this detail, based on component schedule requirements. The detailed design •process varies widely between functional systems. They are developed to meet the "local" needs of the design leaders and designers.

Figure 7

Design schedules are used during program planning to:

• validate component schedules

• provide specific targets to development teams and members.

They are used during program implementation to:

• assess pert and component status

• assess local impacts of detailed changes

• provide updated promise dates to the IMS.

Management and development teams develop and use schedules to serve their complementary roles. Individual schedules are not created or maintained in a vacuum (see Figure 7).

• System-level schedules provide a framework for component and design schedules.

• Design and component schedules are used to validate system-level and vehicle schedules.

• Vehicle system and functional system schedules are used to coordinate the same work from two perspectives.

As a result, how they are administered is important to their consistency and integration throughout program planning and implementation.

Schedule Ownership

Schedules are owned by teams who are responsible for their development and maintenance, and tacitly for their completeness and correctness. The following matrix outlines, ownership responsibilities. Schedule Owner

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment