In Chapter 2 we promised further discussion of multidisciplinary teams(MTs) on projects.
We will now keep that promise. We delayed consideration of MTs until we discussed planning because planning is a primary use for such teams. Using MTs (or transdisciplin- ary teamsas they are sometimes called) raises serious problems for the PM. When used on sizable, complex projects that necessitate inputs from several different departments or groups, the process of managing the way these groups work together is called interface coordination. It is an arduous and complicated job. Coordinating the work of these groups and the timing of their interaction is called integration management. Integration management is also arduous and complicated. Above all, MTs are almost certain to op- erate in an environment of conflict. As we will see, however, conflict is not an unmiti- gated disaster.
A great deal has been written about the care and feeding of teams, and much of it has been encapsulated in a delightful short work by Patrick Lencioni (2002). He writes of the “Five Dysfunctions of a Team.” They are “absence of trust,” “fear of conflict,”
“lack of commitment,” “avoidance of accountability,” and “inattention to results.”
$
Define Customer Re-
quirements
Evaluate Feasibility
Generate Ideas for Improving Current Programs Reputation
Faculty
Evaluate Ideas Get
Data
Evaluate What Competition
Is Doing
Develop Perfor- mance Measures
Define Performance
Define Role of WPPs
Discuss What Else We Are Besides a Biz
School
Genarate Ideas for Partnerships
Generate Blue Ocean
Ideas
Define How We Win
GENERATE IDEASFOR
BREAKTHROUGH
PERFORMANCE IN PART-
TIME PROGRAM
Define Our Customer
Rev and Costs of Programs
Develop Strategy Canvas
?
Consider All funding
Sources ?
Need for Training?
Generate Ideas for Diversification!
Define Our !
Output
Figure 3-9 Final mind map for part-time MBA program project.
3.5 MULTIDISCIPLINARY TEAMS—BALANCING PLEASURE AND PAIN • 95 These dysfunctions transform a team into a collection of individuals in spite of the ap- pearance of harmony (artificial) among the team members. We have emphasized that team members be honest in their dealings with one another, which is required for the development of intrateam trust. We would add that it is imperative that all members understand that they are mutually dependent on each other for achievement of the team’s goals.
Integration Management
The problems of integration management are easily understood if we consider the tradi- tional 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 to- gether. They worked independently and sequentially. First, the product design group developed a design that seemed to meet the marketing group’s specifications. This de- sign 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, relia- bility, manufacturability, and possibly altered the design to use less expensive materials.
There were certain to be changes, and all changes were submitted for management ap- proval, 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, adver- tising 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.
Concurrent Engineering
To solve these problems, the entire project was changed from one that proceeded se- quentially through each of the steps from design to sale to one where the steps were car- ried out concurrently. Concurrent engineering (CE) (a.k.a. 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.) In addition to the Chrysler example noted near the beginning of Chapter 2, Section 2.6, Chrysler (now DaimlerChrysler) used CE to make their PT Cruiser ready for sale in Japan four months after it was intro- duced in the United States. U.S. automobile manufacturers usually take about three years to modify a car or truck for the Japanese market (Autoweek, May 22, 2000, p. 9).
CE has been widely used for a great diversity of projects. For example, CE 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 of- fice; to plan the maintenance schedule for a public utility; and to design and construct the space shuttle. Concurrent engineering 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 in- stance, 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 de- sign engineers changed the design to straight legs. Under the previous system, manufac- turing 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. This is concurrent engineering in action.
Again, the word “engineering” is used in its broadest sense, that is, the art of mak- ing practical application of science. Precisely whichsciences is not specified. If the team members are problem-oriented, CE 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, CE 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 suboptimization as the preferred approach to problem solving. They argue that experts should be allowed to ex- ercise 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 what- ever is established as the project objective. There is considerable evidence, however, that this will not prevent conflict on complex projects.
Interface Coordination—Interface Management
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 iden- tify 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,
3.5 MULTIDISCIPLINARY TEAMS—BALANCING PLEASURE AND PAIN • 97
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 fun- damental structure of this approach to interface management is shown in Figure 3-11.
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 to- ward making the project a success, rather than optimizing his or her individual contri- bution, it will be relatively easy for the PM to identify troublesome interfaces between members of the project team.
The Design Structure Matrix
One observation that can be made regarding integration management and concurrent engineering is that both are fundamentally concerned with coordinating the flow of infor- mation. 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.
Figure 3-10 An interface mapping of a silicon chip design project (Bailetti, Callahan, and DiPietro, 1994).
Figure 3-11 A coordination structure model for project management (Bailetti, Callahan, and DiPietro, 1994).
Compounding this problem is the fact that traditional project management plan- ning 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 proj- ects 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 com- plete a specific task?
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 proj- ect’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 com- plete a given task can be determined by looking across that particular task’s row. Like- wise, 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-7.
According to the table, completing activity crequires the gathering of information from Table 3-7 Example DSM for
Project with Six Activities a b c d e f a
b X X
c X X
d X X X
e X
f X X X
X—information flow
3.5 MULTIDISCIPLINARY TEAMS—BALANCING PLEASURE AND PAIN • 99 Table 3-8 Modified DSM to Show
Activities to Be Completed Concurrently a b c d e f
a
b X O
c X O
d X X X
e X
f X X X
tasks to be completed concurrently X—information flow
O—potential rework situation
activities band f. Furthermore, the table indicates that activities cand fboth 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-7 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 eis completed after activity b, activity bmay 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-8 if it had been planned that tasks c, d, and e were to be done concurrently. Also notice that in Table 3-8 any re- maining entries above the diagonal of the matrix are highlighted as potential rework by replacing each X with an O.
In examining Table 3-8, 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 later option is a bit more complex and may necessitate changing the physical location of where the tasks are completed.
Comments on Empowerment and Work Teams
The use of a participatory management style has been, and will continue to be, empha- sized in this book. In recent years several programs have been developed to institution- alize 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 del- egated to the team, they are all intended to empower workers to use their knowledge and creativity to improve products, services, and production methods.
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:
1. Teams generate high-quality solutions to appropriate problems.
2. Micromanagement is avoided.
3. The team is given accountability for some part of the project deliverable.
4. Synergistic solutions are frequent.
5. The PM has a tool for timely team evaluation and feedback.
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 “volun- tary” 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 coun- tries, 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 experi- ence with the different cultures before taking full responsibility for empowering and leading globalized multidisciplinary teams.
For MTs and CE 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 CE can suffer notwithstanding, teams are extraordinarily valuable during the process of planning a project. They are certainly worth the effort of managing and coordinating.
The task of managing the ways in which different groups interact during plan- ning and implementation of projects is called “interface coordination.” An im- portant aid to interface coordination is mapping the interactions of the various groups. The task of integrating the work of these groups is called integration management. Concurrent engineering allows all groups involved in designing a project to work as a single group and join together to solve design problems simultaneously rather than separately and solving the problems sequentially.
When information from some project activities is required to complete other activities, the Design Structure Matrix may be quite useful.
DISCUSSION QUESTIONS • 101
REVIEW QUESTIONS
1. What are some of the benefits of setting up a project plan for routine, frequent projects?
2. Discuss the reasons for inviting the functional man- agers to a project launch meeting rather than their subordinates who may actually be doing the work.
3. Discuss the pros and cons of identifying and includ- ing the project team at the project launch meeting.
4. Why do so many “self-directed teams” perform poorly?
What can be done to improve their performance?
5. Why is participatory management beneficial to proj- ect planning? How does the process of participatory management actually work in planning?
6. What is the difference between the Resourcecolumn on the action plan (that would include personnel needed by the project) and the Assigned tocolumn?
7. Under what circumstances is it sensible to do without a project launch meeting?
8. What limitation associated with traditional project management techniques like Gantt charts and prece- dence diagrams does the Design Matrix Structure overcome?
DISCUSSION QUESTIONS
9. For each one of the nine components of a project master plan, discuss the problems that might be raised if the element was incomplete.
10. Give several examples of a type of project that would benefit from a template project action plan being developed.
11. Why is the hierarchical planning process useful for project planning? How might it influence the plan if the hierarchical planning process was not used?
12. What causes so much conflict on multidisciplinary teams? As a PM what would you try to do to prevent or reduce such conflict?
13. Of what help is a “map of interdependencies” to a PM who is managing a transdisciplinary team?
14. Develop an action plan with at least two levels for a project you are personally familiar with (e.g., moving away to college, registering for class, cleaning out a garage). (Hint: the plan will be more useful as a learn- ing exercise if you have a subordinate or two-real or imaginary.) Be sure to include precedences, task dura- tions, resource requirements, and milestones. Enter the plan in MSP.
15. Discuss the drawbacks of implementing a project plan without an LRC.
16. What are the potential ramifications of not utilizing integration management techniques or concurrent en- gineering while planning and implementing a project?
17. List the advantages of using an “empowered team” for planning. What conditions must be met for these ad- vantages to accrue?
18. Pursuing a degree or certificate is a major project.
Construct a brief “project plan” for this project that includes all 9 elements described in the chapter.
19. Assume that your class instructor appointed you project manager to lead a dozen of your classmates in writing up the end-of-chapter pedagogy materials (i.e., Review Questions, Discussion Questions, Problems, Incidents for Discussion, and Cases) as an Instructor’s Guidefor this book. You plan to form subteams to work on each of these elements, each headed by a subteam leader.
Of course, all the subteam materials will need to be integrated into the final Instructor’s Guideat the end.
Construct a WBS and linear responsibility chart for this project.
20. You and your family and friends are planning to host a graduation party at the end of the school year. Con- struct an action plan for this party.
21. Construct an action plan for the project in Question 19.
22. Consider one or more projects (from this course or else- where) that you understand reasonably well. Identify situations where information learned from a later task of the project becomes important to an earlier task.
23. Contrast the Project Plan, the Action Plan, and the Work Breakdown Structure.
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.