Improving Time-to-Market with Self-Directed,Cross-Functional Teams

Improving Time-to-Market with Self-Directed,Cross-Functional Teams

(In Empowering Teams, An Introduction. S.Gopalan & N. Taher, eds. 2007 The Icfai University Press, Hyderabad, India)

Corporations are realizing that the conventional methods for bringing products to market are too slow and cumbersome. The complexity of today’s products and the sophistication of the marketplace require a more seamless and integrated process.

Craig LaFargue, Managing Partner of Antioch Consulting Group, with Edward Tripp, Director of Device R&D of Abbott Laboratories, have implemented a development process using cross- functional teams. This process requires representatives from the various departments who usually “wait their turn” in the product development cycle, to work together as a team from the very inception of a product.

When put into practice, the advantages of this new process are immediately apparent:

• improved coordination among departments because of horizontal (as opposed to vertical) communication

• more efficient use of resources and personnel

• decreased timeframe from product inception to market introduction (the most sought-after improvement)

This new process brought its own set of problems, however. While I have found the self-directed, cross-functional approach much superior to the "wait your turn" vertical approach, it does have its own challenges, which I address in this article.

The Truth About Team Development

Over the years, many myths have developed about the team approach to product development. The following is an overview of some of those myths and the truth about them.

Myth 1--Teams go through a predictable series of stages before they are able to get serious and produce something.

There is an assumption that all teams go through several stages--Forming, Storming, Norming, and Performing--and that until the team enters the Performing stage, no actual work on the product is achieved. “Real world” research on group development, however, does not support that theory. It’s true that some groups argue and bicker at the beginning, but many groups do not. To use this theory to guide a group in its development can be disastrous. I simply cannot predict how a group of individuals will jell. I do know,

however, that there are structures that increase the likelihood that a group will jell quickly and get to work. I will discuss those structures later in this article.

Myth 2--The “just do it” approach

This myth is based on the premise that unless a person is actively working on a task directly related to the goal, the person is wasting time. It means that team members feel compelled to “dig in” with some concrete assignments, before discussing the process the team will use to solve problems and develop products.

Unfortunately, when teams do not examine how they will get the work done, discuss the nature of the project, or agree on the importance of certain work philosophies, they wind up wasting more time than if they had discussed the team process at the beginning. Research from Professor Connie Gersick of UCLA Graduate School of Management reveals that teams, who consider the process of getting their work done before starting on the assigned task, complete the assigned task quicker and with higher quality than teams that “just do it.”

Myth 3--Happy members equal a productive team

It seems axiomatic that if team members enjoy each other’s company and the experience of being on the team, the team will naturally be productive. One might expect that if the team members enjoy the team experience, they would naturally adopt the appropriate norms, (i.e., work guidelines). However, if the norms they adopt are inappropriate to the task, then the right work won’t get done, even though the members are having a good time working together.

Again, research in group dynamics sheds light on the issue of group cohesiveness. While it is true that a necessary element of group cohesion is member attraction, that same dynamic can wreck havoc if the norms that guide the team behavior are unsuited to the task. In that case, you have all the members behaving in accordance with the wrong group norms, which inevitably results in a poorly designed and implemented product.

All this may seem counter intuitive. I do know that if members do not like being on the team, group cohesion will suffer and the team will find itself with unproductive members, or at the extreme, without members. So it is necessary for a team to be composed of members who like to be on the team, but who understand that it’s necessary for them to adopt norms that are appropriate to the task.

Myth 4--Sales is for someone else

Myth 3 is based on the faulty premise that as long as the team members are satisfied with the interpersonal processes, that team will be productive. Our experience, and research by

Debra Ancona, Ph.D of MIT, has found that, while the team experience should be perceived as worthwhile by the members, that is not enough for the team to be effective. The additional component, which is a key success factor, is effective boundary management.

Boundary management means creating links within the organization. These links are crucial. In her research, Dr. Ancona found that the degree to which other departments are aware of a team’s activities, determines the success of a team in accomplishing its objectives. This communication of progress is not limited to reports and memos, but should include promoting the team’s members as well as “selling” the team’s capabilities, and promoting its successes to ensure the continued funding of the team. Senior management needs to know, for example, how the team is progressing and, more importantly, that the team is effectively proceeding toward the completion of its mission.

The old adage holds true, the more those in power believe or perceive the “goodness” of a concept, person, or team, the more the requisite funds and resources will continue to flow. If a team sees the task of promoting and selling itself as irrelevant, it may find that its resource pool will dry up prior to completing its objectives.

Myth 5--Conflict is a sign of team meltdown

The “good” news about cross-functional product development teams is that they are composed of members from different departments, who bring varied viewpoints and experience. The “bad” news is that because of these differences, conflict is a natural outgrowth. And because I tend to perceive conflict as a “bad” thing, when it surfaces in team activity, I try to make it go away. When conflicts are buried early in the development process, then uncovered later in the process, it may be too late to resolve them and they can result in a product’s demise.

Again, actual observation of product development teams has led us to believe that conflict is a harbinger of creativity. At face value, this too seems counter intuitive. The popular image of a group is team members working smoothly together, energy focused, with each member concentrating on his or her part. This nice image does not match our observations, however. The truth is that product development teams don’t always know what to do when faced with a difficult issue, and even more, they don’t always agree on a specific course of action.

Cross-functional product development teams, by their very nature, comprise people with varied experiences, skills, and background. It is this diversity of knowledge that is the team’s strength, and this strength can only be utilized if all points of view are allowed to be brought forward, questioned, and tested in a highly energized interpersonal environment. When an uninformed observer experiences this type of volatile teamwork, the observer may conclude that the team is falling apart under the strain of the diverse viewpoints. However, if the team has spent the necessary time building a strong foundation, it will be able to incorporate these points of view, or even create an entirely new course of action to overcome the challenge. Conflict is not the issue; rather it is how the team deals with conflict and harnesses its energy that is key.

Building a Better Team

Growing self-directed, cross-functional teams that are productive and successful means attending to some of the misconceptions about group dynamics and formation. It also means creating a structure that enables the team to work freely and creatively. I have found that there are seven basic blocks that need to be in place before the team can begin work on an actual task. Experience has shown me that if these blocks are in place, there is a greater likelihood that the team will complete its mission. The next section presents the building blocks for a successful team.

Building block 1--Who we are: values and vision

It is important for every team to have a sense of identity. Identity is based on values and a vision. When a team takes the time to define its values and vision, it’s in a much better position to develop a strong “root system” that will allow it to weather the product development storms.

A team’s values are like an internal compass that guide their behavior, often without their knowledge. Values help the team make decisions, especially when such decisions deal with issues that are ambiguous. Values that are shared and agreed upon help the team as it works through its key objectives to accomplish its goal.

Vision is the other critical component for a team’s success. A vision has power. It provides the team with a sense of energy and spirit, enabling the team to persevere in spite of the obstacles. The vision is not the mission, nor the key objectives. A team without a vision is like a person without a sense of spirit.

An effective team vision:

• is shared by all members

• inspires

• is focused on the future, but written in present tense

• is a mirror for the team

• embodies the core values of the team

• is customer oriented

Building block 2--What we do: the mission

The mission statement is the team’s raison d’etre. Simply put, the mission statement describes what the team is charged with doing, the reason for the team’s existence. It is not a philosophical statement about the team, that’s the purpose of the vision. The mission statement keeps the team on task and oriented toward the goal. A mission statement must be precise and to the point, and should describe the core business of the team or organization. A hazy mission statement equals a poor product outcome.

The following are examples of clear mission statements:

• To produce and market a self-energized ambulatory controlled flow delivery system.

• To provide team development consulting services for temporary, task-specific teams.

• To develop and manufacture cutting tools and wear-resistant parts using powder metallurgy.

Building block 3--How we make decisions

It is a popular misconception that all decisions made by a team are done via consensus. Nothing could be further from the truth. It is unrealistic to expect every decision to be made by consensus; it would simply take too long.

The chart (fig. 1) that follows illustrates the concepts of "routineness" and required acceptance by the entire team. Routine decisions differ from non-routine in that they are fairly straightforward in terms of a “standard operating procedure.” Typically these are decisions made by an individual team member regarding his or her specific task specialty.

The concept of acceptance involves how much buy-in is required by the entire team in order for the decision to be implemented successfully. In some cases, everybody on the team must buy in to a decision. More often, however, complete buy-in is not necessary for a decision to be carried out. If a team is characterized by high trust, individual

members can make decisions that affect the team without having to get approval. Indeed, teams that constantly use a consensus process for making decision may be operating out of low trust. Trust, therefore, increases the efficiency of the decision-making process.

The problem that teams have with making decisions invariably involves deciding how the decision is to be made, and having some expectation about that. It’s not how the decision gets made so much as whether the process of decision-making violates a team’s sense or expectation, which in turn leads to increasing or decreasing the level of trust within the team.

The chart on the previous page can help identify the types of decisions a team will be making. First, list the kinds of decisions the team will need to make. Then, categorize

each decision as voting, consensus, authority without input, or authority with input. Next, compare the categorized list to the Decisions Style chart. This will tell the team how to handle the various decisions that will need to be made. This way, expectations are managed and the possibility of poorly implemented decisions is decreased.

Building block 4--How we work together: norms and ground rules

Norms and ground rules describe how the team works together. Norms describe both work processes and interpersonal processes. For example, a work norm may be that whenever a new idea is discussed, it is immediately written on the flip chart. An example of an interpersonal norm is that conflict between two team members is not discussed in front of the team.

Often, norms quickly become habit and, therefore, invisible. The upside of this is that the team doesn’t waste time continually talking about how they go about getting the work done. The downside is that because norms are in the realm of habit, they are not openly discussed, which can lead to some poor work habits that serve to undercut the team’s effectiveness. Research from Professor Gersick of UCLA, has found that teams that discussed how their work was to get done and what their norms would be, were much more effective and successful in the attainment of their goal.

If a team wants to be effective in the pursuit of its goal, it’s well worth the time spent at the beginning of the team’s development to discuss and get agreement on team norms.

Building block 5--How we coordinate with others: boundary management

According to Drs. Debra Ancona, MIT, and David Caldwell, University of Santa Clara, there are three main types of boundary management activities that determine the success of task forces and new product development teams. Moreover, they have found that the sequences of these activities are critical to the team’s success.

Scouting: This involves actively scanning the organization for information relating to the product team. It means importing information to the team from the organization. Scouting centers around information pertinent to markets, technology, and competition, and is best suited to team members with experience in marketing and sales. While these activities are important to the team during the creation stage, when the specifications of the product are still being defined, they can be disruptive and lead to team failure if allowed to continue. The scouting activities wind down when the team receives approval from management to design and build the product.

Some examples of scouting activities might include:

• Discovering what competing firms or groups are doing on similar projects.

• Scanning the environment inside and outside the organization for marketing ideas, technical ideas, or both kinds of expertise.

• Collecting technical information or ideas from individuals outside of the team.

Ambassadorial: These activities are aimed at representing the team to others and protecting the team from interference. Ambassadorial activities require exporting information from the team to the organization. Usually, the team leader takes on ambassadorial activities, attempting to influence individuals in upper levels of the organization in one of the three following ways:

• Buffering: This is protecting the team from outside interference, preventing political pressures from infecting the team’s spirit and progress, and preventing outsiders from overloading the team with too much information or too many requests.

• Building support and progress reporting: This means “talking up” the team to outsiders, particularly those in high levels in the organization. These activities accomplish the dual function of letting management know how the team is progressing and building enthusiasm of outsiders in order to obtain the resources the team needs to achieve its goal. This also entails persuading others to support the team’s decisions, acquiring resources for the team, and keeping other groups in the company informed of the team’s activities.

• Developing a sense of strategy: This means understanding how changes in the company strategy and political situation affects the team’s mission, and determining whether other groups in the company support or oppose the team’s activities. These activities also focus on uncovering potential threats and changes in the organization and outside environment which could spell disaster for the team if not dealt with at an early stage.

Task coordinating: Although similar to ambassadorial activities in that they export information from the team to the outside, task coordinating activities are about communicating laterally with others in the organization. The main focus of these activities is aimed at coordinating the team’s efforts with other teams in the organization that the product team is dependent upon. Task coordinating activities remain high on the list of ongoing activity type throughout all of the team’s stages.

Some examples of task coordinating activities are:

• Reviewing product design with other people in the organization who are not members of the team.

• Discussing and resolving design problems with external groups.

• Coordinating activities with external groups.

• Negotiating for resources and delivery deadlines.

• Ensuring that other department teams understand the needs of this team and support it.

Building block 6--Who does what: roles and responsibilities

Roles and responsibilities describe how the work gets done in the group by focusing on individual commitments and activities. A role is a label for a series of responsibilities and serves as a convenient classification device. More important, however, are the responsibilities that define the role. Poorly defined activities lead to lack of coordination and teamwork. Ultimately, poorly defined responsibilities will cause the team to be unsuccessful in reaching its goal. What I recommend at this point are exercises that clarify individual roles and responsibilities.

One effective exercise is to have all members post a flip chart with their names. Then, members review each chart, writing the role and responsibilities as they perceive them for each specific member. This is followed by each member reviewing his or her new roles and responsibilities with the entire team, getting clarification and approval on their specific “job contract.”

Building block 7--How we accomplish our mission: goals, milestones, and action plans

Achieving the goal is the end for the product development team. When the goal is reached, the team disbands. This is one of the main differences between a cross- functional product development team and a regular, on-going work team.

A good plan starts with the end, and then works backward. Therefore, the first planning step begins with the goal. A team’s goal may be similar to the mission statement, except for one important difference: it has a completion date. A well-defined goal should answer these questions:

• Who is the customer?

• What specifically must the group deliver to the customer?

• When is the final delivery expected?

Milestones, on the other hand, are key events that occur during a product development team’s life cycle. Milestones are major task steps, and usually signify completion of a critical activity or project phase.

Action plans are the activities (action steps) that must be accomplished to complete each milestone. When developing an action plan, the following guidelines may be helpful:

• Write a single milestone at the top of the page. It should include both the key even and when it should be accomplished.

• List the action steps needed to accomplish the milestone by the given date.

• For each action step, you may find it helpful to also list the beginning and end dates and the person responsible for completing the action step.

Summary

When you make the effort to build the proper foundation for self-directed, cross- functional development teams, the true potential of the team members can be released, resulting in reduced product development cycle times. In addition, team members learn valuable skills that can be transferred to other teams. Finally, by having a well-thought­out foundation ahead of time, the team ensures that its members will be successful not only in achieving the mission, but also in developing positive relationships in the way they work with each other.

References

Gersick, C.J. (1990) “Habitual Routines in Task-Performing Groups.” Organizational Behavior and Human Decision Processes, 47, 65-97.

Ancona, D.G. & Caldwell, D.E. “Cross-Functional Teams: Blessing or Curse for New Product Development?” In T.A. Kochan & M. Useem (s.) Transforming Organizations. New York, N.Y.: Oxford University Press.