Product Design 19

A manufacturer of microfilm imaging equipment approached the Eastman Kodak Company to design and supply the microfilm cartridges for use with a new machine under development (Exhibit 19-1). The target specifications were similar to previous products developed by the cartridge group at Kodak; however, in contrast to the usual 24-month development time, the customer needed prototype cartridges for demonstration at a trade show in just 8 months, and production was to begin 4 months later. Kodak accepted this challenge of cutting its normal development time in half and called its efforts the Cheetah project. Effective project management was crucial to the successful completion of the project.

A postmortem report is then prepared as part of the formal closing of the project. These reports are used in the project planning stage of future projects to help team members know what to expect and to help identify what pitfalls to avoid. The reports are also a valuable source of historical data for studies of the firm's product development practices. Together with the project documentation, and particularly the contract book, they provide "before and after" views of each project. For the Cheetah project, the postmortem discussion involved six members of the core team and lasted two hours. The discussion was facilitated by a consultant. The project was completed on time, and despite the aggressive schedule, so much of the discussion focused on what the team had done to contribute to project success. The team agreed that the most important contributors to project success were:

A useful tool for representing and analyzing task dependencies is the design structure matrix (DSM). This representation was originally developed by Steward (1981) for the analysis of design descriptions and has more recently been used to analyze development projects modeled at the task level (Eppinger and Browning, 2012). Exhibit 19-3 shows a DSM for the 14 major tasks of the Cheetah project. (Kodak's actual plan included more than 100 tasks.) In a DSM model, a project task is assigned to a row and a corresponding column. The rows and columns are named and ordered identically, although generally only the rows list the complete names of the tasks. Each task is defined by a row of the matrix. We represent a task's dependencies by placing marks in the columns to indicate the other tasks (columns) on which it depends. Reading across a row reveals all of the tasks whose output is required to perform the task corresponding to the row. Reading down a column reveals which tasks receive information from the task corresponding to the column. The diagonal cells are usually filled in with dots or the task labels, simply to separate the upper and lower triangles of the matrix and to facilitate tracing dependencies.

After considering the need for specialized skills, the reality of other commitments of the team members, and the need to accommodate an increase and subsequent decrease in workload, the project leader, in consultation with his or her management, identifies the full project staff and approximately when each person will join the team. When possible, team members are identified by name, although in some cases they will be identified only by area of expertise (e.g., mold designer, industrial designer). The project staffing for the Cheetah project is shown in Exhibit 19-8. Project Schedule The project schedule is the merger of the project tasks and the project time line. The schedule identifies when major project milestones are expected to occur and when each project task is expected to begin and end. The team uses this schedule to track progress

After discovering an undesirable deviation from the project plan, the team attempts to take corrective action. Problems almost always manifest themselves as potential schedule slippage, and so most of these corrective actions relate to arresting potential delays. Some of the possible actions include: • Changing the timing or frequency of meetings: Sometimes a simple change from weekly to daily meetings increases the "driving frequency" of the information flow

After listing all of the tasks, the team estimates the effort required to complete each task. Effort is usually expressed in units of person-hours, person-days, or person-weeks, depending on the size of the project. Note that these estimates reflect the "actual working time" that members of the development team would have to apply to the task and not the "elapsed calendar time" the team expects the task to require. Because the speed with which a task is completed has some influence on the total amount of effort that must be applied to the task, the estimates embody preliminary assumptions about the overall project schedule and how quickly the team will attempt to complete tasks. These estimates are typically derived from past experience or the judgment of experienced members of the development team. A task list for the Cheetah project is shown in Exhibit 19-7.

Aggregate safety times. The estimated duration of each task in the project generally includes some amount of "safety time." This time accounts for the many normal but unpredictable delays that occur during the execution of each task. Common delays include: waiting for information and approvals, interruptions from other tasks or projects, and tasks being more difficult than anticipated. Goldratt (1997) estimates that built-in safety doubles the nominal duration of tasks. Although safety time is added to the expected task duration to account for random delays, these estimates become targets during execution of the tasks, which means that tasks are rarely completed early and many tasks overrun. Goldratt recommends removing the safety time from each task along the critical path and aggregating all of the safety time from the critical path into a single project buffer placed at the end of the project schedule. Because the need to extend task duration occurs somewhat randomly, only some of the tasks will actually need to utilize time from the project buffer. Therefore, a single project buffer can be smaller than the sum of the safety times that would be included in each estimate of task duration, and the critical path may be completed sooner. In practice, the project buffer may only need to start with time equal to half of the shortened critical path duration. Goldratt has developed these ideas into a project management method called Critical Chain. In addition to the project buffer, the method uses feeder buffers to protect the critical path from delays where noncritical tasks feed into the critical path. Each feeder buffer aggregates the safety times of the tasks on a noncritical path. Exhibit 19-11 illustrates the use of project and feeder buffers

An effective way to tackle the generation of the task list is to consider the tasks in each of the remaining phases of development. For our generic development process, the phases remaining after concept development are system-level design, detail design, testing and refinement, and production ramp-up. (See Chapter 2, Development Processes and Organizations.) In some cases, the current effort will be very similar to a previous project. In these cases, the list of tasks from the previous project is a good starting point for the new task list. The Cheetah project was very similar to dozens of previous efforts. For this reason, the team had no trouble identifying the project tasks. (Its challenge was to complete them quickly.)

An evaluation of the project's performance after it has been completed is useful for both personal and organizational improvement. This review is often called a postmortem project evaluation or postproject review. The postmortem evaluation is usually an open-ended discussion of the strengths and weaknesses of the project plan, development processes employed, commercial and technical results, and quality of execution. This discussion is sometimes facilitated by an outside consultant or by someone within the company who was not involved in the project. Several questions help to guide the discussion: • Did the team achieve the mission articulated in the mission statement (including strategic, technical, and financial goals)? • Which aspects of project performance (development time, development cost, product quality, manufacturing cost, environmental impacts) were most positive? • Which aspects of project performance were most negative? • Which tools, methods, and practices contributed to the positive aspects of performance? Managing Projects 417 • Which tools, methods, and practices detracted from project success? • What problems did the team encounter? • What specific actions can the organization take to improve project performance? • What specific technical lessons were learned? How can they be shared with the rest of the organization?

Budgets are customarily represented with a simple spreadsheet, although many companies have standard budgeting forms for requests and approvals. The major budget items are staff, materials and services, project-specific facilities, and spending on outside development resources. For most projects the largest budget item is the cost of staff. For the Cheetah project, personnel charges made up 80 percent of the total budget. The personnel costs can be derived directly from the staffing plan by applying the loaded salary rates to the estimated time commitments of the staff on the project. Loaded salaries include employee benefits and overhead and are typically between two and three times the actual salary of the team member. Many companies use only one or two different rates to represent the cost of the people on a project. Average staff costs for product development projects range from $2,000 to $5,000 per person-week. For the Cheetah project, assuming an average cost of $3,000 per person-week, the total cost for the 354 person-weeks of effort would be $1,062,000. Early in the development project, uncertainty of both timing and costs are high, and the forecasts may only be accurate within 30 to 50 percent. In the later stages of the project the program uncertainty is reduced to perhaps 5 percent to 10 percent. For this reason some margin should be added to the budget as a contingency. A summary of the Cheetah project budget is shown in Exhibit 19-9.

Changing the project scope or schedule: If all other efforts fail to correct undesirable deviations from the project plan, then the team must narrow the scope of the project, identify an alternative project goal, or extend (slip) the project schedule. These changes are necessary to maintain a credible and useful project plan.

Decouple tasks to avoid iterations. Iterations can often be reduced or eliminated by taking actions to decouple tasks. For example, by clearly defining an interface between two interacting components early in the design process, the subsequent design of the two components can proceed independently and in parallel. The definition of the interface may take some time in advance, but the avoidance of time-consuming iterations may result in net time savings. (See Chapter 10, Product Architecture, for a discussion of establishing interfaces to allow the independent development of components.) • Consider sets of solutions. Iterations involve the exchange of information about the evolving product design. Rather than exchanging point-value estimates of design parameters, in some cases the use of ranges or sets of values may facilitate faster convergence of coupled tasks. Researchers have recently described the application of such set-based approaches to concurrent engineering at Toyota (Sobek et al., 1999).

Engaging outside resources: The team may be able to retain an outside resource such as a consulting firm or a supplier to perform some of the development tasks. Outside firms are typically fast and relatively economical when a set of tasks can be clearly defined and when coordination requirements are not severe

Exhibit 19-2 displays the tasks for three portions of the Cheetah project. The tasks are represented by boxes, and the information (data) dependencies among the tasks are represented by arrows. We refer to this representation as an information-processing view or a data-driven perspective of product development because most of the dependencies involve transfer of information (data) between the tasks. We say that task B is dependent on task A if an output of task A is required to complete task B. This dependency is denoted by an arrow from task A to task B.

Exhibit 19-2(a) shows three tasks, two of which are dependent on the output of another task. These tasks are sequential because the dependencies impose a sequential order in which the tasks must be completed. (Note that when we refer to tasks being "completed" sequentially, we do not necessarily mean that the later task cannot be started before the earlier one has been completed. Generally the later task can begin with partial information but cannot finish until the earlier task has been completed.) Exhibit 19-2(b) shows four development tasks. The middle two tasks depend only on the task on the left, but not on each other. The task on the right depends on the middle two tasks. We call the middle two tasks parallel because they are both dependent on the same task but are independent of each other. Exhibit 19-2(c) shows five development tasks, three of which are coupled. Coupled tasks are mutually dependent; each task requires the result of the other tasks to be completed. Coupled tasks either must be executed simultaneously with continual exchanges of information or must be carried out in an iterative fashion. When coupled tasks are completed iteratively, the tasks are performed either sequentially or simultaneously with the understanding that the results are tentative and that each task will most likely be repeated one or more times until the team converges on a solution.

Facilitate the exchange of essential information. As shown in the DSM representation, a tremendous amount of information must be transferred within the product development team. Every task has one or more internal customers for the information it produces. For small teams, frequent exchange of information is quite natural and is facilitated by team meetings and colocation of team members. Larger teams may require more structure to promote rapid and frequent information exchange. Blocks of coupled tasks revealed by the DSM identify the specific needs for intensive information exchange. Computer networks and collaboration software tools can facilitate regular information transfer within large and dispersed product development teams.

Focusing more effort on the critical tasks: By definition, only one sequence of tasks forms the critical path. When the path can be usefully attacked by additional people, the team may choose to temporarily drop some or all other noncritical tasks to ensure timely completion of the critical tasks.

For all but the simplest products, product development involves many people completing many different tasks. Successful product development projects result in high-quality, low-cost products while making efficient use of time, money, and other resources. Proj ect management is the activity of planning and coordinating resources and tasks to achieve these goals

For small projects, such as the development of a hand tool, each task may correspond, on average, to a day or two of work for a single individual. For medium-sized projects, such as the development of a computer printer, each task may correspond to a week of work for a small group of people. For a large project, such as the development of an automobile, each task may correspond to one or more months of efforts for an entire division or subteam. For large projects, each of the tasks identified at this level may be treated as its own development project with its own project plan

Incentives: Some of the most basic organizational forms, such as functional organizations that use functional performance reviews, may inhibit the productive collaboration of team members across functions. The implementation of project-based performance measures creates incentives for team members to contribute more fully to the project. Having both a project manager and a functional manager contribute to individual performance reviews leading to promotions, merit increases, and bonuses sends a strong EXHIBIT 19-12 Communication frequency versus separation distance. This relationship shown is for individuals with an organizational bond, such as belonging to the same product development team. Source: Based on Allen, Thomas J., and Gunter W. Henn, The Organization and Architecture of Innovation: Managing the Flow of Technology, Elsevier, Burlington, MA, 2007 0 10 20 30 40 50 60 70 80 30% 25% 20% 15% 5% 10% Separation Distance, Meters Probability of Communicating at Least Once per Week 414 Chapter 19 message that project results are highly valued. (See Chapter 2, Development Processes and Organizations, for a discussion of various organizational forms, including project, functional, and matrix organizations.)

Informal communication: A team member engaged in a product development project may communicate with other team members dozens of times per day. Many of these communications are informal; they involve a spontaneous stop by someone's desk, a telephone call, or e-mail to request or provide a piece of information. Good informal communication is one of the mechanisms most useful in breaking down individual and organizational barriers to cross-functional cooperation. While professionals today are generally comfortable interacting with collaborators around the globe, informal communication is dramatically enhanced by locating the core members of the development team in the same work space. Allen (2007) has shown that communication frequency is inversely related to physical separation and falls off rapidly when people are located more than a few meters from one another (Exhibit 19-12). In our experience, e-mail and, to a lesser extent, voice mail also provide effective means of fostering informal communication among people who are already well acquainted with one another. • Meetings: The primary formal communication mechanism for project teams is meetings. Most teams meet formally at least once each week. Many teams meet twice each week, and some teams meet every day. Teams located in the same work space need

Manage the project scope. There is a natural tendency to add additional features and capabilities to the product as development progresses. Some companies call this phenomenon "feature creep" or "creeping elegance," and in time-sensitive contexts it may result in an elegant product without a market. Disciplined teams and organizations are able to "freeze the design" and leave incremental improvements for the next generation of the product

Outsource some tasks. Project resource constraints are common. When a project is constrained by available resources, assigning tasks to an outside firm or to another group within the company may prove effective in accelerating the overall project. The final set of guidelines is aimed at completing coupled tasks more quickly. Recall that coupled tasks are those that must be completed simultaneously or iteratively because they are mutually dependent.

PERT (program evaluation and review technique) charts explicitly represent both dependencies and timing, in effect combining some of the information contained in the DSM and Gantt chart. While there are many forms of PERT charts, we prefer the "activities on nodes" form of the chart, which corresponds to the process diagrams that most people are familiar with. The PERT chart for the Cheetah project is shown in Exhibit 19-5. The blocks in the PERT chart are labeled with both the task and its expected duration. Note that the PERT representation does not allow for loops or feedback and so cannot explicitly show iterative coupling. As a result, the coupled tasks G, H, and I are grouped together into one task. The graphical convention of PERT charts is that all links between tasks must proceed from left to right, indicating the temporal sequence in which tasks can be completed. When the blocks are sized to represent the duration of tasks, as in a Gantt chart, then a PERT diagram can also be used to represent a project schedule

Perform more iterations quickly. Much of the delay in completing coupled tasks is in passing information from one person to another and in waiting for a response. If the iteration cycles can be completed at a higher frequency, then the coupled tasks can sometimes be completed more quickly. Faster iterations can be achieved through faster and more frequent information exchanges. In the Cheetah project, the mechanical engineer would work closely with the mold designer, who would in turn work closely with the mold maker. In many cases, these three would share a single computer display 412 Chapter 19 for the purpose of exchanging ideas about how the design was evolving from their three different perspectives

Pipeline large tasks. The strategy of pipelining is applied by breaking up a single large task into smaller tasks whose results can be passed along as soon as they are completed. For example, the process of finding and qualifying the many vendors that supply the components of a product can be time-consuming and can even delay the production ramp-up if not completed early enough. Instead of waiting until the entire bill of materials is complete before the purchasing department begins qualifying vendors, purchasing could qualify vendors as soon as each component is identified. Pipelining in effect allows nominally sequential tasks to be overlapped.

Process documents: Each of the methods presented in this book also has an associated information system that assists the project team in making decisions and provides documentation. (By information systems we mean all of the structured means the team uses to exchange information, not only the computer systems used by the team.) For example, the concept selection method uses two concept selection matrices to both document and facilitate the selection process. Similarly, each of the other information systems serves both to facilitate the logical execution of the process step and to document its results. Exhibit 19-13 lists some of the important information systems used at the various stages of the development process.

Product development projects involve the completion of hundreds or even thousands of tasks. This section discusses some of the fundamental characteristics of interacting tasks—the "basic physics" of projects. We also present three ways to represent the tasks in a project.

Product development time is often the dominant concern in project planning and execution. This section provides a set of guidelines for accelerating product development projects. Most of these guidelines are applicable at the project planning stage, although a few can be applied throughout a development project. Accelerating a project before it has begun is much easier than trying to expedite a project that is already under way. The first set of guidelines applies to the project as a whole.

Project leaders and senior managers need to be able to assess project status to know whether corrective actions are warranted. In projects of modest size (say, fewer than 50 people) project leaders are fairly easily able to assess the status of the project. The project leader assesses project status during formal team meetings, by reviewing the project schedule, and by gathering information in informal ways. The leader constantly interacts with the project team, meets regularly with individuals to work through difficult problems, and is able to observe all of the information systems of the project. A team may also engage an expert from outside the core team to review the status of the project. The goal of these reviews is to highlight areas of risk and to generate ideas for addressing these risk areas

Project management activities occur during project planning and project execution. Project planning involves scheduling the project tasks and determining resource requirements. The project plan is first laid out during the concept development phase, although it is a dynamic entity and continues to evolve throughout the development process. Project execution, sometimes called project control, involves coordinating and facilitating the myriad tasks required to complete the project in the face of inevitable unanticipated events and the arrival of new information. Execution is just as important as planning; many teams fail because they do not remain focused on their goals for the duration of the project

Project reviews, conducted by senior managers, are another common method of assessing progress. These reviews tend to correspond to the end of each phase of development and are key project milestones. These events serve not only to inform senior managers of the status of a project but also to bring closure to a wide variety of development tasks. While these reviews can be useful milestones and can enhance project performance, they can also hinder performance. Detrimental results arise from devoting too much time to preparing formal presentations, from delays in scheduling reviews with busy managers, and from excessive meddling in the details of the project by those reviewing the project.

Projects rarely proceed exactly according to plan. Some of the deviations from the plan are minor and can be accommodated with little or no impact on project performance. Other deviations can cause major delays, budget overruns, poor product performance, or high manufacturing costs. Often the team can assemble, in advance, a list of what might go wrong, that is,

Smooth execution of even a well-planned project requires careful attention. Three problems of project execution are particularly important: (1) What mechanisms can be used to coordinate tasks? (2) How can project status be assessed? and (3) What actions can the team take to correct for undesirable deviations from the project plan? We devote this section to these issues. Coordination Mechanisms Coordination among the activities of the different members of the team is required throughout a product development project. The need for coordination is a natural outgrowth of dependencies among tasks. Coordination needs also arise from the inevitable changes in the project plan caused by unanticipated events and new information. Difficulties in coordination can arise from inadequate exchanges of information and from organizational barriers to cross-functional cooperation. Here are several mechanisms used by teams to address these difficulties and facilitate coordination.

Soliciting more time and effort from the team: If some team members are distributing their efforts among several projects, project performance may be increased by relieving them of other responsibilities. Needless to say, high-performance project teams include team members who regularly deliver more than a 40-hour work week to the project. If a few critical tasks demand extraordinary effort, most committed teams are willing to devote a few weeks of 14-hour days to get the job done; however, 60- or 70-hour weeks cannot reasonably be expected from most team members for more than a few weeks without causing fatigue and burnout.

Start the project early. Saving a month at the beginning of a project is just as helpful as saving a month at the end of a project, yet teams often work with little urgency before development formally begins. For example, the meeting to approve a project plan and review a contract book is often delayed for weeks because of difficulty in scheduling a meeting with senior managers. This delay at the beginning of a project costs exactly as much time as the same delay during production ramp-up. The easiest way to complete a project sooner is to start it early.

The Critical Chain method uses a novel approach to monitoring the project schedule. By simply monitoring the project buffer and the feeder buffers of the project (described briefly earlier), the project manager can quickly assess the criticality of each path and the estimated project completion time. If tasks consume the project buffer faster than the critical path is being completed, the project runs the risk of slipping the end date. A buffer report therefore provides a concise update on the project status in terms of progress of the critical path and its feeder paths.

The Critical Path The dependencies among the tasks in a PERT chart, some of which may be arranged sequentially and some of which may be arranged in parallel, lead to the concept of a critical path. The critical path is the longest chain of dependent events. This is the single sequence of tasks whose combined required times define the minimum possible completion

The DSM is most useful when the tasks are listed in the order in which they are to be executed. In most cases, this order will correspond to the order imposed by sequential dependencies. Note that if only sequentially dependent tasks were contained in the DSM, then the tasks could be sequenced such that the matrix would be lower triangular; that is, no marks would appear above the diagonal. A mark appearing above the diagonal has special significance; it indicates that an earlier task is dependent on a later task. An above-diagonal mark could mean that two sequentially dependent tasks are ordered backward, in which case the order of the tasks can be changed to eliminate the abovediagonal mark; however, when there is no ordering of the tasks that will eliminate an above-diagonal mark, the mark reveals that two or more tasks are coupled. Changing the order of tasks is called sequencing or partitioning the DSM. Simple algorithms are available for partitioning DSMs such that the tasks are ordered as much as possible according to the sequential dependencies of the tasks. Inspection of a partitioned DSM reveals which tasks are sequential, which are parallel, and which are coupled and will require simultaneous solution or iteration. In a partitioned DSM, a task is part of a sequential group if its row contains a mark just below the diagonal. Two or more tasks are parallel if there are no marks linking them. As noted, coupled tasks are

The baseline project plan embodies assumptions about how quickly the project should be completed, about the performance and cost goals for the product, and about the resources to be applied to the project. After completing a baseline plan, the team should consider whether some of these assumptions should be revisited. In particular, the team can usually choose to trade off development time, development cost, product manufacturing cost, product performance, and risk. For example, a project can sometimes be completed more quickly by spending more money. Some of these trade-offs can be explored quantitatively using the economic analysis techniques described in Chapter 18, Product Development Economics. The team may also develop contingency plans in case certain risks cannot be overcome. The most common desired modification to the baseline plan is to compress the schedule. For this reason, we devote the next section to ways the team can accelerate the project.

The minimum number of people required on the project team can be estimated by dividing the total estimated time to complete the project tasks by the planned project duration. For example, the estimated task time for the Cheetah project was 354 person-weeks. The team hoped to complete the project in 12 months (or about 50 weeks), so the minimum possible team size would be seven people. All other things being equal, small teams seem to be more efficient than large teams, so the ideal situation would be to have a team made up of the minimum number of people, each dedicated 100 percent to the project. Three factors make realizing this ideal difficult. First, specialized skills are often required to complete the project. For example, one of the Cheetah tasks was to design molds. Mold designers are highly specialized, and the team could not use a mold designer for a full year. Second, one or more key team members may have other unavoidable responsibilities. For example, one of the engineers on the Cheetah project was responsible for assisting in the production ramp-up of a previous project. As a result, she was only able to commit half of her time to the Cheetah project initially. Third, the work required to complete tasks on the project is not constant over time. In general, the work requirement increases steadily until the beginning of production ramp-up and then begins to taper off. As a result, the team will generally have to grow in size as the project progresses to complete the project as quickly as possibl

The project plan is the roadmap for the remaining development effort. The plan is important in coordinating the remaining tasks and in estimating the required development resources and development time. Some measure of project planning occurs at the earliest stages of product development, but the importance of the plan is highest at the end of the concept development phase, just before significant development resources are committed. This section presents a method for creating a baseline project plan. After establishing this baseline, the team considers whether it should modify the plan to change the planned development time, budget, or project scope. The results of the concept development phase plus the project plan make up the contract book.

The project team is the collection of individuals who complete project tasks. Whether or not this team is effective depends on a wide variety of individual and organizational factors. Smith and Reinertsen (1997) propose seven criteria as determinants of the speed with which a team will complete product development; in our experience these criteria predict many of the other dimensions of team performance as well: 1. There are 10 or fewer members of the team. 2. Members volunteer to serve on the team. 3. Members serve on the team from the time of concept development until product launch. 4. Members are assigned to the team full-time. 5. Members report directly to the team leader. 6. The key functions, including at least marketing, design, and manufacturing, are on the team. 7. Members are located within conversational distance of each other. While few teams are staffed and organized ideally, these criteria raise several key issues: How big should the team be? How should the team be organized relative to the larger enterprise? Which functions should be represented on the team? How can the development team of a very large project exhibit some of the agility of a small team? Here we address the issues related to team size. Chapter 1, Introduction, and Chapter 2, Development Processes and Organizations, address some of the other team and organizational issues.

The second set of guidelines is aimed at decreasing the time required to complete the tasks on the critical path. These guidelines arise from the fact that the only way to reduce the time required to complete a project is to shorten the critical path. Note that a decision 410 Chapter 19 to allocate additional resources to shortening the critical path should be based on the value of accelerating the entire project. For some projects, time reductions on the critical path can be worth hundreds of thousands, or even millions, of dollars per week

The traditional tool for representing the timing of tasks is the Gantt chart. Exhibit 19-4 shows a Gantt chart for the Cheetah project. The chart contains a horizontal time line created by drawing a horizontal bar representing the start and end of each task. The filled-in portion of each bar represents the fraction of the task that is complete. The vertical line in Exhibit 19-4 shows the current date, so we can observe directly that task D is behind schedule, while task E is ahead of schedule. A Gantt chart does not explicitly display the dependencies among tasks. Task dependencies constrain, but do not fully determine, the timing of the tasks. The dependencies dictate which tasks must be completed before others can begin (or finish, depending on the nature of the dependency) and which tasks can be completed in parallel. When two

This chapter contains five remaining sections. We first present the fundamentals of task dependencies and timing, along with three tools for representing relationships among project tasks. In the second section we show how these principles are used to develop an effective product development plan. In the third section we provide a set of guidelines for completing projects more quickly. After that, we discuss project execution, and finally we present a process for project evaluation and continuous improvement.

We have already introduced the idea that a project consists of a collection of tasks. The first step in planning a project is to list the tasks that make up the project. For most product development projects the team will not be able to list every task in great detail; too much uncertainty remains in the subsequent development activities; however, the team will be able to list its best estimate of the remaining tasks at a general level of detail. To be most useful during project planning, the task list should contain from 50 to 200 items.

We recommend that a contract book be used to document the project plan and the results of the concept development phase of the development process. The concept of a contract book is detailed by Wheelwright and Clark (1992). The word contract is used to emphasize that the document represents an agreement between the development team and the senior management of the company about project goals, direction, and resource requirements. The book is sometimes actually signed by the key team members and the senior managers of the company. A table of contents for a contract book is shown in Exhibit 19-6, along with references to the chapters in this book where some of these contents are discussed. Later we discuss elements of the project plan: the project task list, team staffing and organization, the project schedule, the project budget, and the project risk areas.

Weekly updates: The weekly status memo is written by the project leader and is distributed on paper, by e-mail, or even by voice mail to the entire extended project team, usually on Friday or over the weekend. The memo is usually one or two pages long and lists the key accomplishments, decisions, and events of the past week. It also lists the key events of the coming week. It is sometimes accompanied by an updated schedule.

among team members and enables more rapid completion of tasks. This is particularly true of teams that are not already colocated (although if the team is highly dispersed geographically, meetings can consume a great deal of travel time). Sometimes simply moving a weekly meeting from a Tuesday morning to a Friday afternoon increases the urgency felt by the team to "get it done this week." • Changing the project staff: The skills, capabilities, and commitment of the members of the project team in large measure determine project performance. When the project team is grossly understaffed, performance can sometimes be increased by adding the necessary staff. When the project team is overstaffed, performance can sometimes be

and to orchestrate the exchange of materials and information between individuals. It is therefore important that the schedule is viewed as credible by the entire project team. We recommend the following steps to create a baseline project schedule: 1. Use the DSM or PERT chart to identify the dependencies among tasks. 2. Position the key project milestones along a time line in a Gantt chart. 3. Schedule the tasks, considering the project staffing and other critical resources. 4. Adjust the timing of the milestones to be consistent with the time required for the tasks. Project milestones are useful as anchor points for the scheduling activity. Common milestones include design reviews (also called phase reviews or design gates), comprehensive prototypes (e.g., alpha prototype, beta prototype), and trade shows. Because these events typically require input from almost everyone on the development team, they serve as powerful forces for integration and act as anchor points on the schedule. Once the milestones are laid out on the schedule, the tasks can be arranged between these milestones. The Cheetah schedule was developed by expanding the typical project phases into a set of approximately 100 tasks. The major milestones were the concept approval, the testing of beta prototype cartridges, the trade show demonstration, and production ramp-up. Relationships among these activities and the critical path were documented using a combined PERT/Gantt chart.

fewer formal meetings than those whose members are geographically separated. Time spent exchanging information in meetings is time not spent completing other project tasks. To minimize the amount of time wasted in meetings, some teams that hold frequent meetings meet standing up to emphasize that the meeting is intended to be quick. Other techniques for controlling the length of meetings include preparing a written agenda, appointing someone to run the meeting, and holding the meeting just before lunchtime or near the end of the day when people are anxious to leave. We recommend that team meetings be held at a regular time and place so that no extra effort is expended in scheduling the meeting and in informing the team of its time and location.

he areas of risk for the project. To identify risks the team asks what uncertainties could affect the project's technical, financial, and schedule performance. Uncertainties may relate to task timing, technical developments, market acceptance, material costs, competition, and so on. After identifying each risk, the team can prioritize the risks. To do so, some teams use a scale combining severity and likelihood of each risk. A complete risk plan also includes a list of actions the team will take to minimize the risk. It is good project management practice to address the biggest risks as early as possible in the project. This is done by scheduling early actions to reduce the uncertainty underlying the high risks that have been identified. In addition to pushing the team to work to minimize risk, the explicit focus on risk during the project planning activity helps to minimize the number of surprises the team will have to communicate to its senior management later in the project. The risk plan for the Cheetah project is shown in Exhibit 19-10.

identified by above-diagonal marks. Exhibit 19-3 shows how the DSM reveals all three types of relationships. More sophisticated use of the DSM method has been a subject of research at MIT since the 1990s. Much of this work has applied the method to larger projects and to the development of complex systems such as automobiles and airplanes. Analytical methods have been developed to help understand the effects of complex task coupling, to predict the distribution of possible project completion times and costs, and to help plan organization designs based on product architectures (Eppinger and Browning, 2012). DSM practitioners have found that creative uses of the DSM's graphical display of project task relationships can be highly insightful for project managers in both the planning and execution phases. The chapter appendix presents a larger DSM model in which several overlapping phases of coupled development activities are represented.

increased by removing staff. Note that adding staff in a panic at the end of a project can lead to delays in project completion because the increased coordination requirements may outweigh the increase in human resources. • Locating the team together physically: If the team is geographically dispersed, one way to increase project performance is to locate the team in the same work space. This action invariably increases communication among the team members. Some benefit of "virtual colocation" is possible with e-mail, video conferencing, and other networkbased collaboration tools.

tasks overlap in time on a Gantt chart, they may be parallel, sequential, or iteratively coupled. Parallel tasks can be overlapped in time for convenience in project scheduling because they do not depend on one another. Sequential tasks might be overlapped in time, depending on the exact nature of the information dependency, as described later in the section on accelerating projects. Coupled tasks must be overlapped in time because they need to be addressed simultaneously or in an iterative fashion.

time for the entire set of tasks. Consider for example the Cheetah project represented in Exhibit 19-5. Either the sequence C-D-F or the sequence C-E-F defines how much time is required to complete the four tasks C, D, E, and F. In this case, the path C-D-F requires 18 weeks and the path C-E-F requires 15 weeks, so the critical path for the whole project includes C-D-F. The critical path for the project is denoted by the thick lines in Exhibit 19-5. Identifying the critical path is important because a delay in any of these critical tasks would result in an increase in project duration. All other paths contain some slack, meaning that a delay in one of the noncritical tasks does not necessarily create a delay for the entire project. Exhibit 19-4 shows that task D is behind schedule. Because task D is on the critical path, this delay, if not corrected, will result in a delay of the completion of the entire project. Several software packages are available for producing Gantt charts and PERT charts; these programs can also compute the critical path.

• Complete individual tasks on the critical path more quickly. The benefit of recognizing the critical path is that the team can focus its efforts on this vital sequence of tasks. The critical path generally represents only a small fraction of the total project effort, and so additional spending on completing a critical task more quickly can usually quite easily be justified. Sometimes completing critical tasks more quickly can be achieved simply by identifying a task as critical so that it gets special attention, starts earlier, and is not interrupted. Note that the accelerated completion of a critical task may cause the critical path to shift to include previously noncritical tasks.

• Eliminate some critical path tasks entirely. Scrutinize each and every task on the critical path and ask whether it can be removed or accomplished in another way. • Eliminate waiting delays for critical path resources. Tasks on the critical path are sometimes delayed by waiting for a busy resource. The waiting time is frequently longer than the actual time required to complete the task. Delays due to waiting are particularly prominent when procuring special components from suppliers. Sometimes such delays can be avoided by ordering an assortment of materials and components to be sure to have the right items on hand, or by purchasing a fraction of the capacity of a vendor's production system to expedite the fabrication of prototype parts. These expenses may make perfect economic sense in the context of the overall development project, even though the expenditure may seem extravagant when viewed in isolation. In other cases, administrative tasks such as purchase order approvals may become bottlenecks. Because in past cartridge development projects periodic budget approvals had caused delays, the Cheetah project leader began early to pursue aggressively the necessary signatures so as not to hold up the activities of the entire team.

• Empowerment of a team leader. • Effective team problem solving. • Emphasis on adherence to schedule. • Effective communication links. • Full participation from multiple functions. • Building on prior experience in cartridge development. • Use of computer-aided design (CAD) tools for communication and analysis. • Early understanding of manufacturing capabilities. The Cheetah team also identified a few opportunities for improvement: • Use of 3D CAD tools and plastic molding analysis tools. • Earlier participation by the customer in the design decisions. • Improved integration of tooling design and production system design

• Overlap selected critical tasks. By scrutinizing the relationships between sequentially dependent tasks on the critical path, the tasks can sometimes be overlapped or executed in parallel. In some cases, this may require a significant redefinition of the tasks or even changes to the architecture of the product. (See Chapter 10, Product Architecture, for more details on dependencies arising from the architecture of the product.) In other cases, overlapping entails simply transferring partial information earlier and/or more frequently between nominally sequential tasks or freezing the critical upstream information earlier. Krishnan (1996) provides a framework for choosing various overlapping strategies

• Schedule display: The most important information system in project execution is the project schedule, usually in the form of a PERT or Gantt chart. Most successful projects have a single person who is responsible for monitoring the schedule. On small projects, this is usually the team leader. Larger projects generally have a designated person other than the project leader who watches and updates the schedule regularly. On the Cheetah project, Kodak provided a part-time project analyst who kept the schedule current on a weekly basis and reported to the project team leader. The team members understood the importance of accurate schedule projections and were very cooperative in this effort. Schedule updates are usually displayed in Gantt chart form (Exhibit 19-4).

Product Design 19

Ensembles d'études connexes

Module 8- Exam

CHM 123 Lab Exam 1

OB 7

Body Structure and Function Chapter 16 Study Guide

RMI Exam

Motor learning chapter 9

SYE Life Law final

Ch 8 the cost of taxation

Chapter 10

Physical Activity Benefits: Practice

Chapter 20: Drug Therapy With Tetracyclines, Sulfonamides, and Urinary Antiseptics (pharm)

state local government

Chapter 19- AC motors

Entrepreneurship Test 1 (chapters 1-5)

GA LAW SUPPLEMENT

ATI - Head Neck, & Neurological

Immnunology

RN- NCLEX QUESTIONS IMMUNITY

psych 205 final - chapter 15

Chapter 19