The chemical process industries spend billions of dollars on research and development to improve products and processes. New management tools can increase the return on these development dollars.
Using business tools is one path to better management of research and development (R&D) projects and portfolios. Several such tools are presented here - aggregate planning, quality function deployment, and process redesign (through activity based management or business process reengineering), technology integration, control via stages and gates, and supply chain development and management.
These are only a few of the many models, methodologies, and techniques available. They may be familiar and even in use in some organizations. But, wider use as described here will pay off by improving the performance of development efforts.
Can you "manage" development?
The answer to this question is likely to be "it depends." It depends on each company's circumstances: How mature are its product lines? How fast is technology, both product and process, changing? How big is the budget for product development? What is that budget's relationship to cash flow from existing products? Is development discretionary, or does competition mandate it? How does the organization treat its developers? How hard are they to recruit and retain? No two companies will answer these questions the same way.
However, improving the management of development processes is an opportunity in most companies. The opportunity may be fattening top-line sales with new products and increased market share. Or, it may mean bottom-line boosts from cutting process time, getting more out of plant and equipment, and slashing operating costs.
Consider specialty chemical manufacturer Rohm and Haas Co., which in 1996 reported $4 billion in sales, $400 million in after-tax profits, and R&D budgets of about $200 million annually (1). Rohm and Haas divides its activities three ways: by line of business (four categories), by product type (ten categories), and by expected economic return, or profitability, for shareholders (three categories). The company calls the latter three categories growth, profitability, and value businesses.
In 1996, the growth category contributed 30% of sales and was expected to expand in sales and profits. About half of the R&D budget supported this category. The profitability category (55% of sales) was the second-largest group. Profitability products (also known elsewhere as "cash cows") earned an adequate return on the investment, but growth was not expected. The value category (15% of sales) earned below-par earnings and cash flow. Presumably, management will squeeze these lines for better returns. (In fact, some of these businesses have been divested.) Table 1 shows the businesses in each category.
These splits raise issues about allocating and managing scarce development dollars. Can a single process for managing R&D fit all these businesses? They use different technologies, serve different markets, and vary in their financial objectives. What impact will these differences have on product and process development? How can a company be sure it is getting full value for its development investments? Should low-profit, mature businesses be denied development funds?
Not tackling these issues leads to frustration, particularly when development projects run on with little sign of commercial success. Eventually, a crisis in the business hastens needed change. For example, IBM, faced with declining sales and stock value, slashed R&D budgets by $1 billion, ending many projects and refocusing product development efforts. At risk is the unseen loss from long-term explorations of new technology (2). But, in the near term, IBM's market valuation benefited from the focus on results.
After several years of cost-reducing "reengineering," there is renewed interest in increasing sales and market share. This has produced a flood of tools, models, and techniques to improve development processes. They focus on reducing lead-time, responding to customer needs, and making a difference in the income statement. Most tools address one or more of the following shortcomings:
Informal process definitions. The functions we call R&D have evolved in mature companies. Few firms have scrutinized design processes as thoroughly as they have easier-to-measure processes, such as those in the plant or in the accounting department. Responsibility for successful market introduction is fuzzy, falling under the purview of multiple functions. What's good for one line of business may not fit the needs of others.
Slow processes. With product life cycles shortening in most industries, the agile prosper at the expense of the sluggish. Fast product development, including deployment, equals market success.
Portfolios that are out of control. There are too many projects with no measures for effectiveness and efficiency. Perniciously, good projects fall by the wayside as the bad ones gobble up resources.
This article describes several recently developed business tools that address one or more of these shortcomings. Technical managers often like tools, because they put into practice what common sense dictates. But, lack of awareness inhibits their widespread use. And without the right tool to guide their thinking, companies underachieve.
The project model
By its nature, product development consists of discreet projects. The simple project model in Figure 1 can be adapted to the management of development.
This development model differs from that implicit in many companies. First, it incorporates the notion that commercialization is integral to development. In many organizations, the development process stops at engineering's door. For both new products and processes, commercialization will require the talents of multiple departments and, probably, outsiders.
The model includes external and internal customer needs. Internal customers, in particular, are users of new process technology.
Finally, the definition of technology is expanded. It includes the conventional view that development projects advance the state of the art in a technical discipline. But, it also includes the nontechnical innovations that are needed, such as supplier capabilities and channels to reach the market.
What tools should you use?
If every problem were a nail, all we would need is a hammer. But, the right tool depends on the task.
The revised model in Figure 2 shows the business tools described in this article. The three arrows above the execution box represent growth, profitability, and value as the requirements for different product groups or businesses. Many companies make this distinction, although they may use slightly different terminology.
The remainder of the article explains how various business tools can be applied to the management of a firm's development efforts. An example tells the story of Ann McNally, the chief technology officer (CTO) of a fictitious company, Turbo Chemicals, who has been charged with turning around a development organization.
Aggregate planning
Aggregate planning (3) is a valuable procedure that managers can use to select the "best" projects for the R&D portfolio. It involves the following steps:
1. Define and classify projects. The following categories have been proposed (3): enhancements to existing products, next-generation projects, radical breakthroughs, research and advanced development, and alliance or partnered projects.
2. Define resources and cycle times for representative projects in each category.
3. Identify available resources. Technical staff is often the limiting resource.
4. Compute capacity utilization.
5. Using strategic goals, establish the desired mix by project type.
6. Estimate the number of projects of each type to pursue.
7. Decide which projects to do.
At Turbo Chemicals... Ann McNally is the new CTO of Turbo Chemicals. Her job is to manage both product and process development projets to improve Turbo's bottom line. Turbo has struggled lately. Downsizing and cost cutting have been tried. But, added profits from cost reductions are hard to come by. The Board of Directors wants results from product and process development, plus better returns on Turbo's 100-person development staff. And McNally is supposed to produce them.
When she took over the job, McNally asked for a listing of approved development projects in progress. An avid reader of management books, she organized the projects using the aggregate planning procedure, as shown in the first three columns of Table 2.
Derivatives are extensions of current products. There are 15 basic products, and 20 approved projects to modify their formulations, change their packaging, or make minor changes to their manufacturing processes. Platform projects represent the next generation of current products or processes. They'll lead to "new and improved" versions of products or major investments in plant or equipment. Breakthroughs are truly innovative products involving new technologies. Research includes efforts to discover new technology. Partnered projects (of which there are none at this time) are cooperative efforts with customers or suppliers.
The staffing numbers were derived from project histories for the last few years. Based on the average staff requirements for each type of project and the duration of the projects (including only engineering time, not approval or implementation time), the backlog and staff requirements were calculated.
The need for 134 staff stood out clearly - particularly because the department only has 100 people.
The imbalance is a result of the way management approves projects, without regard to existing backlog. Management would approve any idea, big or small, that had merit. "We're bogging down! The backlog is growing, and we're not completing anything - at least not anything well," McNally realized.
She concluded that the problem is twofold. First, the number of projects must be reduced, because it is not possible to add staff and there are too many projects for the current staff. In addition, more projects will be coming along, and the department will need to respond. Second, the efficiency of the staff must be improved, because the projects seem to be taking longer than one would expect.
To tackle the first part of the problem, McNally classified Turbo's product lines by their growth and profit potential and assigned projects to the appropriate product categories, as shown by the last three columns (growth, profits, and value) in Table 2. This revealed that there were more people working on low-contribution (value category) products than on growth products.
McNally decides to "dump" some projects - to put them on hold or eliminate them all together. To pick the projects, she concentrates on one of the boxes. The Derivatives category for Value products requires 20% of the staff (20 people), so she decides to start there.
Quality function deployment
Quality funciton deployment (QFD) is a structured discipline for translating requirements into product or process specifications. For example, Ford uses QFD to translate customer desires for a car door into design specifications (4).
Design teams find QFD particularly useful. A pitfall in many development efforts is lack of understanding of the need a product is to fill. In large organizations, the designer may not have this knowledge. Even if communications are there, it is often difficult to get team members from several disciplines to communicate effectively. QFD encapsulates in a single source all assumptions regarding consumer preferences, competitive assessment, and the contribution of product features to the customer requirements.
A design team used QFD for the design of an auxiliary power unit (APU) for aircraft produced and came up with an interesting result immediately. The APU is a turbine engine that starts the main engines and provides electrical power and ventilation when the main engines aren't running. Going into the development project, the design team focused on the aircraft builder, the buyer of the APU, as the customer.
However, the design really had to satisfy two customers: the aircraft builder and the airline user. Searching out the needs of the airline users caused the team to make several changes to the design.
QFD can also contribute to aggregate planning. It will identify missing projects or projects that make little contribution to strategic objectives. A return to the example illustrates this point.
At Turbo... McNally had read about QFD as a tool for designing new products, and she decided to adapt it to review the ten projects in the Value category. These products were "past their prime" in the product life cycle. So, strategically, Derivative projects would need to improve profits.
She developed the QFD matrix in Table 3 for ranking the projects. The ten projects are across the top and the evaluation criteria are down the side. The weightings of the criteria are in the second column; because cost reduction is the highest priority for Value products, it has the greatest weight. Each project is assigned points for each criterion (here, the 9-3-1 scale common in QFD analysis is used), and these are added to get a total score for each project.
The projects varied greatly in terms of their contributions to the business -- projects 3, 4, 5, and 7 were large contributors, projects 9 and 10 were marginal, and the rest provided little value.
Other project/product combinations would require different criteria and weights. This illustrates, however, how QFD can cast light on the comparative value of projects.
Process redesign
Activity based management (ABM) and business process reengineering (BPR) are terms currently applied to the redesign of business processes. ABM had its roots in activitybased costing systems, which shifted the focus of budgeting and financial reporting from departments to processes. BPR is a more-recent incarnation and calls for "radical" restructuring of processes to eliminate lead time and waste. I believe that, when it comes to process redesign, there's nothing new, but the buzzwords add topicality and the illusion that there is. Often, this stimulates needed, perhaps belated, action.
While many companies have overhauled manufacturing processes, most haven't yet tackled development. In fact, the design principles are the same (5). Opportunity lies in fashioning processes to fit business needs. A one-size-fits-all process means compromises. The resultant design won't meet the needs of any single product group well.
A product portfolio like Rohm and Haas' has overlapping technologies, markets, and goals. The design of development pipelines or funnels should reflect these differences. It doesn't mean there has to be a design for each of the ten product lines or the four lines of business or the three return categories. But, there might be three or four designs, representing different types of development projects. Projects might be categorized based on the size of the project, strategic value, product or process, time needed to produce revenue, or technology involved.
Based on previously completed reengineering projects, analysts have drawn several conclusions regarding best practices in process redesign. These principles apply well to product development:
Be aggressive in defining process boundaries. Cover multiple functions. In the case of development, include commercialization in the marketplace or implementation in the plants. Establish cross-functional management and design teams to make the changes.
Focused businesses do better, and so do the development activities that support them. A development process established for the convenience of central engineering will be slow to adapt to market changes. The design of the development process should reflect market needs. Set up processes around those needs. QFD will help.
Flow, density, and velocity are good metrics for process measurement. The consulting firm Ingersoll Engineers uses these measures to evaluate manufacturing cell design (6). Cells are clusters of different kinds of machines put together to speed workflow. Multiple-technology cells can do the same thing for development.
These measures adapt well to the development environment. Flow measures the path of work through the process. Too many hand-offs add time, increase the likelihood of error, and reduce accountability. Density refers to the physical space for production. With too much space available, work in process inventory builds up. The analog in development is too many projects in the pipeline at once. Velocity measures the relationship between the work time and the clock time it takes to complete a project. A velocity of 0.5 means it took two hours of clock time to do one hour of work. Most manufacturing processes measure velocities below 0.05. (Yes, that's 5% of cycle time spent actually adding value.) In all probability, most development projects are that low or lower.
New cost accounting improves visibility. Traditional cost accounting in manufacturing relies on a direct labor base and allocations of overhead, which often includes development. Without activity costs for manufacturing processes, judging project success or failure is difficult. Activity costs also help in selecting the best projects for cutting those costs.
Cross-functional teams improve processes and increase employee satisfaction. As described later, integration, rather than mastery of specific technologies, is increasingly important to development success. Teams help achieve this integration, and they should include all the organizations touched by a process. This includes suppliers as well as customers.
Process redesign starts with establishing the "as-is," which describes how the process operates. The analysis should also include an evaluation of how well the process works.
At Thrbo... Next, Ann decided to turn her attention to the lead time required for projects, reasoning that if she could shorten lead times, Turbo could get to market faster and maybe save manpower. So, she considered Turbo's process and organization for development projects (Figure 3).
Engineering departments have a lot of autonomy. Project budgets are built by asking technical department managers for resource estimates. When one department completes its part, that's passed along to the next department. The CTO reviews the projects periodically. Marketing, Finance, and Manufacturing support the project upon request of the Engineering department working on the project at that time. When the project is done, Marketing, Finance, and Manufacturing will review the project and prepare the implementation plan. This can be quite time-consuming if the project is complex, particularly for those projects requiring new facilities or distribution channels.
A project can have one of many sponsors. Sponsors include Marketing, Manufacturing, Engineering, or corporate executives. Material vendors and manufacturing equipment suppliers provide ideas. The CTO's office receives the ideas. Forms are sent to the engineering departments for estimating costs, while the sponsor identifies the benefits.
When a project is approved, it is released to the first technical department; along the way it may go through one or more other technical departments. When complete, Finance reviews the project. If funding is available for implementation, the CTO gets necessary authorization a second time and sends the project to Marketing or Manufacturing for implementation, depending on the type of project. This phase is known as "the maze," since it's hard to know how a project is doing or where it is in the process.
The front-end and back-end processes add six to 18 months to the project duration. For example, a Derivative project averages five months in Engineering. But, it could take anywhere from a year to two years to complete.
The most successful projects have strong sponsor support. All sponsors have "pet" projects, so they'll lobby hard for resources and expedite the project through the technical departments. (This is one reason the fivemonth duration in Engineering is just an average.) There's wide variation from project to project.
As she pondered this, McNally became even more convinced that major changes were in order. So, she listed the problem areas and the perils she saw (Table 4). She wasn't sure exactly what to do, but she was frustrated with the current system and ready to change.
Technology integration
Iansiti and West also argue for fundamental changes in development project management (7). Technology knowledge has proliferated, they say, and advancements in narrowly defined specialties are readily accessible to all competitors. The advantage will go to those who can choose from the technology options available and integrate them effectively.
They cite as an example the U.S. semiconductor industry, where success at choosing and integrating technologies into new plants has helped American companies regain leadership. These companies had lagged, because they used an obsolete model of technology integration. In that model, isolated project teams from development or manufacturing would decide what technologies to pursue. Usually they had only narrow perspectives on pieces of the project. The lack of broad perspectives led to poor decisions.
A new model places responsibility for development on a broadly skilled integration team. It probably includes suppliers, other companies, and research institutions. After making technology choices, integration teams work with developers to make the new technology a reality. Helping the process is the capacity to experiment extensively with the new technology.
Stages and gates
Appropriate controls make sure projects are on track. The use of "stages and gates" increases management visibility over progress (or lack thereof) in development projects. This approach is described in (8).
This management tool recognizes that each development project will likely have a different pace of progress. Two similar projects starting at the same time will not finish together. However, they will follow similar paths - for example, investigations, development, testing, and implementation. Completion of predetermined deliverables document progress along that path. At each gate, managers review these deliverables and decide if the project can proceed to the next stage.
This approach makes increasing sense as the complexity or number of projects increases. Managers of growth products, in particular, should find this tool attractive, since growth projects vary widely in their need for customer input, user surveys, and internal adjustments to capabilities and capacity. Stage/gate project management recognizes this.
Supply chains
In the world of products, traditional functional thinking is giving way to a new view, characterized by the term "supply chain." This view recognizes that no single function or company stands in isolation. The links between the primary producer, its suppliers, the distribution system, and the end users is a single chain. Weakness of any one link weakens the whole chain. Integrating these components strengthens the chain and leads to competitive advantages.
Chemical process industries (CPI) companies sell into multiple chains ranging from other manufacturers to wholesalers and end users. BASF maintains in its advertising that "We don't make the products; we make them better." BASF is an important part of the supply chain for its customers' products.
Companies like Rohm and Haas serve multiple supply chains. They will need to understand the needs of each and respond appropriately to all of them. Two recent articles (9, 10) guide our understanding of the dynamics of supply chain management.
Porter (9) asserts that companies need to make decisions about how they compete. For example, they may compete as low-cost producers (e.g., Hyundai in the automobile market) or, at the other extreme, as high-price, exclusive providers (e.g., Rolls Royce). They support their choices by setting up linked activities - a supply chain. (For instance, one would expect the Hyundai showroom to have fewer amenities than the Rolls Royce showroom.) These linked activities are a barrier to competitors, because integrating many activities is much more difficult than copying one.
The linkage of activities is vital because, while each activity may be easy to imitate, the total linked network is not. Airgas is an example of such a company. It sells low-technology industrial gases, but it seeks advantages through distribution-network building and offering value-adding services to go with its products.
Fisher (10) points out that supply chain design depends on the nature of the product and its demand. He divides products into functional and innovative categories. Functional products sell at low margins; their supply chains should be efficient, since customers are buying based on price. Innovative products command higher margins; delivery and availability should drive the design of their supply chains.
Managers of growth, profit, and value products need to keep these differences in mind. According to Fisher, the supply chain for growth products will differ from that of profit and value products. For growth products, there would be less concern for the cost of getting products to customers and more concern for availability and service. For profit and value products, which are more mature, the emphasis would continue to be squeezing cost out of the supply chain.
Over at Turbo... A week later, Ann finishes her recommendations for a new development process. Realizing that the organization can take many directions, she put together a proposal to discuss with her department managers and company executives. It centers around four fundamental changes:
1. Have multiple processes tailored to different product lines and project types. A lot of delay can be removed from the Derivative projects. A cross-functional cell, with engineers from various departments, will be set up. The cell manager will handle the approval and execution using guidelines given to him. The technical teams on the projects can work directly with sponsors to get the job done.
The next three recommendations apply to the major projects in the Platform, Breakthrough, Research, and Partnered categories.
2. Strengthen internal tracking and accountability. A program management function will be responsible for each major project. Each effort will have a responsible project manager to see that it stays on track.
A stage/gate system will increase visibility over major projects. Deadlines will be set for each gate and defined deliverables will be due at that time. This will allow management by exception, with followup initiated if a program manager brings in the project late. Four gates at critical points in the project life will be defined.
3. Involve users throughout the process in major projects. There are many needs in this area. Both internal users, such as Marketing and Manufacturing, as well as those outside the company in the supply chain, including numerous suppliers and customers, must be considered. The company can no longer do business in isolation from these partners. Most major projects require supply chain changes.
First, as part of the project management function, users should act as a project steering committee. In this way, they can give timely input to the process and be aware of the progress being made. The project manager and steering committee would plan the project in detail and oversee the design.
Second, a supply chain technical group should be established. It would support major projects with systems and business expertise related to this fast-changing area. Like any other technical group, the program manager would use it as required by the project.
4. Match projects to strategy. Senior management should sign off on all major projects. Importantly, this screening should use the criteria appropriate to each product/project category. The current portfolio is chewing up resources needed for high-potential markets. As a first step, all the Breakthrough projects for the Value group should be challenged - that will free 18 engineers right away.
This new process is illustrated in Figure 4.
Beyond tools...
While tools may be invaluable in improving development processes, they are not sufficient to motivate change. To start that change, three ingredients must be in place:
a why, or a reason to change usually dissatisfaction with the current way of doing business, such as not enough new products, unprofitable operations, or fast-changing technology;
a want, or a vision of the future - commonly this vision includes ontime, on-budget projects generating truckloads of cash; and
a how, including the next steps to take.
This article has been about the hows. Awareness of a few hows supports the other two ingredients and can get the organization moving ahead. Once started, the change process will build on itself.
J. B. AYERS is a principal with CGR Management Consultants, Los Angeles, CA (Phone: 1310) 822-6720; Fax: (310) 821-7269; E-mail: jimayers@cgrmc.com). He has consulted in strategy and operations improvement for 27 years; many of his projects addressed the product development process. He has authored numerous articles on strategy and reengineering, as well as a book, "Improving Competitive Position: a Project Management Approach," which was published by the Society of Manufacturing Engineers. He also presents workshops on the redesign of product development processes, as well as supply chain reengineering. He holds a BS from the U.S. Naval Academy with distinction and MBA and MS degrees in industrial engineering from Stanford Univ. As a Naval officer, he served on nuclear submarines. He is a member of the Society of Manufacturing Engineers ISME) and the Council of Logistics Management CLMI. He is also a Certified Management Consultant ICMC) and a member of the Institute of Management Consultants.
[Reference]
Literature Cited
[Reference]
1. "1996 Annual Report," Rohm and Haas Co., Philadelphia, PA (1996).
2. Ziegler, B., "Gerstner Slashed R&D by $1 Billion; for IBM. It May Be a Good Thing," The Wall St. Journal, p. 1 (Oct. 6, 1997).
[Reference]
3. Wheelwright, S. C., and K. B. Clark, "Revolutionizing Product Development," Free Press, New York (1992).
4. Hauser, J. R., and D. Clausing, "The House of Quality," Harvard Business Review, 66 (3), pp. 63-73 (May-June 1988).
[Reference]
5. Ayers, J. B., "What Smokestack Industries Can Tell Us About Reengineering." Information Strategy: The Executive's Journal, 11 (2), pp. 20-26 (Winter 1995).
[Reference]
6. Nyman, L. R., "Making Manufacturing Cells Work," Society of Manufacturing Engineers, Detroit, MI (1992).
7. Iansiti, NL, and J. West, "Technology Integration: Turning Great Research into Great Products," Harvard Business Review, 75 (3), pp. 69-79 (May-June 1997).
[Reference]
8. Cooper, R. G., "Winning at New Products," 2nd ed., Addison-Wesley, Reading, MA (1993).
9. Porter, M. E., "What is Strategy?." Ha,vard Business Review, 74 (6), pp. 61-78 (Nov.-Dec. 1996).
10. Fisher, M. L., "What is the Right Supply Chain for Your Product?," Harvard Business Review, 75 (2), pp. 105-116 (Mar.Apr. 1997).
