Once senior management has decided to fund a major project, or a highly important small project, a project launch meeting should be called. Preparation for this meeting is required (Knutson, 1995; Martin and Tate, 1998).

When a PM is appointed to head a new project, the PM's first job is to review the project objectives (project scope plus expected desirable outcomes that accrue to stakeholders from matters beyond the project's deliverables) with the senior manager who has fundamental responsibility for the project. The purpose of this interview is threefold: (1) to make sure that the PM understands the expectations that the organization, the client, and other stakeholders have for the project; (2) to identify those among the senior managers (in addition to the manager who is party to this interview) who have a major interest in the project; and (3) to determine if anything about the project is atypical for projects of the same general kind (e.g., a product/service development project undertaken in order to extend the firm's market into a new area).

Armed with this background, the PM should briefly study the project with an eye to preparing an invitation list for the project launch meeting. At the top of the list should be at least one representative of senior management, a strong preference given to the individual with the strongest interest in the project, the probable project champion. (The champion is usually, but not necessarily, the senior manager with responsibility for the project.) Recall in Chapter 2 we noted that the project champion could lend the political clout that is occasionally needed to overcome obstacles to cooperation from functional managers—if such obstacles were not amenable to dissolution by the PM.

Next on the invitation list come the managers from the functional areas that will be called upon to contribute competencies or capacities to the project. If highly specialized technical experts will be needed, the PM can add individuals with the required expertise to the list, after clearing the invitation with their immediate bosses, of course.

The PM may chair the launch meeting, but the senior manager introduces the project to the group, and discusses its contributions to the parent organization. If known and relevant, the project's tentative priority may be announced, as should the tentative budget estimate used in the project selection process. If the due dates for deliverables have been contracted, this should also be made clear. The purpose of senior management's presence is to ensure that the group understands the firm's commitment to the project. It is particularly important for the functional managers to understand that management is making a real commitment, not merely paying lip service.

At this point, the PM can take over the meeting and begin a group discussion of the project. It is, however, important for the senior manager(s) to remain for this discussion. The continuing presence of these august persons more or less assures cooperation from the functional units. The purpose of the discussion is to develop a general understanding of what functional inputs the project will need.

Some launch meetings are restricted to brainstorming a problem. The output of such a meeting is shown in Table 3-1. In this case, the Director of Human Resources (HR) of a medium-size firm was asked by the Board of Directors to set up a program to improve employee retention. At the time, the firm had a turnover rate slightly above 60 percent per year among its technical employees. (A turnover rate of 50 percent was about average for the industry.) The HR Director held a launch meeting of all department heads, all senior corporate officers, and members of the Board. At this meeting, the group developed a list of "action items," each of which became a project.

When dealing with a single project, it is common for a preliminary plan to be generated at the launch meeting, but we question the advisability of this. For either functional managers or the PM to guess at budgets or schedules with no real study of the project's deliverables is not prudent. First, the transition from a "tentative, wild guesstimate" made by senior managers or the EPMO to "but you promised" is instantaneous in these cases. Second, there is no foundation for mutual discussion or negotiation about different positions taken publicly and based on so little knowledge or thought. It is sufficient, in our judgment, to get a firm commitment from functional managers to study the proposed project and return for another meeting with a technically (and politically) feasible plan for their group's input to the project.

It has been said, "If this means many planning meetings and extensive use of participatory decision making, then it is well worth the effort (Ford and McLaughlin, 1992, p. 316). If the emphasis is on "participative decision making," we agree. Actual planning at the launch meeting should not go beyond the most aggregated level unless the deliverables are well understood or the delivery date is cast in concrete and the organization has considerable experience with similar projects. Of course, if this is the case, a major launch meeting may not be required.

The results of the launch meeting should be that: (1) the project's scope is understood and temporarily fixed; (2) the various functional managers understand their responsibilities and have committed to develop an initial task and resource plan; and (3) any potential benefits to the organization outside the scope of the project are noted. In the meetings that follow, the project plan will become more and more detailed and firmer. When the group has developed what appears to be a workable plan with a schedule and budget that seem feasible, the plan moves through the appropriate management levels where it is approved, or altered and approved. If altered, it must be checked with those who did the planning. The planners may accept the alterations or a counterproposal may be made. The project plan may cycle up and down the managerial ladder several times before it receives final approval, at which time no further changes may be made without a formal change order (a procedure also described in the plan).

Irrespective of who alters (or suggests alterations to) the project plan during the process described above, it is imperative that everyone be kept fully informed. It is no more equitable for a senior manager to change a plan without consultation with the PM (and, hence, the project team) than it would be for the PM or the team to alter the plan without consultation and approval from senior management. If an arm's-length client is involved, the client's approval is required for any changes that will have an effect on the schedule, cost, or deliverable. Clearly, the PMO (or EPMO) can facilitate this process.

Open, honest, and frequent communication between the interested parties is critical for successful planning. What emerges from this process is sometimes called the project baseline plan. It contains all the nine elements noted in Section 3.1 and all amendments to the plan adopted as the project is carried out. As noted above, when senior management, the client, and other stakeholders have "signed-off" on the plan, it becomes a part of the Project Charter, a contract-1ike document affirming that all major parties-at-interest to the project are in agreement on the deliverables, the cost, and the schedule.

Inadequate up-front planning, especially failing to identify all important tasks, is a primary contributor to the failure of a project to achieve its cost and time objectives. Therefore, a primary purpose for developing a WBS is to ensure that any task required to produce a deliverable is not overlooked and thereby not accounted for and planned.

The previous subsection discussed the planning process as seen from the outside. The PM and the functional managers developed plans as if by magic. It is now time to be specific about how such plans may be generated. In order to develop a project plan that will take us from start to finish of a project, we need to know precisely what must be done, by whom, when, and with what resources. Every task, however small, that must be completed in order to complete the project should be listed together with any required material or human resources.

Making such a list is a nontrivial job. It requires a systematic procedure. While there are several systematic procedures that may be used, we advise a straightforward and conceptually simple way to attack the problem—the hierarchical planning process— which is how to build a Work Breakdown Structure (WBS) for the project.

To use this process, one must start with the project's objective(s). The planner, often the PM, makes a list of the major activities that must be completed to achieve the objective(s). The list may be as short as two or three activities, or as large as 20. Usually the number is between 5 and 15. We call these Level 1 activities. The planner now takes each Level 1 activity and delegates it to an individual or functional group. (The PM might delegate one or more Level 1 tasks to him- or herself.) The delegatee deals with the task as if it is itself a project and makes a plan to accomplish it; that is, he or she lists a specific set of Level 2 tasks required to complete each Level 1 task. Again, the breakdown typically runs between 5 and 15 tasks, but a few more or less does not matter. The process continues. For each Level 2 task, someone or some group is delegated responsibility to prepare an action plan of Level 3 subtasks. The procedure of successively decomposing larger tasks into their component parts continues until the lowest level subtasks are sufficiently understood so that there is no reason to continue. As a rule of thumb, the lowest level tasks in a typical project will have a duration of a few hours to a few days. If the team is quite familiar with the work, longer durations are acceptable for the lowest level tasks.

Another simple approach to creating the WBS begins by gathering the project team together and providing each member with a pad of sticky-notes. After defining the project's objectives, and Level 1 tasks, team members then write on the sticky-notes all the tasks they can think of that are required to complete the project. The sticky-notes can then be placed on the wall and arranged in various ways. One advantage of this approach is that it provides the entire team with a better understanding of the work needed to complete the project. The fact that it is a cooperative exercise also helps the project team to bond. Finally, this exercise can generate a WBS tree. Figure 3-1 illustrates the tree. A colleague called this a "Gozinto chart." (He said it was named after a famous Italian mathematician, Prof. Zepartzat Gozinto. The name has stuck.)

Microsoft Project (MSP) will make a WBS list (but not a tree-chart) at the touch of a key. The task levels are appropriately identified; for example, the WBS number "7.5.4" refers to the "Level 3, task Number 4" that is needed for "Level 2, task 5" that is a part of "Level 1, task 7." (The PM has the option of using any other identification system desired, but must enter the identifiers manually.)

Task levels are appropriately organized on the MSP printout, with Level 1 tasks to the left and others indented by level. If one uses a tree diagram and each task is represented by a box with the WBS identifier number, one can add any information one wishes—given that it will fit in the box. Such an entry might be the proper account number to charge for work done on that task, or the name of the individual (or department) with task responsibility, or with a space for the responsible party's signature denoting that the person has accepted accountability by "signing-off. " As we will see, additional information is often added by turning the "tree" into a list with columns for the additional data.

Figure 3.1. A partial WBS (Gozinto chart) for an Annual Tribute Dinner project.

1n doing hierarchical planning, only one rule appears to be mandatory. At any given level, the "generality" or "degree of detail" of the tasks should be roughly at the same level. One should not use highly detailed tasks for Level 1 plans, and one should not add very general tasks at Level 3 or more. This can best be done by finding all Level 2 subtasks for each Level 1 task before moving one's attention to the Level 3 subtasks. Similarly, break all Level 2 tasks into their respective Level 3 tasks before considering any Level 4 subtasks, if the breakdown proceeds that far. A friend of ours who was an internationally known artist and teacher of industrial design explained why. When producing a painting or drawing, an artist first sketches-in the main compositional lines in the scene. The artist then adds detail, bit by bit, over the whole drawing, continuing this process until the work is completed. If this is done, the finished work will have "unity." Unity is not achieved if individual areas of the picture are completed in detail before moving on to other areas. A young art student then made a pen-and-ink sketch of a fellow student, showing her progress at three different stages (see Figure 3-2).

We have said that the breakdown of Level 1 tasks should be delegated to someone who will carry out the Level 2 tasks. It is the same with Level 2 tasks being delegated to someone who will design and carry out the required Level 3 tasks. A relevant question is "Who are all these delegatees?" Let's assume that the project in question is of reasonable size, neither very large nor small. Assume further that the PM and the functional managers are reasonably experienced in dealing with similar projects. In such a case, the PM would probably start by working on Level 1. Based on her background, the PM might work on Level 2 of one or more of the Level 1 tasks. Where recent experience was missing, she would delegate to the proper functional manager the task of specifying the Level 2 tasks. In the same way, the latter would delegate Level 3 task specification to the people who have the appropriate knowledge.

Figure 3.2. Three levels of detail in hierarchical planning.

In general, the job of planning should be delegated to the lowest competent level. At Level 1, this is usually the PM. At lower levels, functional managers and specialists are the best planners. In Chapter 2 (Section 2.1) we described that strange bugbear, the micromanager. It is common for micromanagers to preempt the planning function from subordinates or, as an alternative, to allow the subordinate to develop an initial plan that the micromanager will amend with potentially disastrous results. The latter is an event reported with some frequency (and accuracy) in Dilbert©.

The WBS can be reshaped and buttressed with some additional data often not included in the project's WBS. The WBS is generally oriented toward the project's deliverables. The additions increase its orientation toward the planning and administration of the work. It does this by using available material, while adopting a format that is not typically used by the WBS. Figure 3-3 illustrates a layout that helps to organize the required information. We refer to these layouts as "modified" WBSs. The additional data in the columns are: (1) estimates of the resources required for each task in the plan, (2) the estimated time required to accomplish each task, (3) information about who has responsibility for the task, and (4) data that will allow tasks to be sequenced so that the set may be completed in the shortest possible time. Once the project starting date is known, item 2 in the preceding list may be changed from the time required for a subtask completion to the date on which the subtask is scheduled for completion.

To understand the importance of item 4 in the list, consider a set of subtasks, all of which must be completed to accomplish a parent task on a higher level. It is common in such a set that one or more subtasks (A) must be completed before one or more other subtasks (B) may be started. The former tasks (A) are said to be predecessors of the successor tasks (B). For instance, if our project is to paint the walls of a room, we know that before we apply paint to a wall, we must do a number of predecessor tasks. These predecessors include: clear the floor area near the wall to be painted and cover with drop cloths; remove pictures from the wall; clean loose dirt, oil, grease, stains, and the like from the wall; fill and smooth any cracks or holes in the wall; lightly sand or score the wall if it has previously been painted with a high-gloss paint; wipe with a damp cloth or sponge to remove dust from the sanding; and mask any surrounding areas where this paint is not wanted. All these tasks are predecessors to the task "Paint the walls."

The predecessor tasks for "paint the walls" have been listed in the order in which they might be done if only one person was working. If several people are available, several of these tasks might be done at the same time. Note that if three tasks can be done simultaneously, the total elapsed time required is the time needed for the longest of the three, not the sum of the three task times. This notion is critical for scheduling, so predecessors must be listed in the WBS. One convention is important. When listing predecessors, only the immediate predecessors are listed. If A precedes B and B precedes C, only B is a predecessor of C.

Figure 3.3. A form to assist hierarchical planning.

While Table 3-1 illustrates the output of a project launch meeting (more accurately a program launch meeting), Table 3-2 shows a WBS for one of the action items resulting from the launch meeting. With the exception of tasks 3 and 4, it is a Level 1 plan. Three Level 2 items are shown for tasks 3 and 4. Because the HR Director is quite familiar with such projects, violating the one-level-only rule is forgivable. Note also that the HR Director has delegated some of the work to himself. Note also that instead of assumptions being shown at the beginning of the WBS, project evaluation measures were listed.

The WBS not only identifies the deliverable, but also may note the start date if it is known or other information one wishes to show. Once the subtasks and their predecessors have been listed along with the estimated subtask activity times, the probable duration for the set of subtasks, and thus the task due date, can be determined as we will see in Chapter 5. If the estimates for the durations and resource requirements for accomplishing the subtasks are subject to constraints (e.g., no overtime work is allowed) or assumptions (e.g., there will be no work stoppage at our subcontractor's plant), these should be noted in the WBS.

If one wishes, the information in the form shown in Figure 3-2 can be entered directly into Microsoft Project® (MSP). Alternatively, one can produce a WBS using MSP, directly, as shown in Figure 3-4. The project title can be entered in a header or footer to the form, as can other information such as a brief description of the deliverables, the name of the PM or the task manager, the project start and/or due dates, and the like.

Table 3-3 shows a WBS generated on MSP with task durations, and start and finish times for the Level 1 tasks in an infection control project. The project begins on September 12 and ends on November 30. As is customary, people work a five-day week so a three-week task has 15 work days and 21 calendar days (three weeks), assuming that the individual or team is working full-time on the task. As we will see in Chapter 5, one usually dares not make that assumption and should check carefully to determine whether or not it is a fact. If the one performing the task is working part-time, a task that requires five days of work, for example, may require several weeks of calendar time. We will revisit this problem in Chapter 5.

MSP makes the task of Level 1 planning of the broad project tasks quite straightforward. The same is true when the planners wish to generate a more detailed listing of all the steps involved in a project. The PM merely lists the overall tasks identified by the planning team as the activities required to produce the project deliverables—for example, the output of a brainstorming session. The PM and the planning team can then estimate task durations and use MSP to create a WBS. Table 3-4 shows a planning template used by a software company when they have their initial project brainstorming meetings about delivering on a customer request.

Figure 3.4. A WBS as an output of MSP.

MSP has a planning wizard that guides the PM through the process of identifying all that is necessary to take an idea for a project activity and turn it into a useful WBS.

Table 3-5 is an example of a template developed by a computer systems support company. Company planners repeatedly performed the same steps when clients would ask for a local area network (LAN) installation. They treated each job as if it were a new project, because costs and resource assignments varied with each assignment. To improve efficiency, they developed a planning template using MSP. After meeting with a client, the project manager could add the agreed-upon project start date, and any constraints on the schedule required by the client. The steps to install the LAN remained the same. The start and finish dates, and the number of resources needed to meet the schedule were adjusted for each individual client, but the adjustments were usually small. Once the schedule of a specific job was decided, the PM could determine the resources needed to meet that schedule and find the cost of the project.

Creating this kind of template is simple. The software can calculate the cost of each different project which is most helpful to the project manager if cost, prices, or schedules must be negotiated. If the client wants the project to be completed earlier than scheduled, the PM can add the additional resources needed and project management software can determine the costs associated with the change.

If the PM wishes to include other information in the project's modified WBS, there is no reason not to do so. Some include a column to list the status of resource or personnel availability. Others list task start dates.

Like the WBS, the RACI Matrix comes in a variety of sizes and shapes. Typically, the RACI matrix is in the form of a table with the project tasks derived from the WBS listed in the rows and departments or individuals in the columns. The value of the RACI Matrix is that it helps organize the project team by clarifying the responsibilities of the project team members. For an example of a simple RACI Matrix, see Figure 3-5.

Figure 3.5. A RACI Matrix.

In Figure 3-5 letters are used to indicate the nature of the responsibility link between a person and a task. Note that there must be at least one A in every row, which means that someone must be accountable for completion of each task. For example, examine the row with the task "Solicit quotations." In this case the Project Engineer is accountable for the task being carried out while the Field Manager will be responsible for actually doing the work associated with soliciting quotations. The project's Contract Administrator and the Compliance Officer/Risk Manager must be consulted about the solicitation process. The PM must be informed before documents are sent to potential vendors. Note that a particular individual or department can be assigned multiple responsibility links. For example, it is common for a person to be both accountable and responsible for a particular task. Other common combinations include consulted/ informed and accountable/informed.

Standard RACI Matrix templates are available to facilitate their development. One can use symbols or numbers as opposed to letters to refer to different responsibility relationships, and the references may be to departments, job titles, or names. Only imagination and the needs of the project and PM bound the potential variety. Likewise, additional columns can be added to the RACI Matrix to capture the due dates of tasks, actual dates completed, the status of tasks, performance metrics, and so on.

A final observation is needed on this subject. When we speak to functional managers about project management, one comment we often hear is anger about changes in the project plan without notification to the people who are supposed to conduct the tasks or supply services to the project. One quote from the head of a statistics lab in a large consulting firm is typical. The head of the lab was speaking of the manager of a consulting project for a governmental agency when he said, "I pulled three of my best people off other work to reserve them for data analysis on the XYZ Project. They sat for days waiting for the data. That jerk [the PM] knew the data would be late and never bothered to let me know. Then the *%$#@% had the gall to come in here and ask me to speed up our analysis so he could make up lost time."

Make sure to use the Inform category, not simply to report progress, but also to report changes in due dates, resource requirements, and the like.

In today's fiercely competitive environment, project teams are facing increasing pressure to achieve project performance goals while at the same time completing their projects on time and on schedule. Typically project managers and project team members rely on the "left" side or the analytical part of the brain to address the challenges. Indeed, if you are a business or engineering student, the vast majority of techniques that you have been exposed to in your studies relies on the logical and analytical left side of your brain. On the other hand, art students and design students tend to be exposed to techniques that rely more on imagination and images which utilize the creative "right" side of the brain. Importantly, many activities associated with project management can be greatly facilitated through the use of a more balanced whole-brain approach (Brown and Hyer, 2002).

One whole-brain approach that is particularly applicable to project management in general, and project planning in particular, is mind mapping. Mind mapping is essentially a visual approach that closely mirrors how the human brain records and stores information. In addition to its visual nature, another key advantage associated with mind mapping is that it helps tap the creative potential of the entire project team, which, in turn, helps increase both the quantity and quality of ideas generated. Because project team members tend to find mind mapping entertaining, it also helps generate enthusiasm, helps get buy-in from team members, and often gets quieter team members more involved in the process.

To illustrate the creation of a mind map, consider a project launched at a graduate business school to improve its part-time evening MBA program for working professionals. The mind mapping exercise is initiated by taping a large sheet of paper (e.g., 6 ft × 3 ft) on a wall. (One good source of such paper is a roll of butcher's wrapping paper. Several sheets can be taped together to create a larger area if needed.) It is recommended that the paper be oriented in landscape mode to help stimulate the team's creativity as people are used to working in portrait mode. In addition, team members should stand during the mind mapping exercise.

The process begins by writing the project goal in the center of the page. As is illustrated in Figure 3-6, the part-time MBA project team defined the goal for the project as generating ideas for breakthrough performance in the part-time MBA program. In particular, notice the inspirational language used in defining the project goal which helps further motivate team members and stimulate their creativity.

Once the project goal is defined, team members can brainstorm to identify the major tasks that must be done to accomplish this goal. In developing the mind map for the project, the MBA team initially identified four major tasks: (1) define the role of working professional programs (WPPs), (2) generate ideas for improving current programs, (3) generate ideas for diversification, and (4) evaluate the ideas generated. As illustrated in Figure 3-7, these major tasks branch off from the project goal.

Figure 3.6. Begin mind mapping with statement of project's objective.

Figure 3.7. Major tasks branch off from project goal.

Figure 3.8. Major tasks are further broken down into more detailed tasks.

Developing the mind map proceeds in this fashion whereby components in the mind map are continuously broken down into more detailed tasks. For example, Figure 3-8 illustrates how the define role of the WPPs task was broken down into more detailed tasks. Figure 3-9 provides the final map for the MBA project.

A couple of comments regarding the process of mind mapping are in order. First, color, word size, word shape, and pictures should all be used to add emphasis. In fact, team members should be encouraged to use pictures and images in the mind map over using words. The brain processes and responds to symbols and pictures differently than it does to words. When using words, key words as opposed to full sentences should be used. Also, it should be noted that it is OK to be messy when developing the original mind map. Indeed, one should not expect the original mind map to resemble something as polished as the mind map shown in Figure 3-9. Rather, the mind map will typically need to go through several iterations of polishing and refining. It should also be noted that the polishing and refining can be greatly facilitated with the use of a computer graphics program.

In addition, multiple team members can and should contribute to the mind map simultaneously. In fact, one team member should be formally designated as the facilitator to ensure that all team members are contributing to keep team members focused on the project, and to ensure that team members are focusing on project tasks—not goals. Finally, at the most detailed level, tasks should be expressed using a noun and a verb (e.g., develop measures, generate ideas, define output).

Unfortunately, it is all too common for projects to go over budget and/or be completed late. In many cases insufficient upfront planning is the major culprit. With inadequate upfront planning, important tasks are overlooked, which in turn results in underestimating the project budget and duration. Mind mapping is a fast and effective tool that can greatly facilitate project planning and help minimize problems that result from inadequate upfront planning.

Figure 3.9. Final mind map for part-time MBA program project.

A polished and refined mind map facilitates a number of other project-related activities. For example, the mind map can be easily converted into the traditional WBS. Furthermore, the mind map can be used to facilitate risk analysis, setting project team meeting agendas, allocating resources to project activities, and developing the project schedule (see Brown and Hyer, 2002, for additional details on the use of mind mapping for project management).

The problems of integration management are easily understood if we consider the traditional way in which products and services were designed and brought to market. The different groups involved in a product design project, for example, did not work together. They worked independently and sequentially. First, the product design group developed a design that seemed to meet the marketing group's specifications. This design was submitted to top management for approval, and possible redesign if needed. When the design was accepted, a prototype was constructed. The project was then transferred to the engineering group who tested the prototype product for quality, reliability, manufacturability, and possibly altered the design to use less expensive materials. There were certain to be changes, and all changes were submitted for management approval, at which time a new prototype was constructed and subjected to testing.

After qualifying on all tests, the project moved to the manufacturing group who proceeded to plan the actual steps required to manufacture the product in the most cost-effective way, given the machinery and equipment currently available. Again, changes were submitted for approval, often to speed up or improve the production process. If the project proceeded to the production stage, distribution channels had to be arranged, packaging designed and produced, marketing strategies developed, advertising campaigns developed, and the product shipped to the distribution centers for sale and delivery.

Conflicts between the various functional groups were legend. Each group tried to optimize its contribution, which led to nonoptimization for the system. This process worked reasonably well, if haltingly, in the past, but was extremely time consuming and expensive—conditions not tolerable in today's competitive environment.

To solve these problems, the entire project was changed from one that proceeded sequentially through each of the steps from design to sale, to one where the steps were carried out concurrently. Parallel tasking (a.k.a. concurrent engineering or simultaneous engineering) was invented as a response to the time and cost associated with the traditional method. (The word "engineering" is used here in a generic sense.) Many years before the General Motors example noted near the beginning of Chapter 2, Section 2.6, Chrysler used parallel tasking to make their PT Cruiser ready for sale in Japan four months after it was introduced in the United States. U.S. automobile manufacturers usually took about three years to modify a car or truck for the Japanese market (Autoweek, May 22, 2000, p. 9). Possibly, "PT" for parallel tasking was the source of PT for the Cruiser.

Parallel tasking has been widely used for a great diversity of projects. For example, PT was used in the design and marketing of services by a social agency; to design, manufacture, and distribute ladies' sportswear; to design, plan, and carry out a campaign for political office; to plan the maintenance schedule for a public utility; and to design and construct the space shuttle. Parallel tasking has been generally adopted as the proper way to tackle problems that are multidisciplinary in nature.

Monte Peterson, CEO of Thermos (now a subsidiary of Nippon Sanso, Inc.), formed a flexible interdisciplinary team with representatives from marketing, manufacturing, engineering, and finance to develop a new grill that would stand out in the market. The interdisciplinary approach was used primarily to reduce the time required to complete the project. For example, by including the manufacturing people in the design process from the beginning, the team avoided some costly mistakes later on. Initially, for instance, the designers opted for tapered legs on the grill. However, after manufacturing explained at an early meeting that tapered legs would have to be custom made, the design engineers changed the design to straight legs. Under the previous system, manufacturing would not have known about the problem with the tapered legs until the design was completed. The output of this project was a revolutionary electric grill that used a new technology to give food a barbecued taste. The grill won four design awards in its first year.

The word "engineering" is used in its broadest sense, that is, the art of making practical application of science. Precisely which sciences is not specified. If the team members are problem oriented, parallel tasking works very well. Some interesting research has shown that when problem-oriented people with different backgrounds enter conflicts about how to deal with a problem, they often produce very creative solutions— and without damage to project quality, cost, or schedule (Hauptman and Hirji, 1996, p. 161). The group itself typically resolves the conflicts arising in such cases when they recognize that they have solved the problem. For some highly effective teams, conflict becomes a favored style of problem solving (Lencioni, 2002).

When team members are both argumentative and oriented to their own discipline, parallel tasking appears to be no improvement on any other method of problem solving. The PM will have to use negotiation, persuasion, and conflict resolution skills, but there is no guarantee that these will be successful. Even when intragroup conflict is not a serious issue with discipline-oriented team members, they often adopt subopti-mization as the preferred approach to problem solving. They argue that experts should be allowed to exercise their specialties without interference from those who lack expertise.

The use of MTs in product development and planning is not without its difficulties. Successfully involving transfunctional teams in project planning requires that some structure be imposed on the planning process. The most common structure is simply to define the group's responsibility as being the development of a plan to accomplish whatever is established as the project objective. There is considerable evidence, however, that this will not prevent conflict on complex projects.

One of the PM's more difficult problems when working with MTs is coordinating the work of different functional groups interacting as team members. The team members come from different functional areas and often are not used to dealing with one another directly. For the most part, they have no established dependencies on each other and being co-members of a team is not sufficient to cause them to associate—unless the team has a mission that makes it important for the members to develop relationships.

One approach to the problem of interface coordination is to expose the structure of the work assigned to the team (Bailetti, Callahan, and DiPietro, 1994). One can identify and map the interdependencies between various members of the project team. Clearly, the way in which team members interact will differ during different phases of the project's work, so each major phase must be mapped separately. Figure 3-10 shows the mapping for the design of a silicon chip.

The logic of this approach to structuring MTs is reasonable. The original project plans and charts are a good initial source of information on interfaces, but project plans change during the execution of a large, complex project. Further, project plans assume, implicitly, that interfaces somehow change automatically during the different project phases—an assumption generally contrary to fact. This does not ignore the value of standard project planning and control tools of long-standing use; it simply uses interface maps to develop the coordination required to manage the interdependencies. The fundamental structure of this approach to interface management is shown in Figure 3-11.

Figure 3.10. An interface mapping of a silicon chip design project (Bailetti, Callahan, and DiPietro, 1994).

No approach to interface coordination and management, taken alone, is sufficient. Mapping interfaces does not tell the PM what to do. The maps do, however, indicate which interfaces have a high potential for trouble. As usual, populating the project team with problem-oriented people will help. If a team member is strongly oriented toward making the project a success, rather than optimizing his or her individual contribution, it will be relatively easy for the PM to identify troublesome interfaces between members of the project team.

One observation that can be made regarding integration management and parallel tasking is that both are fundamentally concerned with coordinating the flow of information. Furthermore, while the need to coordinate the flow of information is a challenge that confronts virtually all projects, the use of MTs tends to magnify this challenge. This is particularly true for new product development projects.

Compounding this problem is the fact that traditional project management planning tools such as Gantt charts and precedence diagrams (both discussed in Chapter 5) were developed primarily to coordinate the execution of tasks. This is because these tools were originally developed to help manage large but relatively well structured projects such as construction projects and ship building. However, in some cases such as new product development projects, the issue of information flows can be as important as the sequencing of tasks. In essence, traditional project management planning tools help identify which tasks have to be completed in order for other tasks to be started. Often, however, a more important issue is what information is needed from other tasks to complete a specific task?

Figure 3.11. A coordination structure model for project management (Bailetti, Callahan, and DiPietro, 1994).

To address the issue of information flows, Steven Eppinger (2001), a professor at MIT's Sloan School of Management, proposes the development and use of a Design Structure Matrix (DSM). The first step in developing a DSM is to identify all the project's tasks and list them in the order in which they are typically carried out. This list of tasks makes up both the rows and columns of the DSM. Next, moving across one row at a time, all tasks that supply information to the task being evaluated are noted. When the DSM is completed, all the tasks that provide information that is needed to complete a given task can be determined by looking across that particular task's row. Likewise, moving down a particular task's column shows all the other tasks that depend on it for information.

An example DSM corresponding to a project with six activities is shown in Table 3-6. According to the table, completing activity c requires the gathering of information from activities b and f. Furthermore, the table indicates that activities c and f both depend on information from activity b.

As the example illustrates, a key benefit of constructing a DSM is the ability to quickly identify and better understand how information is needed. It can also highlight potential information flow problems even before the project is started. For example, all the X's above the diagonal in Table 3-6 are related to situations where information obtained from a subsequent task might require the rework of an earlier completed task. To illustrate, in the second row we observe that activity b requires information from activity e. Since activity e is completed after activity b, activity b may need to be revisited and reworked depending on what is learned after completing activity e.

The DSM also helps evaluate how well the need to coordinate information flows has been anticipated in the project's planning stage. To make this assessment, a shaded box is added to the DSM around all tasks that are planned to be executed concurrently. For example, the DSM would appear as shown in Table 3-7 if it had been planned that tasks c, d, and e were to be done concurrently. Also notice that in Table 3-7 any remaining entries above the diagonal of the matrix are highlighted as potential rework by replacing each X with an O.

In examining Table 3-7 there are two potential rework situations. Fortunately, there are a couple of actions that can be taken to minimize or even eliminate potential rework situations. One option is to investigate whether the sequence of the project activities can be changed so that the potential rework situations are moved below the diagonal. Another option is to investigate ways to complete additional activities concurrently. This latter option is a bit more complex and may necessitate changing the physical location of where the tasks are completed.

Table 3.6. Example DSM for Project with Six Activities

Table 3.7. Modified DSM to Show Activities to Be Completed Concurrently

The use of a participatory management style has been, and will continue to be, emphasized in this book. In recent years several programs have been developed to institutionalize the participative style. Among these programs are Employee Involvement (EI), Six Sigma (SS), Quality Circles (QC), Total Quality Management (TQM), Self-Directed Work Teams (SDWT) [a.k.a. Self-Directed Teams (SDT) by dropping the word "work," which is what SDTs sometimes do], and Self-Managed Teams (SMT). While these programs differ somewhat in structure and in the degree to which authority is delegated to the team, they are all intended to empower workers to use their knowledge and creativity to improve products, services, and production processes.

There is no doubt that some of these teams meet their goals, and there is also no doubt that many of them do not. Research on the effectiveness of these programs yields mixed results (Bailey, 1998). The research (and our experience supports this) leads to the tentative conclusion that the success or failure of empowerment teams probably has more to do with the way in which the team program is implemented than with the team itself. When empowerment team programs are implemented with a well-designed plan for involvement in solving actual problems, and when the teams have full access to all relevant information plus full support from senior management, the results seem to be quite good. When those conditions are not present, the results are mediocre at best.

Some of the more important advantages of empowerment are:

All of these advantages are strong motivators for team members. If the team is self-directed, however, an additional element must be present for the team to have a reasonable chance at success. Senior management needs to spell out the project's goals and to be quite clear about the range of authority and responsibility of the team. "Self-directed" does not mean "without direction"—nor does it apply to the team's mission. Furthermore, taking an active role in the team's work is not "voluntary" for team members. There must be a well-publicized way of "deselecting" team members who do not actively participate and do not carry a fair share of the team's workload.

The rapid growth of virtual projects employing team members from different countries, industries, and cultures raises additional problems for empowering work teams. Customary worker/boss relationships and interactions vary widely across industrial and cultural boundaries. In such cases, the potential PM needs some training plus experience with the different cultures before taking full responsibility for empowering and leading globalized multidisciplinary teams.

For MTs and parallel tasking to be successful, whether or not the teams are self-directed, the proper infrastructure must be in place, proper guidance must be given to the teams, and a reward structure that recognizes high-quality performance should be in place.

All of the potential problems that MT and parallel tasking can suffer notwithstanding, teams are extraordinarily valuable during the process of planning a project. They are certainly worth the effort of managing and coordinating.

In the next chapter, we use the project plan to develop a project budget. We discuss conflict surrounding the budgetary process. Then we deal with uncertainty, the project's (and PM's) constant companion.

The Chief Operating Officer of the Plymouth Zoo Avery Mitchell was put in charge after the CEO unexpectedly died. Avery was named acting CEO and told by the zoo's Board of Directors that he would be considered for the position permanently if the next few months went smoothly. Avery was very nervous because he knew that the zoo was on the verge of financial troubles. He was not expecting to make the profits that had been projected for the next few months. He knew that admissions were down as a result of recent unrest in the city and nationally.

The deceased CEO had hired a consulting group to help identify cost savings for the zoo. The firm hired was unfamiliar to Avery, and there were rumors around the zoo that the lead consultant was a friend of the now deceased CEO.

The consulting group had been interviewing staff at the zoo for the last two weeks in order to prepare a proposal for work re-design to cut costs. Avery met with the consultants, and they presented him with their proposal. The proposal outlined the cost of the consultants and the projected savings the zoo could expect after the consultants' work was finished. Avery was unclear about precisely how the savings were determined and what would be the redesign project's specific deliverables.

A large privately owned retail discount store was having problems with their time clocks. There were six freestanding time clocks in the store for staff use. They were located conveniently at points where staff entered and exited the store. The staff could also clock in and out on the computer terminals that controlled the cash registers.

The time clocks were old and often in need of repair. The Information Technology (IT) department was responsible for the maintenance of the machines. The IT department could make minor repairs but had to call the clock vendor for the not infrequent major repairs.

The head of Human Resources (HR) wanted to launch a project to purchase and install new time clocks. He felt that because the current time clocks could not be counted on to work, the accuracy of the staff's working hours and the store's payroll was in question. This bothered him, and he felt the problem was getting worse as the clocks aged.

The head of the IT department wanted to launch a project to get rid of all the time clocks and have everyone clock in and out using the current computer terminals located at each register. This would greatly decrease the costs the department was incurring to maintain the current time clocks. The head of IT knew that the computer terminals were not conveniently located for anyone except the sales clerks, but he thought that he could add some terminals in other locations for less money than maintaining the current clocks. He also felt very confident in his staff's ability to maintain the computer terminals themselves, so the expense of calling in a vendor would disappear completely.

The head of HR did not like IT's idea at all. He had problems already with people clocking in for other staff and knew this would only get worse if every staff had to go to a designated computer terminal to clock in and out. The head of HR also knew he had several staff members who were not computer literate and would have trouble clocking in and out.

The two department heads went to the President, and each asked to set up and supervise a project to take care of the time clock problem.