Debugging dysfunctional development
By Lee Norris Miller
Product development often is a disjointed effort that puts sales vs. engineering vs. manufacturing vs. management. Launching a product that goes through such a tortuous process often leads to disappointment. But using force-field analysis to help establish multifunctional product development teams can result in a smooth operation that brings the concerns of all partners to the table, yielding cost-effective, innovative products that customers will want and pay for.
Much has been written about the incredibly creative products developed in record time by the multifunctional teams (sometimes called cross-functional or multidisciplinary teams) of companies such as Apple and Motorola. Yet, even as organizations cite the urgent need for innovative products for an increasingly competitive marketplace, many of these same organizations hesitate to adopt multifunctional teams for product development. It appears as though many executives think that multifunctional teams belong only where employees come to the job in flip-flops and work with Fido next to their desk.
However, organizations that use multifunctional teams for product development report benefits that go beyond creativity or speed. And those slow to adopt this practice may be missing out on more than just the latest fad product or the quickest time to market. In fact, many companies inadvertently set their sights on lower sales and diminishing margins by not giving the customer what he or she wants. How could this happen? Aren’t most companies the experts in their field? Surely they know better than anyone what the customer wants?
Actually, it has been suggested many times over that our companies are not nearly as customer-oriented as we would like to believe. As Mike Walker contended in a 2002 article for the journal Financial Management, “Many companies don’t obtain or use solid customer data because they think they already know what the customer wants.” He concludes that, “This ‘fuzzy front end’ is a major cause of business failure.”
A tale from a nearby galaxy
Let’s see how this could happen by taking a look at a typical scenario in industry today, as illustrated in Figure 1.
Management visits sales and asks: “Why are our sales down? Are you guys slacking off again?” Defensively, sales responds: “We’re working our butts off. Our product line is out of date. We need a new ‘Latest Fad’ model to compete.” So management heads over to engineering and tells it to develop a ‘Latest Fad’ model. “We have got to have it now,” management says.
Engineering checks out all of the other “Latest Fad” models that everyone else offers. The engineers develop one for a competitive price (“Sales is always harping about the price”), one they’re sure will be well-received. Months later, the “Latest Fad” model has siphoned off some sales from the company’s other models, but overall sales have not budged much. Management again visits sales: “We gave you your ‘Latest Fad’ model, and sales are still terrible. Now what’s your excuse?”
This time, the response from sales is: “Our ‘Latest Fad’ model doesn’t have the whizbang gizmo feature that’s on the Company A model. We need the gizmo feature.” Management heads to engineering and says, “We need the gizmo feature.” Engineering grumbles that they investigated the gizmo feature and thought that it was too expensive, but without putting up much of a fight, they redesign the “Latest Fad” model and add the gizmo feature.
When the new “Latest Fad + gizmo” model comes out, sales screams: “We can’t sell that. It’s too expensive. You can’t raise the price; sales are terrible already. What do you think you’re doing?” Engineering replies: “Of course it’s expensive. That’s why we left it out to begin with. But you guys in sales had to have it. So here it is. Now you sell it.” At this point, management has to get involved again. “What are we going to do now? We spent thousands of dollars designing and redesigning our ‘Latest Fad’ model. On one hand, people seem to like the new ‘Latest Fad + gizmo’ model, but on the other hand, there does seem to be some initial resistance to buying it due to the high price.”
Management holds a meeting where they decide that they can’t afford another redesign. After all, engineering already is over budget from all the overtime spent on getting the first “Latest Fad” model out in record time and then again on the rushed redesign. To get sales moving, management agrees with sales (“Just like they always do,” grumbles engineering), and they cut margins to the bone to lower the price and then give incentives to sales employees to motivate them to push the new model.
A few months later, sales of the new “Latest Fad + gizmo” model are doing much better. Sales department employees are all smiles after having received their first incentive bonus checks. Engineering grumbles, “We do all of the work, and sales gets all of the money.” Management worries about expenses that are too high and daydreams about boosting sagging margins by shifting manufacturing to a country whose labor rate is 50 cents per hour.
A new hope
Clearly, product development in many companies truly is not in touch with the customer. Product development with multifunctional teams looks to avoid this scenario by building an infrastructure that creates interdisciplinary
teams whose focus is on meeting the customer’s requirements in product function as well as price. The idea is to get it right the first time by developing a product that customers want, for which they are willing to pay, and that can be produced for a price that will earn acceptable profits. It seems intuitively evident that success would require concurrent input from your marketing, engineering design and manufacturing functions, as shown in Figure 2, to meet these multiple, simultaneous goals.
The process starts with your marketing personnel determining the required functionality of the product as perceived by the customer. Also, the retail-selling price, based on what the customer is willing to pay for the product’s functionality, is established. Marketing’s input doesn’t stop here, as having marketing personnel on board as the voice of the customer throughout development is critical to the project’s success.
Next, cost planning begins, even before any design work takes place. Here, manufacturing personnel work with engineering to calculate the estimated cost. The estimated cost is the current cost of the expected new model using current technologies. It generally is calculated using cost tables for an existing model by adding or subtracting cost differences for the new model due to expected product design differences.
The estimated cost is then compared to the target cost, which is the retail-selling price (as previously determined from customer input) less distribution costs and the target profit (from the company’s long-term profit goals). The difference between the estimated cost and the target cost is the amount that must be saved through design changes to meet the target profits for the new model.
Design engineers now begin designing components that meet the functionality requirements of the customer while meeting the cost targets. Multifunctional meetings determine how to reduce product costs while maintaining or improving functionality. Marketing, engineering, manufacturing and expected third-party suppliers all work together to meet the design requirements. Typically, two complementary meetings are held each week.
First, brainstorming meetings involve meeting or improving product design characteristics or solving design problems as creatively as possible. The rule in these meetings is to leave your inhibitions and all negative comments at the door. Frequently these meetings turn into lively discussions with entertaining descriptions of crazy methods for doing this or that, that is, until someone asks, “Why wouldn’t that work?” Often, that’s when the laughing stops and … hmmm … you may be on to something.
The complement to, or perhaps the antithesis of, the brainstorming meeting often is referred to as the production meeting. In these meetings the brainstorming ideas are developed, the product design is firmed up, and value engineering is performed to examine cost saving areas. These areas include design simplification, part count reductions, component part standardization and reduction of direct labor and/or raw material consumption. If a component’s cost target cannot be met, the difference must be added to another component’s cost target. However, the design is not considered complete until all of the design criteria, including the target cost, have been met.
Use the force (field analysis)
Companies that have adopted multifunctional teams for product development insist that they have boosted profitability. However, even though most Japanese manufacturing companies (where the concepts originally were developed) and many technology product organizations (such as Apple and Motorola) have adopted the practice, many U.S. organizations have not embraced it. So why the resistance and how should we overcome it?
Organization development research has suggested that we analyze resistance to change by utilizing the concepts of force-field analysis. The force-field analysis suggests that the stability (some call it inertia) in our companies’ and our employees’ behavior is due to the balance of factors that drive and restrain change. Change can be accomplished more readily by analyzing and reducing the restraining forces rather than by increasing the driving forces. For example, pushing harder inevitably will be met with an increase in resistance. Thus, let’s look at the restraining forces when incorporating multifunctional teams for product development and then look at what can be done to reduce or eliminate them.
Resistance to teamwork. In order to meet the multiple, simultaneous demands of the marketplace, product development requires multifunctional teams. In Asian culture, the team, or the collective whole, is more important than the individual. But in the Western world it’s the individual that most often takes priority over the group. A system requiring teamwork may include people who refuse to go along. They may resist because they feel a loss of individual status, or perhaps they think the system will restrict the creativity so important to them. This aspect will have to be addressed if a company implementing multifunctional teams is going to avoid employee opposition.
Lack of trust. Multifunctional teams require trust. Tales of Asians blindly following their leaders’ instructions, even to their own deaths in kamikaze flights, are legendary. To Western employees, however, the goals and the criteria and the numbers must be trustworthy so that everyone buys into the system. The moment that someone suspects management, another department or even another team member of putting up unrealistically high or low numbers, the system will break down.
Lack of discipline. With the constant pull and tug of company politics, management will require discipline to “stay the course” when someone’s favorite feature is about to be removed or when someone else cries that there is neither need nor room for cost cuts. From the meditations of Buddhism to the rigorous practices of martial arts to the sought after perfection in a Japanese garden, the examples of Asian self-discipline are storied. But Westerners are more noted for their creativity, not their discipline – especially design engineers who make their living creating innovative new products. So how can these two characteristics possibly be integrated?
Resistance is made futile
Although it certainly reflects some unique aspects of Asian culture, the concept of using multifunctional teams has wider applicability, and the techniques involved have been adapted successfully to other cultures. In fact, the multifunctional team techniques themselves frequently provide the solutions to many of the surrounding questions. So let’s look at how the restraining forces can be reduced or eliminated.
Teamwork. We all have watched teams of lesser-skilled players work together to beat teams of individually superior athletes, so the advantages of teamwork are well-known. By getting everyone working together, multifunctional teamwork provides the catalyst for creative product solutions and cost savings that the engineering department might not have thought about or could not have addressed on its own. But multifunctional teamwork provides the structure where this can take place. Multifunctional product development makes meeting the design criteria the goal of the team, not just the engineering department. Multifunctional team members, working together on every step of the process, all are held accountable for the project’s overall results. This motivates all team members to make the system work and the product design successful.
Three additional steps can help motivate team members to focus on overall results. First, the initial use of multifunctional teams should use team members made up of volunteers from each of the functions that you intend to have on your development team, such as marketing, design engineering and manufacturing. This ensures that you start with a minimum of resistance from team members. Second, employee performance reviews should include some measure of peer evaluation for their work on the project. All team members should have a means to provide input into another member’s performance, such as with a 360-degree performance appraisal. This will help eliminate concerns about freeloading. Third, you must ensure that the team members will be available full time for the entire project, from concept to product launch. Team members should feel comfortable that they and other team members can buy into the project and invest 100 percent of their time and energy without concern of being pulled off to do something else that comes up.
There still could be interpersonal squabbles, however. This is an area in which there may be a need for training. Classes should be considered to teach all members group problem-solving techniques and/or interpersonal conflict resolution.
Trust. A necessary ingredient for trust is good communication. Multifunctional teamwork requires that team members receive and accept clear goals from management about what is expected. This includes comprehensive criteria from marketing as to the functionality and price requirements from the customer, concise numbers from cost planning and the accounting department on costs and expected profits, and guidance from manufacturing on how best to design the product to meet cost and manufacturability requirements.Again, the system itself provides the structure to develop this trust.
Multifunctional teams promote trust because everyone on the team has an active part in developing the numbers and criteria that must be trusted. Furthermore, the development of the numbers and criteria is done openly and not behind closed doors. Also promoting trust is the fact that these numbers are available for all to see and use. Team members can see that they are considered trustworthy, as compared to the somewhat typical scenario today where, for example, cost and profit information is only accessible to and is fiercely protected by the accounting department and senior management.
In addition, to encourage teamwork and cooperation further and to reduce interpersonal squabbles, keep the product development teams small, no more than 10 permanent members. Although other departments may be necessary to assist with some product development duties from time to time, limit the permanent full-time members to the functions required from concept to launch. Generally, these are marketing, design engineering and manufacturing. Finally, all of the project development team members should be located in the same area away from their functional silos. They should sit within conversational distance of one another. Again, a necessary ingredient for trust is good communication, so eliminating barriers to communication, including distance, is imperative.
Discipline. Product development discipline is yet again something that multifunctional teams can provide. The system provides this discipline since the inclusion of whiz-bang gizmo type options will be taken away from the whims of the design engineers or the sales department. Instead, such plans will be evaluated based on customer preference and perceived value. Since cost planning is done in the initial stages of product development, the tough decisions concerning the inclusion of product functionality as compared to its costs are made early. Early changes are more economical than those required later in the design cycle. Without utilizing multifunctional teams, the product might be launched with costly functions that customers don’t want to buy.
Clearly, multifunctional product development teams help prevent these potentially low-margin products. Finally, senior management must buy into the system. When functional managers want to “borrow” their employees and pull them away from the multifunctional team, senior managers must understand how important the product development project’s long-term goals are and resist the short-term temptation that risks destroying the multifunctional team. Senior management buy-in also is responsible for empowering the team, giving team members the informational tools they need and authorizing them to use those tools to make product development decisions in the best interests of the organization.
However, senior managers cannot be expected to buy into a vision that they can’t see, so “pony meetings” should be held twice monthly. Pony meetings, a term from Apple’s product development system, are meetings of senior management with the entire multifunctional team.
In these meetings, senior managers typically outline things they would like to see in the product’s development, things that the product development team frequently sees as somewhat wishful thinking (such as, “I want a pony.”… “Who doesn’t want a pony? Ponies are gorgeous.”)
Senior managers, even if misguided, cannot and should not be ignored, and their ideas should be investigated and, if warranted, incorporated. The inclusion of senior management into the system gives managers the sense of control they need for buy-in and gives the multifunctional product development team the legitimacy it needs to resist special requests from others, requests that would take team members away from the project.
Breaking through the dark side
Clearly, before U.S. companies will change, management must recognize that change is necessary. This recognition may be upon us. “Three-quarters of managers questioned in a 1999 survey in Harvard Business Review … thought that their companies’ planning processes were unsatisfactory,” according to Walker.
Some may say that designing new products with multifunctional teams will be more difficult. After all, the teams will face multiple constraints when designing components that simultaneously meet the customer’s quality and functionality requirements, meet the production department’s manufacturability requirements and meet the target cost. But these goals always have been the focus of design engineers, and the specifics never have been spelled out as clearly as when using multifunctional teams.
Obviously, using multifunctional teams for product development is no magic cure-all. If treated like the management idea of the month, creating multifunctional team slogans and handing out multifunctional team coffee mugs will do little to reduce product costs or increase product functionality.
According to Manufacturing Engineering magazine’s editor Brian Hogan in 2003, “When you examine a successful product ... you’ll find the secret of that success is always someone’s hard work. … Hard work can’t be replaced by glibness, a clever presentation, or familiarity with the latest books by management gurus.”
Ultimately, what your organization gets out of multifunctional team product development depends on how much effort you put into it. But if you concentrate your focus on customer functionality and price requirements, and then strive to meet those requirements using multifunctional teamwork’s systematic methods, then your probability for successful and profitable product launches surely will improve.
Lee Norris Miller is a visiting assistant professor in the Department of Political Economy and Commerce at Monmouth College. He has been an instructor at Bangkok University, vice president of engineering at Brake Align LLC, vice president of engineering at Accu Industries Inc., president at LeO Tech Inc., and president at Manufacturing Solutions Inc. He is completing his doctorate in business administration at St. Ambroise University. He has an M.S. in mechanical engineering from Virginia Commonwealth University, an MBA from Western Carolina University and a B.S. in mechanical engineering from the Ohio State University.