Managing the external forces in new product development
Mark Durrenberger, PMP, Beebe Nelson, and Steve Spring
If you have ever been involved in new product development, we are sure that these scenarios will sound familiar to you.
- Sales and Marketing are not paying attention to your project because they are focused on this year's sales, and so your marketing team member hasn't been able to develop product positioning with representatives in the regions.
- Another project is behind schedule and won't release the resources you need to move your project forward.
- The CEO just visited your project and was heard to remark that it is a “sure bet.” You're afraid that she'll divert your resources to other projects which she thinks are in more need of help.
In these scenarios, the new product teams needed to manage people and events that are external to the project. Even the best project management practices and new product development processes, when applied only to the internal issues of a project, will not be enough to ensure project success. Each of the authors has had the experience of working with new product development teams whose management of both the process and the project has been exemplary, only to find that external forces have derailed or entirely stopped the project. In this article you will learn what forces a team needs to be aware of, what roles team members need to play in dealing with these forces, and what practices are effective in managing these forces in the external environment.
Most companies engaged in new product development today have a defined product development process outlining deliverables for a series of stages or phases and requiring reviews or “gates” in order for projects to pass from one stage to another. In these “stage/gate” processes, reviews provide an excellent opportunity for the members of a cross-functional product development team to strengthen ties to stakeholders and make sure that functional areas are fully informed and prepared to support the project.
However, in the stage/gate process the team's focus is usually on clearing a gate and passing on to the next stage. This orientation can push a team to overlook external issues, especially if reviewers are not aware of them and therefore not likely to address them. We have found it helpful to distinguish between endogenous and exogenous issues.1 Endogenous issues lie within the clear boundaries of team responsibility and influence. Exogenous issues lie outside the defined scope of responsibility of the team. Some exogenous issues are endogenous to the company (e.g., functional decision making), and some are exogenous to the company itself. Figure 1 portrays the elements that are endogenous or exogenous to the project. These terms have helped us to define domains often overlooked by project teams and have proved useful in waking us up to areas of impact, influence and responsibility, which new product teams ignore at their peril. When teams shift their attention to what lies beyond team boundaries they develop an attitude characterized by responsibility and effective action rather than blame, fear and suspicion.
Team Roles: Listener, Integrator, Coordinator, and Influencer
- Karen opens every meeting by asking team members “What have you heard ‘on the street’?” As each team member contributes his or her bit of information, a picture emerges that allows the team to understand and impact what is going on in the company that might affect their project.
- Dick mapped out the stage/gate process used by his company to cover the tasks and deliverables of his functional area, which is electronic manufacturing. Participants on a new product development team from electronic manufacturing are now able to dovetail team and functional processes.
- Gene uses schedule review meetings to ensure that information about forces outside the team are integrated with project tasks. Team members make explicit links to vendor, competitor and other issues as they review team tasks.
Figure 1. Endogenous or Exogenous Elements
These scenarios exemplify how some teams and team members fulfill the team roles necessary to managing external forces. The roles of Listener, Integrator, Coordinator, and Influencer are filled by everyone on the team. Everyone should possess the skills necessary for filling these roles, but in some cases specific members should be accountable for some aspects of a role.
The Listener. The Listener role provides the team with information beyond its boundaries. Listening includes formal and informal listening or data-gathering: customer visits, gathering information about competitors and the market, being aware of what's happening on other teams or in the corporation. Frequently it is the chance piece of information which, when brought to the table with others' ideas and insights, can critically influence a project.
The Integrator. The Integrator role creates the team's memory. Too often information is not in a form that allows it to be available to decision makers and workers. No matter how well the Listeners perform their jobs, without integration the team will not make use of the information. There are two kinds of Integrators: one kind performs the process facilitation role on the team, ensuring that team conversations include appropriate people and subjects; the other kind is a content manager, ensuring that information is recorded, updated, and accessible to the team. In the case of the Integrator, it works best to have specific team members with appropriate skills assigned to fulfill the role.
The Coordinator. The Coordinator role has to do with the coordination of team activities with external stakeholders. In this role, team members negotiate delivery deadlines and synchronize work flow with people external to the team. Even if the team itself has adopted excellent project management practices, they have to be careful not to be derailed by external partners whose management practices may be poor or simply different from theirs. Often it is hard to “push back” with an external partner to make sure that due dates and work processes are clear, but failing to manage this aspect of the project is a recipe for disaster.
The Influencer. The Influencer role is one everyone on the team will play to some extent. However, the team should formalize some aspects of the Influencer role. For instance, in addition to the reviews that occur as a part of the stage/gate process, larger projects should have meetings with company officers at regular intervals. These meetings, and other communication with senior-level corporate officers, should be the responsibility of the project leader.
There is one Influencer role that everyone on the team can and should play, and that is the role of creating a positive image of the project in the company. The idea here is to have the team speak positively of itself and publish its accomplishments—in short, to “brag” about itself. Techniques for bragging include advertising accomplishments in corporate and divisional publications, as well as learning to promote the project with individuals outside the project. When executives are deciding how to allocate scarce resources, it is not unusual for them to go with the project that they believe has the best chance of success. If they've just heard a success story from Project A and a horror story from Project B, all else being equal Project A will get their support. Another benefit to such influencing is the team building that occurs when the team is regularly seeing its own accomplishments and has learned to speak well of itself to the outside world.
Managing the External Forces
How will the new product development team keep the external forces in mind so that they do indeed take appropriate and effective action? The technique we recommend is to use an “event chart.”2 An event chart differs from a milestone chart in that a milestone chart identifies the key accomplishments or delivery dates the team must meet, while the event chart shows what is likely to occur in the team's external environment as the project proceeds. To be sure that the team is thinking of as many external factors as possible, the event chart can be drawn on a field in which the horizontal axis represents time and the vertical axis represents domains that the team should include. After brainstorming the relevant domains (such as corporate calendar, upcoming political, regulatory and legislative events, or timing of competitor introductions), a team's event chart might include dates of board of director meetings; timing of corporate and functional budget cycles and strategic planning cycles; expected completion dates of projects that share this project's resources, or whose introduction may influence distribution, customers or competitors for this project; expectations about future economic, social or environmental conditions; dates of expected competitor product introductions; and expected changes in technology that might affect the project.
This chart can become the central focus of the team's management of external forces. Team members pool their knowledge in order to construct the chart, using Post-it Notes so that they can easily update items. To create the chart the team will have to listen to what is going on outside its borders. The process of construction itself is an integration of the information, and having the information all in one place allows for discussion about what influencing or coordinating needs to occur. The event chart should be available to all team members. It can be displayed in a team conference room or distributed through a shared database, such as a web page or Notes. The team should update the event chart frequently and identify new actions based on the changes. Used regularly, the event chart of external forces can be a driver for the team to manage the external forces.
The Event Chart Helps Integrate Information
Early in the life of the project the team should brainstorm a list of stakeholders and other external forces. This list, which the team should revisit as the project proceeds, will include vested stakeholders, non-vested stakeholders, and external forces.
Vested Stakeholders. A Guide to the Project Management Body of Knowledge defines stakeholders as individuals and organizations who are involved in the project, or whose interests may be affected by it. One group of stakeholders has a vested interest in the project's success and can influence it directly by giving or withholding resources and other forms of support. These stakeholders include the upper management of the company whose business success is affected by the success of the project, the functional areas that are both suppliers to the project and stakeholders in the project's success, and strategic partners who have a vested interest in the success of the project. The project management team should try to list all the vested stakeholders and their relationship to the project. This list will be helpful to the team because it will display stakeholder needs and expectations, making it easier to recognize potential problems and conflicts.
Example: When the company vice president visited the team conference room one morning, he noticed that the first-year sales commitments, which the team had delineated in red, were way below what the marketing group had committed to at the feasibility review. This rather dramatic way of informing him that some of the stakeholders had altered their expectations of the project spurred him to intercede with marketing in a way that the team had not been able to.
Non-vested Stakeholders. Non-vested stakeholders include vendors and other suppliers, distributors, competitors and customers. These stakeholders affect and are affected by the project's success and activities, but they have no direct control over resources or support.3 Although these stakeholders do not directly control support or resources, they have enormous impact on the project. They should be identified along with the vested stakeholders.
External Forces. Project teams should identify other forces external to the team that influence the success of the project. These include the larger forces of economic conditions (is the dollar gaining or losing against foreign currency, and how will that affect my project?), legislative and regulatory issues (how will new regulations in this country and worldwide affect the project, for good or ill?), and social and technological changes (will changes in environmental awareness affect the viability of my new product concept? will emerging technology support or extinguish the product?). Although the team may not be able to influence these factors, it will be able to make better decisions when it is aware of them.
Example: The team was scheduled to make a large purchase of capital equipment from a foreign country. The dollar was relatively weak at the time, but the purchasing member was able to delay purchase of the equipment until the dollar recovered, allowing him to stay within budget on the purchase.
The Event Chart Indicates the Need for Influencing and Coordinating
We recommend that the team commit to a regular review of external forces, perhaps once every two weeks or every month, at which they update the event chart, the list of stakeholders and the external forces. This activity should normally take only a few minutes; when it takes longer it will be because there is new information or because things have changed, and the review will be well worth the time spent. This review will remind the team to assign members to special roles when that is needed. For instance, the project leader may well have chief responsibility with upper management. It will be up to him or her to make sure that the team has adequate and up-to-date information about corporate expectations, long-range plans and strategies, and other influences on the project (listening and integrating), and to influence upper management to ensure consistent support of the project. Team members from the purchasing function may have the responsibility of coordinating with vendors, and marketing and market research team members will be responsible for collecting, documenting and distributing within the team information about customers and competition. One or more team members should be responsible for integrating information, providing the team with data that is accurate, accessible and useful for ongoing decision making.
Below are three examples of how managing the external forces in new product development can help determine the fate of the project, and allow project teams to react in the best interests of the company.
Example: A Team That Pulled Victory From the Jaws of Defeat. A new product team at a major Fortune 500 foods company was almost ready to launch a new product when upper management decided to cancel it. When they regrouped with the charge of starting a new project, they mapped out a strategy for dealing with management. Team members interviewed managers to find out just what each one wanted, and to discover if they had any “pet ideas” that might surface to change the project's direction. They also checked out managers' understanding of the team charter. As the project went forward, a senior officer played the role of Listener and Influencer, staying in touch with management to be sure that the project continued to enjoy the needed support. The team had learned not to leave management support to chance.
Example: A Team That Finally Was Allowed to Rest in Peace. A new product project leader who was developing a product to compete in an emerging technology market was concerned because for several years his project had been underfunded and the support from management and functional leaders was shaky. He continued to get enough support to survive, but not to develop the product with any velocity, and there was no certainty that the product, once it hit the market, would align with the corporation's strategy. The project leader called all the important stakeholders together to review the project's strengths and weaknesses, and to investigate its fit with corporate strategy. The result of this meeting was that the project was canceled, the resources used elsewhere, and millions of dollars were saved.
Example: When the Team Charter is Not the Team Charter. A project leader at a major consumer goods company was asked to pull together a team to develop a product that would block a competitor's entry in a Far East market. Market research showed, much to the team's surprise, that the company's current product was vastly preferred to the competitor's, and that any new entry would compete with their own product, not with the competitor's. Instead of going ahead to the Feasibility Review, which they almost certainly could have passed, the team proposed extensive customer and market research to discover which markets might need a blocker, and to determine customer requirements for it.
Although new product reviews are an excellent opportunity for teams to address issues in the company and beyond, we have found that too frequently reviews are held chiefly as a screening process for the project. There is little “push back” on the functional areas and the reviewers to make sure that there will be the needed functional support as the project advances, and there is frequently too little questioning of the corporate officers' understanding of competitor and other external issues. “Passing a review” should be seen as a two-way contract for performance by the team and for support by the functional area. When reviews are seen only as hurdles that project teams must pass successfully, passing a review may be something of a Pyrrhic victory—you win the battle only to lose the war.
In each of the above examples, the team has been willing to push back, to gain alignment from key stakeholders in the company—or to clarify that they do not have that support, and to investigate stakeholders and forces outside the company. They gathered the necessary information and took on the responsibility of influencing where that was necessary. Teams that have a clear process for managing the external forces will be able to anticipate issues before they become critical, plan for how to manage if certain things do occur, and influence external stakeholders to make decisions in their favor.
1. See Peter Beale and Mark Freeman, “Successful Project Execution: A Model,” Project Management Journal, 1991, 22:23-40.
2. See “Seven Steps to Strategic New Product Development,” Bob Gill, Beebe Nelson, and Steve Spring (in the PDMA Handbook of New Product Development, Wiley, forthcoming) for a description and example of an event chart. Corning uses the event chart in its new product planning process.
3. Note that vendors may be non-vested if they are in a simple supplier relationship to the program, or vested if they are in a partner relationship.
Mark R. Durrenberger, PMP, is a principal consultant with Duncan•Nevison, a project management training and consulting firm headquartered in Lexington, Mass. He previously was a project planner and PM consultant at a Fortune 500 company.
Beebe Nelson, of Adams Hill Associates in Gloucester, Mass., works with individuals, groups, teams and organizations to increase effectiveness of team and business processes, chiefly in the area of new product development.
Stephen Spring, a principal associate with Productivity Associates in Cambridge, Mass., has ten years experience as a consultant, educator and manager with several Fortune 500 companies.
PM Network • March 1996