Suppose you’re a team leader who’s been asked to spearhead a major change initiative, such as the implementation of a key new software application. To prepare you to lead this effort, your company invites you to attend a course on software-development methodology, hosted by the organization. You diligently go to the course, take lots of notes, and return to work eager to try out your new learnings. You’re fascinated by all the technical and task management strategies you’ve just explored, and you’re looking forward to helping your team plunge into their project. Indeed, when the group members assemble to begin defining the project, you’re bursting with ideas for drawing on what you learned in the course.

But as you begin sharing your insights with others in your group, you notice some troubling developments. Not everyone participates equally in these early discussions, and team members can’t seem to agree on how the project should best be approached. You realize that, although you know a lot more about how to manage a software-development effort than you ever did before, you still don’t know any more about what must happen in order for a team to actually complete a project. You also sense that your team’s project will have important impacts on the larger system, but you don’t know exactly what they might be or where in the system they might manifest themselves. Likewise, you’re a bit worried about how the larger system might in turn affect the project.

It may seem that the sensible thing would be to take a few more courses, this time in team development and systems thinking. Many organizations offer just these sorts of courses to their employees. The problem is that, no matter how many of them you attend, you will likely remain unable to integrate the various learnings that you’ve gleaned from a bewildering array of trainings. Moreover, people often aren’t sent to the very courses they need most. For example, manufacturing and other more technically oriented team leaders frequently attend what are thought of as the “hard-core” trainings — usually those courses that focus on tools or methodologies. Courses emphasizing group interaction and team development are often viewed by these folks as too “touchy-feely” or “soft core.” When these leaders return to work, they might be very good at driving the use of a new tool or task methodology, but they fail to inspire the team or help elevate its performance.

The fragmentation that occurs in this educational process is damaging because it spreads into the project execution process. It’s especially problematic in change initiatives that cross functions, divisions, or entire businesses. In such large-scale, complex projects, people forge ahead without fully grasping how the team-development and project-execution stages unfold together or how the project and the larger system shape one another as the project progresses. Without this “bigger picture,” a team may not know how to move beyond development obstacles, such as clarifying team-member roles, and it may make decisions that have unintended consequences throughout the company.

The Need for Integration

Over the last 15 years, much has been written separately about team dynamics and project-execution improvement. For example, B. W. Tuckman’s work popularized the “Form, Storm, Norm, and Perform” stages of team development. And W. Edwards Deming’s “Plan, Do, Check, Act” model outlined the steps required to improve a project-execution process or system. However, it’s difficult to apply these theories in a way that addresses the interaction of team development and project execution that characterizes how the real world works. In everyday life, teams and projects don’t each operate in a vacuum. The specific content of the work, the approach to the project itself, and the dynamics within the team all occur together and influence one another. In your imaginary software-development project, for example, the content would consist of the technical specifications that the new application must achieve. The task methodology could be one of numerous standard methodologies used to design a new application. And the team dynamics might include the various ways and stages by which the team members collaborate on the project, build on one another’s ideas, resolve problems, and learn to work together effectively.

In everyday life, teams and projects don’t each operate in a vacuum. The specific content of the work, the approach to the project itself, and the dynamics within the team all occur together and influence one another.

All three of these dimensions interact and unfold as the project progresses — whether the project centers on designing a new organization-wide computer system, reengineering a manufacturing process, or developing a plan for entering a new market. If we understand some but not all of them, we cannot effectively manage the whole team/project system. And if we try to optimize one of them (e.g., by pushing the task methodology so hard that we stifle creative interaction among the team members), we sub-optimize the whole project. Indeed, the effectiveness of the interrelationship among these various dimensions determines the team’s ultimate success or failure.

Organizations can address these issues by using a more systemic, integrative approach to change — i.e., one that addresses how people are working together (team development) and what they’re working on (project execution) — and that shows team members how the two aspects fit together. A systemic approach should also encourage team members to sharpen their awareness of the larger system within which the change project is unfolding. Moreover, it needs to take into account the roles of all the key players involved in a change effort. Finally, such an approach needs to be easy to grasp and should be accompanied by a visual representation showing where the project and the team are in the development cycle. Everyone involved in a project should have ready access to this graphic representation so as to build a common language and identify both progress and problems. Thus this kind of graphic representation can serve as both a “road map” and a diagnostic tool.

Before exploring ways to integrate all of these dimensions, it’s helpful to take a closer look at the team-development and project execution pieces.

Stages of Team Development and Project Execution

Teams must progress through a specific series of stages in order to successfully complete a project. A team might skip one or more key tasks (such as clarifying roles and expectations in a new team) in one of the developmental stages and still accomplish its overall project. However, the end result is usually poor, membership has dropped off, and the team leader finds him- or herself completing the project alone. A highly successful team will work its way through each stage in sequence and at its own pace (see “Team-Development and Project-Execution Stages”).

Key Players

In addition to the team leader and team members, there are other key players in each change project: specifically, management (or the leadership/chartering group) and other key resources (facilitators, coaches, and so forth). Above, we mentioned the responsibilities that the actual team and its leader have throughout the five stages. But the other two groups also have specific responsibilities that must be taken into account.

For example, to support the team-development process, leaders/managers can help define goals, select the team leader and members, clarify decision-making, and recognize the team’s achievement once it finishes the project. To support the project-execution process, they may play a different role: They identify “customer” needs and gaps between current reality and goals, help define the project and its scope, help redefine the project if that becomes necessary, provide resources, and identify new opportunities opened by completion of the project. Additionally, the chartering group “runs interference” for the team during the course of the initiative, and pays attention to the whole system within which the team is working.

The key resources, for their part, generally coach, facilitate, and respond to questions during the team-development process. During project execution, they consult with managers and team members and provide expertise on the project-execution process.

All change efforts are difficult and sometimes messy. At each of the five stages, typical challenges and signs of progress arise. To help the team move through the critical paths of each stage, team leaders need to be aware of these issues and have some approaches ready to deal with them. The table “Tips for Team Leaders” on p. 4 provides guidelines for how to help a team progress through the five stages.

The figure “Putting It All Together” p .5 graphically captures, in a usable model, how all the elements in this approach work together, and can serve as a handy reference tool for everyone involved in a project. The diagram is a kind of mirror image, in which the team-development stages are shown on the left, and the project execution stages are shown on the right. On each side, the responsibilities of the three main groups of players — management, key resources, and team leaders/members — are listed. Finally, the “Plan, Do, Check, Act” framework is superimposed so that users can see where they are in this cycle as the project progresses. This graphic provides a needed road map and diagnostic tool by helping all players assess progress and understand what to do when progress falters.

Supporting Systems Thinking

The approach reflected in “Putting It All Together” supports systems thinking in several ways. For one thing, it teaches project participants to think systemically about the project by keeping all the parts of the system visible. In effect, the diagram maps the entire “project system,” including key players, processes, and cycles. This inclusiveness is especially important when change projects cut across numerous organizational “silos.” For example, at several points in the project-execution cycle, participants “scope” the project; that is, define what the work will include and what it won’t. This activity forces members to focus on the whole system and the boundaries of a project or process.

“Mapping” a process or project also requires thinking about the flow of work, goods, ideas, etc. Questioning why and how things are as they are often moves the team “upstream” from the system they are changing.

For example, a manufacturing company struggled with late shipments and dissatisfied customers. When they mapped the system and gathered data, they learned that all sales orders arrived at the end of the month. This happened because there was a sales policy that allowed salespeople to discount products at month end in order to meet sales quotas. Of course, customers preferred to buy product at the discounted price; thus, manufacturing capabilities became overloaded at month end.

Moreover, by using this framework, the team spends time gathering information about the current situation. This activity leads to multiple data points for discussion and hones the team’s capacity to see patterns and themes rather than isolated incidents.

Finally, this integrative approach helps team members understand the larger system within which they work. Specifically, as they continually monitor their project system, they notice the project’s impact on various parts of the system (and vice versa). From there, they can design further improvements in both their own project system and the other systems with which it interacts. Also, while brainstorming possible solutions to problems, participants consider possible unintended consequences of action plans on various parts of the project and larger system. Thus the improvement effort stays focused on how the various subsystems fit together, rather than their individual functioning — encouraging a truly holistic view.

Deborah Heller and Linda Cunningham are cofounders of Heller Cunningham, which provides business-strategy and organizational-development consulting and expertise in implementation of vision and mission. Reach them by phone at (617) 734-7604 or by mail at Box 1567, Brookline, MA 02446. Lauren Keller Johnson is publications editor at Pegasus Communications.

For a case study that shows the application of this integrated approach in an actual business setting, see “Reinventing Human Resources at L. L. Bean: Lessons for Learning and Change” by Deborah Heller (Pegasus Communications, 2000). To order a copy, call (800) 272-0945 or go to www.pegasuscom.com.