Developing a framework for establishing cross-functional integration within a product development project

William J. Swanston, Operations Manager, Robbins-Gioia, Inc.

Gary T. Biggar, Senior Program Analyst, Robbins-Gioia, Inc.

In order to bring new products to market in today’s product development environment, an organization must possess the capability to integrate all of its product development functions in a timely and effective manner. True cross-functional integration requires not only that the efforts between the various functions be coordinated, but also that the efforts between the functions support and reinforce each other.

This paper will present a project management model (Exhibit 1) that has been used by the authors to successfully integrate cross-functional product development teams within the automotive industry. Although developed within the automotive industry, the project management model presented in this paper is not limited to the automotive industry and can be adapted and used within any given industry.

Cross Functional Integration—Project Management Model

Step 1: Establish Product Development Templates for Organization

Project Management Process

There are two product development templates that should be developed: a high-level project reference template and a more detailed project integration and management template. The high-level reference template (called the Overall Project Template) contains the major milestones and key events for a typical product development project within the organization. The integration/management template (called the Project Integration template) supports the Overall Project Template by incorporating the details for the milestones and key events that are needed to effectively manage the project. The specific contents for each of these templates will vary according to industry and organization within the industry (i.e., these templates will reflect the type of projects conducted in your organization as well as the way in which your organization manages its product development projects).

The Overall Project Template is used to set the boundaries for the project. Once complete all team members use it as a reference to plan their specific detailed work. The major milestones and key events contained in the Overall Project Template will vary depending on the organization and the industry. Some of the major milestones within the automotive industry include; Project Kick-Off, Strategic Confirmation, Program Approval, Product Readiness, Launch Readiness, and Launch Sign-Off. Key events that drive these milestones include; establishment of product targets and objectives, completion of failure mode and effects analyses, development of designs, supplier sourcing requirements, prototype builds, prototype testing, engineering release and sign-off, tooling design and builds, pilot production and prove-out, and ramp up.

The Project Integration Template begins with all the milestones and key events contained in the Overall Project Template. The Project Integration Template then adds the detailed tasks needed to support these high-level tasks. In short, the Integration Template “fills in the blanks” for the Overall Project Template. The integration template should not be too detailed. As a general rule, it should not go deeper than WBS level 3 or 4. The “minute” details will be managed individually at the functional level. The Project Integration Template is most effective when it is structured by function. All functions required to develop a new product within your organization should be included in the template. This includes, but is not limited to; Product Engineering, Prototype Planning and Build, Product Manufacturing, Product Packaging, Product Appearance, Product Marketing, Product Finance, Purchasing, Quality and Reliability, Program Management, and organization-specific Product Development Deliverables. Organization-specific product development deliverables are the specific deliverables by which your product development projects are measured. Each task contained in the Integration template must be linked to an appropriate product development deliverable. Each product development deliverable is then linked to an appropriate milestone, as depicted in Exhibit 2.

Once the integration template has been properly linked, the last step is to go back and assign each task to its appropriate milestone and deliverable. Assignments are made using the “Text” and “Text 2” columns in Microsoft Project. For each task that supports a project milestone, enter the milestone that it supports in the “Text 1” column. For each task that supports a deliverable within the milestone, enter the deliverable identification number in the “Text 2” column.

Exhibit 1

image

The planning process for each product development project within the organization must begin with these templates, which are then modified or customized for the specific project being undertaken.

Team Integration Issues

Developing effective product development templates for an organization requires the participation and input from all functional areas of responsibilities. The individuals responsible for using the templates must be the same individuals who develop them. This is the only way to achieve an organizational template that the entire cross-functional team will take responsibility for. Before rolling out the completed templates, they should be proven out on a pilot project, and a roll-out implementation strategy should be established (i.e., how the templates will be introduced to the organization).

Exhibit 2

image

Step 2A: Develop Overall Project Plan for the Product Development Project

Project Management Process

As stated under Step 1, the overall project plan is an initial high-level plan for the project that contains only the major milestones and key events for the project. One of the keys to the development of an integrated project plan is to get an initial (high-level) plan in the hands of the team as quickly as possible, so that the project’s strategy and philosophy can be discussed, negotiated, and ultimately agreed upon. The quickest way to begin the team consensus process is to run the overall project template developed under Step 1 by entering the start date for you particular project. The template will then calculate the initial timing for all milestones and key events. Once the Overall Project Template is run, it becomes project specific and is used as a starting point for discussion in weekly project strategy development meetings. These strategy development meetings should include at a minimum, a team member from each function. Also, before beginning the project strategy development meetings, an overall project plan binder should be established so that all decisions related to development of the project strategy are well documented for future reference. The overall project plan binder should contain a tab for the overall project plan, as well as a tab for each project function represented on the project.

Team Integration Issues

Identifying, contacting, and assembling the correct people is the key to establishing the Overall Project Plan. For example, it is important to have experienced CAD (Computer Aided Design) and CAE (Computer Aided Engineering) involved in the high level planning process. In other words “do leave any critical functions out” of these initial project strategy meetings. Personal contact to specially invite program team members to join into the initial process is very helpful.

Once the correct individuals are assembled, it is important to develop and maintain business relationships with each member of the team.

Exhibit 3

image

Exhibit 4

image

Step 2B: Identify Integration-Level Project Content (Scope) for Each Product Development Function

Project Management Process

As the overall project plan begins to mature, each function represented on the project team identifies all the integration level tasks that their function will need to perform. The project integration template is used to accomplish the identification process. After opening up the Project Integration Template and saving it as the “new” project, each function contained in the template (which is now the project integration file) is filtered and distributed to the appropriate team members. Each team member(s) representing a function then goes through their section and identifies all integration level tasks required for their function for the project. For some functions, there may be multiple disciplines that need to participate. For example, within the automotive industry, the engineering function is partitioned into the following disciplines; body interior, body exterior, chassis, and electrical. Each of these disciplines must identify which tasks their discipline must perform in the engineering section.

Note that this step is conducted concurrently with the development of the overall project plan, however; the overall project plan must be fairly solidified before this identification process can take place.

Team members identify the integration level tasks required by marking “Yes” for all required tasks on their print out. Their responses are then entered into the “Text 3” field in the Microsoft Project integration level project file. The following example Scope Identification Form is an excerpt from the engineering section of an automotive template.

Team Integration Issues

In order to obtain accurate scope information each team member must be treated with respect and with the understanding that their individual contribution is valuable to a successful outcome. To obtain the fullest contribution from each member of the team, it is essential to recognize them for their expertise.

Step 3: Establish Project-Specific Integration Schedule

Project Management Process

The project-specific integration schedule is established using the information contained in the overall project plan, in conjunction with the scope information supplied by each of the functions under Step 2B. The Project Integration Template that was developed under Step 1 is converted into a project-specific integration schedule by eliminating all integration template tasks and deliverables not required for the project, and then scaling the remaining tasks to fit the timing contained in the overall project plan.

Exhibit 5

image

The data needed to determine the integration level tasks not required for the project is now contained in the “Text 3” field of the Microsoft Project file that was created under Step 2B above. Any non-summary task that does not contain an entry in the “Text 3” field represents a task that is not required for the project. Each of these tasks must be eliminated from the integration file. There are three steps required to eliminate a task from the integration level schedule. First, the duration for the task is set to zero; second, the task is marked as 100% complete; and finally, “Yes” is entered into the “Flag 1” field in Microsoft Project. Note that the “not required” tasks for the project are not physically eliminated from the integration file. They are simply rendered to a state in which they have no effect or impact on the schedule (i.e., the tasks are hidden). The reason that tasks are not physically eliminated is so they can be easily “reinstated” if it becomes necessary at some point in the future.

Once all the tasks not required for the project have been eliminated (or hidden), the remaining tasks need to be time-scaled in accordance with the overall project plan that has been developed. The most efficient way to time-scale an integration file is to focus on one milestone at a time (i.e., complete the time-scaling process for the first milestone in the integration file before moving on to the second). The following steps make up the time-scaling process:

A. Create a table in Microsoft Project that displays the following columns; ID, Text1, Name, Start, Finish, Duration, and Predecessor.

B. Create a “Milestone” filter that enables the isolation of each milestone. Exhibit 4 provides the definition for the “Milestone” filter in Microsoft Project.

C. Time-scale each milestone in succession.

Exhibit 6

image

•   Run the “Milestone” filter for the desired milestone.

•  Identify all integration tasks for the milestone that are also contained in the Overall Project Plan.

•  Reference the Overall Project Plan for the timing of each of these integration tasks.

•  Time-scale the milestone so that the timing for each Overall Project Plan task contained in the integration file matches the timing contained in the Overall Project Plan. Actual time scaling is accomplished by adjusting task durations, changing lead or lag times, and/or modifying the logic relationships.

D. Save both a project baseline and an interim plan (i.e., save start and finish dates into Start 1 and Finish 1) when the integration file has been time-scaled.

Exhibit 7

image

Once the integration file is project specific (i.e., it is time-scaled and all not-required tasks are eliminated), the overall project plan can be destroyed. It is no longer needed because all of the milestones and key events are also contained in the project specific integration file. At this point, the overall project plan is no longer a separate file, and is simply a filter from the integration file.

Team Integration Issues

It is important to keep all integration tasks identified as “not required” in front of the team on a regular basis. Many times, tasks initially identified as “not required” later become required as the project moves through its execution. Also any changes made to the template logic must be reviewed and approved by the project team. This is critical to maintaining the integrity of the product development templates for the organization. If template integrity is lost, organization buy-in to the templates will also be lost.

Step 4: Filter Integration-Level Functional Schedules

Project Management Process

The integration-level functional schedules represent the “integration points” for each function and/or functional discipline. The tasks contained in the integration-level functional schedules represent the tasks that will be tracked and managed across the project. Therefore, each function must be able to provide status for all of its integration-level tasks. Additional detail is added within each function as required to effectively manage within the function itself (see Step 5 below). Exhibit 5 provides a graphical representation of the integrated work plan structure.

The actual Microsoft Project filter used to filter the integration-level functional schedules is constructed as follows.

Once filtered, the integration-level schedules are distributed to each function within the project.

Team Integration Issues

Prior to distributing the integration-level functional schedules, every effort should be made to get to “personally” know as many people as possible supporting the program. Get to know the team members by name, and whenever possible try to talk to them about their role, function and how it relates to the program. This requires that you sincerely care about others and their contributions to the team.

This relationship building can be planned, but in practice, it is mostly unplanned and usually only takes a few minutes per day. When developing relationships, it is important to keep in mind that project teams consist of an assortment of personalities that range from “quiet introverts” on one end of the spectrum to “boastful extroverts” at the other end. Quiet introverts need to be prodded to contribute information. However, once the feel comfortable in a relationship, they will open up. The “boastful extrovert” will provide more than enough information. The challenge with the “boastful extrovert” is to be able to glean the important project information.

Step 5: Build Detail Into Each Functional Schedule (As Required)

Project Management Process

Initially, each functional schedule is a “filtered” integration file (i.e., the file itself contains all the integration plan tasks). The first step for each function is to go through and eliminate all integration tasks not applicable the specific function. This is accomplished through the following steps:

Exhibit 8

image

Exhibit 9

image

A. Display all tasks in the file (eliminate the filter).

B. Once all tasks are displayed, then display the “Text 3” column.

C. Go through the file and eliminate all tasks that are not required for the function (i.e., all tasks that do not have the function listed in the “Text 3” column).

D. Out-dent all remaining tasks to WBS level 1.

The tasks remaining after the elimination process make up the WBS Level 1 functional schedule. Each of these tasks is then reviewed and detail tasks are added as needed to effectively manage the function (Refer to Exhibit 7—Top Box).

Once the individual functional schedule has been created, the “Start 1” and “Finish 1” fields are used to keep it in line (integrated) with the project integration file. Start1 and Finish1 dates were saved in the integration file under 3D. Thus, when the “filtered” functional schedules are distributed, they automatically contain the integration timing for the project. Each function simply manages its plan to ensure that all work takes place within the time frames established in the Start1 and Finish1 columns (Refer to Exhibit 7—Bottom Box).

As long as the functional schedule remains on or before the integration work plan timing (S1/F1) the overall project remains on schedule. If the duration for an integration work plan task contained in the functional schedule (i.e., WBS Level 1) extends outside S1/F1 timing established for the task, the overall schedule for the project is jeopardized.

Team Integration Issues

Getting team members to build functional schedules can be a very challenging task. Project teams are made up of individuals who are exceptionally busy, over burdened or perhaps do not manage their time well. Many times you will not be “given the time of day” when it comes to being provided important project information and details. This can be extremely frustrating, because the person you need the information from is the only person who can provide it and you must have the information for a specific deadline. There is skill required to obtain this information on time without elevating the situation a team member’s superior. First, inform the team member via e-mail or with a written short memo about what is needed by when and why. Then make yourself visible to the person, but do not interrupt a meeting or a conversation (stand outside his or her office or cube if necessary), and always maintain courtesy and be patient.

More times than not, if this approach does not work, it is because the person cannot provide the information (they simply do not know). These individuals obviously need help, but are either too embarrassed or do not know how to ask for help. This is the time to offer help. Help may be required from others, so assist in planning a meeting if necessary. If this approach does not help, then suggest that a meeting be set up with the appropriate supervisor. It is always important to document all attempts to obtain information. As a last resort, approach the team member’s supervisor on your own, but be prepared with documentation. Always inform the team member of your intentions.

Step 6: Identify Cross-Functional Gives and Gets

Project Management Process

As stated in the introduction, true cross-functional integration requires not only effective “vertical” coordination, but “horizontal” coordination as well.

Vertical coordination is achieved through the “up and down” process that takes place between the project integration file and its supporting functional schedules. Horizontal coordination is achieved through the identification and management of “gives” and “gets” across the functions.

A “give” is defined as a project task whose information must be provided in order for a downstream task to be completed. The function responsible for completing the upstream task has a “give” that must be provided to the function responsible for completing the downstream task.

A “get” is defined as a project task that cannot be completed without the information that would be provided by the completion another specific task. The function that is waiting for the information has a “get” from the function responsible for completing the upstream task.

Initially, the gives and gets for a task are its predecessors (gets) and successors (gives) as contained in the integration file. These are then used as a “springboard” for identifying the lower (functional) level gives and gets that resides only in the minds of the team members. “Gives” and “Gets” are documented on the “Deliverable Gives/Gets Definition Report” (Exhibit 9).

Team Integration Issues

The advantages to the identification of gives and gets include the following:

A. Verification of integration file logic/relationships. Predecessors and successors are presented in nontechnical terms. When presented nontechnically, team member feedback will produce more accurate project “logic” (i.e., a more accurate project model).

B. Team members are better able to identify functional level gives and gets.

Step 7: Execute Product Development Project

Implementation of the project management process presented in combination with ability to recognize and effectively address the team integration issues as they arise will result in a truly cross-functionally integrated project team.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston,Texas,USA

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.