The decade of the 1980s yielded many improvement initiatives that were focused on the manufacturing and materials management functions. Some initiatives were largely focused on improving management processes and empowering employees. JIT, Kanban, and Quality Circles are examples of "process-focused" initiatives. Other initiatives were primarily focused on technologies that supported or automated business or manufacturing processes. MRP, Bar Coding, CIM, and SPC are examples of "technology-focused" initiatives popular in the 1980s.
Numerous manufacturers experienced significant measurable benefits from implementing these techniques. Cycle times in manufacturing were drastically reduced, inventories were managed-down to record low levels, and product quality was clearly improved in many segments of industry. Towards the end of the decade it was clear that a good deal of the "bang for the buck" was already "in pocket."
Some of the most positive indicators of improvement have been some of the most painful to appreciate. Highly trained manufacturing and materials managers and technicians are now on the street looking for jobs. Mergers, acquisitions, and bankruptcies of companies that supplied technologies to these areas are an everyday occurrence. Well known companies like Prime Computer, Cullinet, Computer Partners, Automatix, and a host of others bit the dust or experienced significant corporate restructuring or downsizing. The "Big 8 Accounting" firms became the "Big 6" and the names of many of the internal consulting practices in these firms were changed. In many of these service firms, "system development" business services were re-focused to become "system integration" services. In almost every segment of industries that dealt with the manufacturing sector, significant changes were evident.
Most experts now agree that the vast majority of improvement opportunities that are "controllable and implementable" from within the manufacturing and materials functions have been achieved or are in process at this time. The exact figures being offered range from 60% to 90% penetration. The major opportunities for future improvements in operations functions originate in functions that are not controllable by manufacturing. Again, macro industry trends are reflecting this reality. Usher in Business Process Reengineering, TQM, and Self-Empowered Teams for management process improvements. Usher in Cross-Functional Systems and Product Data Management as examples of next-step technologies. Usher in Concurrent Engineering and Design For Manufacturing as examples of improvement initiatives that span both the process and technology environments.
One of the major problems with initiatives in the 1980s, which in the author's opinion is on the verge of being repeated in the 1990s, is that the scope and duration of the attempted improvements is too big. Grand visions of "complete overhauls" that will pay benefits still abound.
GM's project Saturn is a great example. Huge sums of money and resources were invested to create a completely automated automobile production facility. The knowledge and goodwill that is resulting from this program is benefiting many companies including GM, but it will be many years still before the investment pays for itself.
TQM is another fine example. TQM is still in its first decade as a prominent management goal and already public literature is questioning its effectiveness. The scope of TQM is not bounded. It includes every structure, process, technology, and communication within an organization. Further, this scope extends to all customers and suppliers. Managing a "TQM Program" is a multi-year undertaking which addresses every aspect of company operations. Simply said, TQM is impossible to define and then manage. It has no bounds.
Third, and the final example, is Business Process Reengineering-BPR. BPR is the hottest topic in corporate America in the early 1990s. Like TQM, the goal of BPR is admirable and tangible at a conceptual level. Like TQM, BPR also has no limitations on its scope. The author's prediction is that BPR and TQM will end up in the same category once the approaches are tested over time. The post-mortem will read something like this. "We learned and we improved, but we spent huge sums of money and resources over a multi-year period that would have had much more impact if they had been more focused. In hind sight, we would limit and change our approach."
One of the primary arguments for "total reengineering" and TQM is that it is impossible to optimize the whole by optimizing the parts. From one view, this logic is quite sound and fundamental. From another view, it falls apart. If the scope of a project is so large that the risk measurably increases and the potential benefits are pushed into the distant future, then "where's the beef."
The Saturn project, as contrasted with the manufacturing industry in general, provides a reasonable illustration of this viewpoint. Manufacturing professionals spent a good part of the 1980s "linking islands of automation." First the work centers were optimized, then they were linked together. Changes to localized improvements had to be undone to optimize the flow of the whole operation, but benefits were being realized one cell at a time. In contrast, GM had to wait many years for an entirely new "reengineered factory" to be built. The scope of the project was barely manageable and there were delays. The investment period was so extensive that it will take many years to recover it.
Companies should learn from their experiences. The author has a saying that summarizes these lessons learned. "Anything that is everything has a high probability of being nothing at all, or at the very least being disappointing." The goals of BPR and TQM are noble and tangible at a conceptual level, and are virtually not implementable. Improvement initiatives and projects should not be undertaken if the scope exceeds some of the practical realities that exist in the business world.
While the "islands of automation" approach was not completely efficient, it was at least definable and manageable. And, it yielded benefits in a phased manner.
Why prioritize new product development among all other opportunities that a company has to improve itself. Some folks will argue the old saying, but most will agree that "no products, no sales, no profits, no company." New product development is the first and foremost issue for companies that design and produce products. All other business activities, opportunities, issues, and problems result from having products to sell.
By definition, healthy companies have a vibrant and consistent new product development engine. This requirement will become amplified in this era of global competition. As product cycles continually decline and global competition provides an ever increasing number of alternatives and choices, the companies that can keep turning out new products that consistently meet customer needs will stay near the top.
Most companies hope that some 60% to 80% of sales revenues and profits result from products that were developed within the past 3-5 years, and few achieve it. It is also essential to remember, in competitive markets, that new products typically have the highest profit margins attached to them. The profits from being first to market are greatest. The profits decrease as competitors enter and price wars begin.
Concurrent Engineering, or Concurrent Product Development-CPD, is an improvement initiative that is focused on reengineering the product development function for speed, efficiency, and quality.
From an organization-wide viewpoint, CPD is an "island of change." From a management standpoint, CPD is definable. The goals are quite clear.
From a scope perspective, the implementation of CPD programs is finite and manageable.
If these three basic tenets of project scope are followed, concurrent product development efforts will yield the expected benefits within the planned time period. Many companies focus on technology-based solutions to problems. Almost by definition, the development, implementation, and training cycles for technology-based solutions will exceed 2 years.
Most management teams have little disagreement about the importance of new products. The majority of disagreements lie in the differing views about the current strengths and weaknesses of the company new product development engine, and who should be responsible for directing and implementing improvements.
Most management teams, while taking responsibility for overall improvement initiatives such as CPD, rely on the folks that work for them to perform the specific analyses and make the recommendations. In selected instances, management goes outside the company to consultants and service firms to assist in the analysis and recommendation process. This is where the rub begins.
Senior management became senior management because they were the leaders in implementing the "changes of their time." Current company operating philosophies, principles, practices, and procedures were defined and improved by them. Their collective success propelled them into executive roles. They became the leaders because their methods and results were better than that of their predecessors. This may rub a few readers the wrong way, but if you subscribe to the theory that the "best get to the top," then the logic is sound.
Now these senior managers are in the same position as their predecessors. Times have changed again and new thinking is required. Like their senior forefathers, the change initiatives are blessed from the top but executed from lower levels. The current executive team will be no less resistant to change, than their predecessors were.
To get off to a positive start in reengineering initiatives such as CPD and Design For Manufacturing it is essential that opinions and politics be reduced to the smallest level possible during the initial stages of an improvement program. Employees only have limited goodwill in conceptual discussions and arguments with members of a management team. This is especially true if the members of the management team were instrumental in designing and implementing the processes that are the subject of the change initiative.
Anyone who has ever attempted to lead or participate in a major change initiative knows that if there is not agreement at the beginning of what is to be done, then there will be difficulty and lack of buy-in for the rest of the project. Now we come full circle to the discussion earlier in this article regarding unbounded improvement programs. If a project cannot be defined and agreed to, it cannot be achieved in a planned time frame.
The most effective way to gain consensus across all levels of the organization is to base analysis and recommendations on facts. A famous executive once said that "God is entitled to opinion, all others must bring facts and data." This is a guideline to use for any major change initiative, including Concurrent Product Development.
Before beginning the planning and implementation activities associated with concurrent engineering, the current "performance baseline" must be established. The baseline is a set of metrics, measures, and statistics that define the current performance of the product development function and capabilities.
The specific baseline metrics that are chosen should not only be meaningful to measuring today's environment, but should be applicable to measuring progress in an ongoing manner. The specific measures should be factual in nature, and quantitative whenever possible.
The number of different measures should be limited to a practical number. This may range from 10 in some companies, to over 50 in other companies. A recommended number is some where in the middle, say around 25. The measures should be relatively easy to calculate and to remember.
Measures should be taken several ways. First, measures at a macro-level should measure the overall capability and throughput of the product development function at an aggregate level. Second, measures should quantify approaches and limitations to defining plans for starting-up new product development efforts. Third, measures should exist to document the "contract" between management and the self-directed concurrent development teams regarding project goals and expectations. Fourth, provisions should be made for measuring the progress of projects-in-process. Finally, measures should exist for measuring progress in the accelerated development environment of the future. In this last case, it many not be possible to apply these metrics to the current environment. The specific elements to be measured in future environments may not be tracked and/or recorded in traditional management and scheduling approaches.
In summary, there are five different categories of metrics necessary for rapid development environments. All categories, except Project Contract metrics, are worthwhile to apply during baselining and need assessment activities.
Numerous metrics exist that facilitate and promote rapid development processes for each of these areas. This article will limit discussion to approximately two metrics for each of these five areas. Where appropriate, case studies and industry surveys will be included to illustrate the use of the baseline metric in practice.
It is also important to note that the metrics discussed in this article are focused on the effectiveness and efficiency of "new product development processes," as opposed to a whole set of metrics that exist to measure "new product development technologies."
The product development function in a company is much larger than the Engineering department. The Marketing function must provide overall direction, and at the very least a skeleton definition of each and every product prior to its development. The Engineering function has the responsibility for designing and developing. The Manufacturing function must make the product producible with consistency. The Field Service function must be able to maintain and upgrade the product over time and resolve customer issues. The product development function is actually composed of portions of several different business functions.
In manufacturing operations, capacity is measured either by machine capacity or by human capacity. In product development, capacity is measured solely by human capacities. As such, bottlenecks in product development largely occur because functions such as Marketing, Engineering, and Manufacturing do not have the right amount of resources dedicated to new product development at the right times in the process.
In order to assure that a given company has minimized the chance of new product bottlenecks, the different resource requirements for the functions involved in new product development must be initially estimated and then actively managed in the future. An effective tool for accomplishing this task is named "Staffing Ratios." The ratio approach is important because it provides for scalability as an organization grows or shrinks over time. If a company fundamentally changes its product line, then the staffing ratios between each of the functions may change. For the most part however, once the baseline measure is established it is good for several years to come.
By definition, the Engineering department in a company has the primary responsibility for developing new products. The responsibility is certainly shared by other functions, but in reality only a subset of the personnel in other functions are actively involved in the process. The Staffing Ratios metric is always calculated by measuring the ratio of engineers to the "number of full-time equivalent or dedicated product development staff" in each of the other functions to the number of full-time engineering staff [Figure 1]. In mixed hardware-software development environments, resources that are specific to either hardware or software must be further broken out for a sound analysis.
Ratios are typically calculated for key new product development functions such as Marketing, Manufacturing Engineering, Production, Purchasing, Quality, and Field Service. Ratios in mixed environments necessitate the delineation of several "sub-functions." For example it is necessary to isolate Hardware Quality Assurance from Software Quality Assurance.
Once a company determines its own ideal set of Staffing Ratios, it is now in a position to minimize the number of new product development bottlenecks. Several surveys are now available to assist companies in defining appropriate ratios. Highlights from one survey are included in this article [Figure 1B].
There are several important things to keep in mind when using these surveys. First, what counts is "best-in-class" ratios and not "industry averages" when baselining a company. Comparing to averages has value, but new development process designs should be based on best-in-class. Second, specific competitive advantages or disadvantages that a company has must be incorporated into the thinking process. Functions with lower relative skill levels will require relatively more folks to accomplish the same results. Also, "monkey see-monkey do," is sometimes dangerous and will not result in the best answer for all companies. Use staffing ratio survey information as a guideline, and then apply the best judgment for a given situation in your own company.
For example, a baseline analysis that was conducted with a Fortune 1000 manufacturer of automated test equipment resulted in identifying the existing/current ratios for three of their functions involved in new product development [Figure 1C].
In this particular case, the closest survey information available was the "Instrumentation" category. Instrumentation covered several different types of instrument manufacturers, including automated test equipment. Assuming for the moment that industry averages are valid measures, the study indicated that they needed a few more Marketing professionals dedicated to new product development. Their ratio was 10 Engineers for every 1 Marketing professional. The industry average was 7.5:1. The comparison was even more pronounced for Manufacturing Engineering. Their ratio was 8.5:1. The industry average was 4.8:1. Approximately 40% more total resources were required for Manufacturing Engineering. They were unable to compare their Software ratios. The survey data did not capture the ratios between hardware engineers and software engineers.
After examining the survey data, the manufacturer decided to try to get more specific information. This is typical for first-time users of the Staffing Ratios analysis approach. They contacted an ATE trade association that they belonged to and asked to receive summaries of the financial and staff information across all the members that belonged to the trade association. Each and every year, member companies submitted summaries of their financial statements and human resources. Armed both with the survey information, and with the trade association information, the ATE manufacturer then went about developing appropriate ratios for their company.
Another organization-wide metric that is popular in many companies is Target Project Size [Figure 2]. Each and every company has unique capabilities and limitations in its ability to manage and execute projects to a plan. When a project is too large, the risk increases greatly and delays are certain. When a project is too small, the payback may not be worth the effort. It is highly useful to understand the project sizes and attributes that make projects in a company successful.
There may be several "development sweet spots" in any given organization. The sweet spots may be calculated using several different attributes on an X-Y axis framework.
One of the popular approaches is to take a representative set of projects, typically 10-15 in number, from the past 5-10 years in a company. Plot "total project person-years" against the "time-to-market" for each of the projects. Categorize each of the projects in two ways. First, determine whether the project was successful or unsuccessful. Second, determine whether the project was an incremental or a next-generation development effort. Plot the data on an X-Y axis. For most companies, the different sweet spots become immediately apparent.
When planned projects fall outside the known sweet spot ranges, examine the attributes of the project and make decisions to bring the projects back into the successful ranges. It is not possible, nor is it typically prudent, to have all projects within the sweet spots. On the other hand, if all projects fall outside the sweet spots the chance of success is reduced. Companies should strive for a portfolio of development projects that insure ongoing successes, balanced with a few high-risk high-return efforts.
One of the basic principles of Concurrent Product Development is to achieve "early cross-functional involvement." Numerous studies have shown that the product design becomes largely fixed in the very early stages of a new product development effort. Once the design becomes fixed, the costs to change it increase dramatically. As well, the time necessary to redesign-it-right is disproportionately long to the amount of time that it would have taken to do it right in the first place. With each and every one of these instances, companies shoot themselves in the foot. The frustration of manufacturing and field service professionals continues to rise. The wall between engineering and these functions becomes ever more rigid and tall. After many years of experiences like this, both "upstream" and "downstream" organizations become "numb." The situation is accepted as the "way it is" and companies are forever relegated to sequential development techniques.
In rough numbers, the design becomes 80-95% fixed once the first 10-20% of the development cost has been expended. In most traditional corporate development processes, only one or two people from the combined manufacturing engineering, production, purchasing, and field service functions have had any input to the design during this phase. In fact, in many companies, over 50% of the product development or R&D budget has been expended before there is any significant input from these "downstream" functions. The project is about 50% complete, and then full cross-functional involvement begins to occur. All engineering and manufacturing professionals are familiar with "The Wall." Concurrent Product Development processes are the way to bring it down.
The Concurrency Matrix is an baselining tool that is used to determine the degree of early cross-functional involvement in new product development projects. It is typically applied to a set of representative development projects to analyze the specific performance of each project, and to calculate the organization-wide profile and averages. In ongoing projects, it is applied during the planning phases to assist in determining staffing skill requirements and levels. At major development milestones it is used as a "check-up" tool [Figure 3].
The Concurrency Matrix must be constructed twice during the implementation of a CPD program. Initially, during the baselining phase, it must be constructed using the current company development procedure. Then, once the forward-looking concurrent development process has been defined, it must again be constructed to utilize the forward framework.
During the baselining phase, the program managers who were or are responsible for the representative portfolio of projects must get together to agree on common terms for the matrix so an apples-to-apples condition will exist to determine the Concurrency Matrix baseline. The program managers must agree on two areas. First, the list of functions that are central to the development of new products in the company. Each of these functions becomes one row in the matrix. Second, they must agree on the major phases that currently exist in the company new product development process. Although most every manufacturer has a documented new product development process, there is typically a wide range of approaches in applying it. The program managers must come to agreement on the four to seven major phases that apply across each of their projects. These phases become the columns of the matrix. With this information in hand, the matrix is constructed.
During the course of constructing the matrix it is typically useful to define one to three activities that occur in each box of the matrix. Again, the program managers should do this together. This chart should be limited to a single piece of paper. There are literally thousands of activities that functions perform during each phase of development. The challenge here is for program managers to agree on one to three of them for every "function-phase" box in the Concurrency Matrix.
This one-page Concurrency Matrix framework becomes the standard by which all representative projects are baselined. Each program manager now applies the tool to their projects. Once each project has completed this, the company average is calculated.
The Concurrency Matrix results in a great deal of information about the new product process in a company. Three areas are discussed here.
In the example just shown, it is clear that the field service function came on board too late. Similarly, but to a lesser degree, the Hardware Engineering and Manufacturing Engineering functions were late to get involved. Also, both the Marketing and Software Engineering functions had several "let downs" during the course of their involvement. This information constitutes the "project specific staffing performance." If similar occurrences are observed across several projects, or the representative project portfolio as a whole, then it is possible to draw meaningful fact-based conclusions about "systematic organization deficiencies." Systematic deficiencies will be discussed in the context of a case study later on in this section.
Using the Concurrency Matrix it is also possible to determine a "numerical calculation of % concurrent." The example shown here indicates that this new product development team was 70% concurrent. The math is straightforward. There are 20 boxes in the matrix. Each box is worth 2 points by definition. When the activities of a box are completely performed in the specified time period, then 2 points are awarded and the box is fully blackened. If a portion of the activities are performed, and/or they are performed late, then either a half-box or a blank box is awarded. Half-boxes are worth 1 point, blank boxes are zero points. In all, this product development team accumulated 28 of a possible 40 points. Dividing 28 by 40 yields 70% concurrent.
Finally, the ability of the Concurrency Matrix to identify "systematic organization deficiencies" is notable. One case study involved an instrument manufacturer that developed relatively complex instruments. A company elected to apply the matrix to 10 programs. Four of the ten Concurrency Matrices are shown here [Figure 3B]. Their results are similar to the other six projects.
Projects 1 and 2 were already completed and in the marketplace for several years. Project 1 was a tremendous success. Project 2 was barely acceptable. Projects 3 and 4 were still in process. It was generally believed that project 3 would be a bomb and that Project 4 would be quite successful.
The company went through the prescribed process of having the respective program managers determine the different business functions that were central to the development of new products. Next, they all agreed on six major phases that were common across their projects. A brief one-page framework was prepared. Each manager then rated their individual program results.
The exercise was somewhat simplified. Only two choices were available when completing the matrix, "black equals performed as required" or "white equals improvement required." This simplification helps visually when comparing the boxes. As an aside, one company to date has programmed the Concurrency Matrix into a formal performance measurement system that identifies and quantifies systematic deficiencies through automated tools.
In summary, Systems Engineering always had gaps in the early phases when their direction and input is absolutely essential to architecting and planning the project. The Marketing function was always late in getting on board. In several cases the project was half over before Marketing became seriously involved. Software and SQA had gaps on three of the four projects. Electrical Engineering had the best overall performance, followed by a rough tie between mechanical engineering and manufacturing. These facts were first discussed with the program managers and then with executive management.
The Concurrency Matrix baseline provided benefits immediately to the company. Even though the company had just begun to determine the overall CPD needs, and was still many months from implementing a program, it was possible to make immediate corrections based on these systematic deficiencies across current projects.
The Marketing function, which was really a Sales-oriented function, was further refined to define a category of product planners that would be dedicated to assisting engineering and manufacturing from the early phases of product definition throughout development of the final project.
The issue in Systems Engineering was that no one person really owned the function. An appropriate manager was assigned to define the requirements for a more formal Systems Engineering function. During the process, company management realized that this really was a core competency for complex instruments that they had completely overlooked in their company.
The situation with Software and SQA was determined to be important, but unavoidable to date. The presence of software in their product had increased dramatically over the past few years. This was true of every company in their industry and in many other industries. The problem was probably not unique to them. Nevertheless, the company needed to come to grips with the problem and the Concurrency Matrix baseline provided the jump start.
Improvements were initiated fairly quickly in all of these areas by executive management, and readily adopted by the program managers and program team members. The systematic and fact-based analytical approach which all the key players participated in created an environment for immediate consensus. Everyone felt great about taking some quick decisive actions so early in the project. There was little "wiggle room" for the power brokers and politicians. Everyone had to agree. The CPD program gained momentum from this point forward.
Development processes must be cross-functional and concurrent if downstream changes are to be kept to a minimum. All stakeholders must be able to contribute early to the definition of product requirements and to the product design. Typically, full staff ramp-up does not occur on new product development efforts until some time in the middle of a project. The middle is often operationalized as "design is almost complete and a prototype is now required." The middle is too late.
Analogous to the Concurrency Matrix is the "Project Staffing Speed" tool [Figure 4A]. The purpose of this baselining tool is to focus attention on the rate at which projects are ramped-up. The Concurrency Matrix will assist in defining "what" resources and "when" resources are required. The Project Staffing Speed tool assists in defining "how many" resources.
The philosophy behind this tool deals with the fact that any given project will require a determinable number of resources and time for each of those resources to perform their work. If the work is started in the future, then it will finish in the future. If the work is started now, it will finish sooner. The sooner the work is completed, the sooner the product gets to market.
The fast project ramp-up approach will work every time if three things occur during the Feasibility Phase. First, the analysis and experimentation during the Feasibility phase must reduce the development risk to a finite amount, on the order of 15% to 20% schedule prediction accuracy. Second, the customer requirements must be fairly complete and documented. The risk cannot be lowered to those levels if this activity is not performed adequately. Third, a thorough planning exercise to estimate the project resources must be undertaken. The planning exercise must be based on a known physical and functional architecture of the product. Specifications need not be complete, but the architecture must be.
Most all companies perform these three activities to some degree of completeness during Feasibility, but few companies carry them far enough to reduce the development risk. Too much work is left for the Development Phase. On the other hand, the project has been carefully estimated and a fixed amount of development funding has been approved for a "partially defined product and project." This simple flaw in development planning and estimating is causal to companies that consistently overrun development budgets and schedules by factors of two and three. A project that has not been defined cannot be accurately estimated.
Even if these three activities have not been performed as prescribed above, earlier staff ramping techniques will produce faster time-to-market. Product development professionals assigned to projects in a rapid ramp-up scenario will force the definition and planning to occur more quickly. One Staff Ramping Speed case study illustrates the point [Figure 4B].
This case study was conducted with a manufacturer of complex instruments. The company had a traditional development process. The Feasibility Phase was fairly informal and little rigorous project planning occurred. Development program time and cost estimates were quite loose and management typically approved projects knowing that the program team would be back for more funding next year. This scenario is not atypical in industry.
The actual Staff Ramping Speed results of four projects are illustrated. The complexity of each of these new products was different. Projects 1 and 2 were of similar complexity. Projects 3 and 4 were relatively more complex.
The analysis clearly indicates that projects 1 and 4 ramped-up the fastest. It is also clear that the rapid staff ramp-up lead to a reduced time to market.
If companies were to perform rigorous analyses during the Feasibility phase, they would be in a position to confidently ramp-up rapidly. New product development professionals would be gainfully employed as of development funding approval.
Of central importance in an ongoing CPD environment, but of relatively little importance during the needs assessment and baselining activities, are the "Team Contract" metrics. The scope of discussion in this third category of Team Contract metrics is appropriately limited.
Team Contract metrics are the "heart" of accelerated development processes. They arise from the analysis and planning work performed by teams during the Feasibility Phase. These metrics are the central focus of discussions between executive management and autonomous empowered teams at the point that development funding is approved for projects.
These metrics result from the team's own estimates of the resource and time requirements necessary to complete the project. These are the measures that the team is willing to live by during the development process, and be measured by upon conclusion of the project.
In an accelerated environment, more time is spent up-front during the Feasibility Phase to plan the project more accurately and reduce the development risk. The operating assumption in a CPD environment is that the team has accurately estimated the project and that management should believe the estimates.
During the development funding approval meeting some small amount of negotiation will occur, but unlike funding meetings in a pre-CPD environment the team is an equal participant with management. If the team is willing to commit to their estimates and live by them, than management can only undermine the team's buy-in by mandating different figures than the ones that the team spent many hours developing together. There must be a "trust" between management and the team regarding development estimates and time frames in accelerated environments.
The team, in conjunction with management during the development funding meeting, commit to each other's specific goals. These goals typically include overall time-to-market, product cost, and market size estimates. A "representative team contract" may include several other goals as well [Figure 5].
Specific ranges are negotiated around each of the goals. As long as the team is operating within the ranges negotiated with management, they will be free to execute the project virtually independent from external interference. If the team stays on course, the only management reviews will be the ones that occur at the major phase transition points or milestones during the development process. If the team's actual performance goes outside the negotiated ranges, then management reserves the right to conduct a project review.
The negotiated ranges will differ for each project. In some cases, time-to-market will be the critical factor for success. In other cases it may be the product cost and planned profit margin. The negotiated range around the most critical items will necessarily be smaller than less important goals.
The example shown here indicates that product cost is of the utmost importance. The negotiated range that will trigger a management review is +5%. The development cost and time-to-market goals are relatively looser, in the 15% to 20% range. Similarly, if the market size shrinks by 20% a management review will be necessary.
The representative baseline tools discussed in this section both focus on time-to-market. One tool analyzes development time in a static manner, the other in a dynamic manner. Static measurements have been maintained by companies for years. The key to the future is to reduce the granularity of the measures to one or two increased levels of refinement. Dynamic measures are rarely used by companies, although the technologies behind them are simple. The dynamic method discussed here is a take-off on simple regression. More advanced approaches utilize tools similar to those used by most Marketing functions to "predict the future." Exponential smoothing and other dynamic forecasting models are representative examples.
Static measures are fairly intuitive and obvious measures. Many companies have significant experience with this metric and it is important that they get more experienced in the future.
Applying static measures in several ways to a representative portfolio of projects will yield new information in each different analysis. With a single set of static data, several measurements are possible. For example, it is possible to calculate overall schedule forecast accuracy, examine the variation in predicted and actual phase times across projects, and identify the places where the development processes typically breaks down all with the same set of data.
First, the basic data for each program must be gathered and analyzed [Figure 6A]. In this example, "total" and "by phase" are measured. It is also useful to go to another level of detail and measure "time between milestones." Specialized measures such as "time to completed specifications" and "time to design freezing" are also quite useful, especially in an ongoing CPD environment.
This particular project missed the development schedule by 26%. The project took 55 months, but only 47 were planned. There was slippage during each phase of the project.
Once the project specific metrics have been calculated, the next step is to normalize the projects so that the different sizes and durations of the project may be compared in a like manner. Normalization is typically done by turning time-based measures into percent-based measures [Figure 6B].
For this particular company, the randomness of the figures was fairly representative of the randomness of the company development process as a whole. This single result further emphasized the need for stability and consistency in the product development process.
Dynamic measures are useful both for tracking the progress of a development project, and for quantitatively calculating the completion date of a project. Most completion dates that companies rely on are calculated during the course of a project by the project team. Few checking mechanisms are in place to provide "second opinions" to the team's own estimates.
Dynamic Time-To-Market is an extremely easy tool to use during baselining activities, and in ongoing project environments [Figure 7A]. Every time a schedule prediction is made by the team during the course of a project, the date is plotted on the graph against the date that the prediction was made. As time passes, and several predictions are plotted, it is possible to extrapolate the data to estimate a prediction date. The tool inherently incorporates the ongoing forecast error, whether it be positive or negative, into the extrapolation.
In this example, project A is clearly on track. Regardless of the date of prediction, the predicted date remains the same. A project that is on schedule will always proceed directly horizontally towards the diagonal line. Project B, on the other hand, is off-track. Projects that are slipping will start trending upward and asymptotic to the diagonal line. The more the project is off-track, the more vertical the slope of the line becomes. If a project has a serious short term slip, the line will go vertical indicating an infinite completion date. In the rare event that a project is ahead of schedule, the trend line will move downward and to the right.
The "second opinion" of time-to-market is calculated by extrapolating the actual project line to intersect the diagonal line. At the intersection, "drop a perpendicular" to the "predicted date" axis. This date will provide a sound "second opinion."
An application of Dynamic Time-To-Market to four different projects provides some interesting results [Figure 7B]. First, the graphical presentation clearly indicates projects that are slipping. Whenever any given data point for a project appears "above" its predecessor data point, the project is slipping.
Second, the most recent predicted launch date may or may not be an accurate prediction of the actual launch date. Current predictions become modified by past history in this tool. For example, look at the third data point for project "2". In the middle of 1985 project was predicted to complete approximately one-year later in the middle of 1986. Using extrapolation based only the first three data points, the project would be forecasted sometime during the middle of 1987. This is one whole year longer than the team's prediction at the time. In the final analysis, the project completed in the latter part of 1988. The application of the Dynamic Time-To-Market tool yielded a more accurate forecast of completion than the current estimate of the team at the time.
Next, examine project "3". Start the analysis with any data point associated with this project, except for the final data point which is "off the chart." Each and every time that the team estimated a predicted launch date, the next prediction indicated the prior prediction was off by at least one year. A rough estimate indicates that with a slip rate of a year per year that this project may possibly complete some time during the year 2900. Project "3" is clearly a problem project.
Management should have begun asking tough questions when the second data point was plotted. Once the third data point had been plotted indicating the unacceptable and ongoing slip rate, company management should have become involved in redefining the project scope and goals. It is not always the team's problem that projects slip. In many cases the task handed to the team is too great, the resources given to the team may be too few, and numerous other reasons exist. Sometimes teams need help.
Problem projects are quite easy to identify, with or without this analytical tool. Dynamic Time-To-Market at the very least provides framework for identifying problem projects and for getting a "second-opinion" on the most realistic prediction of actual development time and launch dates.
Now move into the future. It is somewhere between the years 2000 and 2005, approximately ten years away. The entire reference plane for viewing product development has been redefined. Global competition is occurring from twice as many countries. It is virtually impossible to know where, when, and how companies will enter markets that your company competes in. Development cycles are now half of what they used to be. For a good many industries, the entire development cycle will be under one year, most likely on the order of 4-8 months. This is quite realistic. Many prominent industries have development cycles under one year in the early 1990s. CAE/CAD/CAM integrated system frameworks will exist that automatically make use of prior designs and maintain reusable parts and software libraries. In a matter of hours, initial prototypes will be able to be produced. The process of design and development will be redefined.
In this redefined business environment, it will be necessary to make assessments of products and projects virtually days into their development cycle. What today is considered unmeasurable, will be totally measurable. Product development will undergo in the 1990s what manufacturing and materials functions experienced in the 1980s.
The companies that see into the future now and begin to prepare for it will be the ones that are best positioned to succeed.
Goldense Group, Inc. is among the first companies in the US to develop and apply advanced metrics frameworks for the future. Some of our forward-looking concepts, which are applicable in selected environments today, focus on measurements taken early-on in the "soft stages" of development projects.
GGI refers to these metrics as Process-Oriented Concurrency Metrics or "POCMs," pronounced "poke-ems." The translation is literal and direct. Numerous simple measures will need to be made early-on in the development environments of the future [Figure 8A]. Management and teams will measure project progress at a much greater level of granularity and much more frequently than practices of today.
POCMs may take a few moments to absorb. Their simplicity is disarming and few companies would consider measuring these items as primary measures in traditional environments. They even fly in the face of values that many managers hold as their "deemed rights" in the 1990s. This strained condition will exist for several years to come, until many companies have fully internalized the implications of accelerated development cycles and realized the full brunt of foreign competition.
POCMs are proactive metrics. The information they yield allows for actions on projects-in-process today, not the next development cycle. Popular measures such as Engineering Change Orders are totally reactive. All learning is hindsight and only leveragable on future projects or redesigns.
Rapid metrics consist largely of measures taken well before product design is complete and released to manufacturing. There are literally hundreds of measures that can be made in these early phases of development. The metrics with the most predictive capabilities for any given company should be chosen.
POCMs should be focused two ways. First, there should be metrics that measure only the softest aspects of new product development process quality. Second, there should be metrics of the quality of the product being designed that are driven by the quality of the development process. This is why the term "process-oriented" is used. While both process and product measures are taken, the "driver" for the metric lies in the overall quality of the human activities during the development process [Figure 8B].
Early adopters of GGI's rapid metrics have found poke-ems serve to keep both teams and management honest during the "development contract." They are valid additional measures of project performance.
For instance, a relevant POCM metric is "core-team turnover." Few will argue that turning-over key core team members does not affect the project duration and outcome. Typically, it is the management group that causes turn-over and resource-shifts that affect the project plan. Measurements in this area will help reduce the number of times that a team "thrashes" during the development project as critical resources are shifted to other projects and/or are yanked for short periods of time.
Conversely, "number of milestones completed on-time" and "number of design reviews completed on-time" are valid measures of team-controllable metrics.
Keeping a simple count of "on-time hits and misses" of key project activities is a valid indicator of the future. Most every project team that is late on major and minor milestones still promises that they will hit the scheduled plan date. Then, some short period of time before the actual date, a meeting is called to announce a formal schedule slippage. On-time hits and misses on "sub-program-level milestones" are an effective honesty-keeping metric for teams.
Numerous other examples exist. POCMs help to rev-up project speed by focusing collective team attention on some of the finer but significant aspects of the program plan. They are typically managed within the team, but are visible in management information systems.
Manufacturing's next frontiers lie in earlier involvement in product definition and development efforts. The 1980s resulted in achieving manufacturing improvements that were controllable from within the manufacturing function. To realize the next level of improvement, manufacturing must become an equal player in a totally cross-functional development environment. Some 80% of the product design become fixed when a very small percentage of the product development budget has been expended. Improvement opportunities lie in early involvement.
Business improvement initiatives that define-in all business functions and processes in a company are highly risky. The biggest benefits are achieved at the conclusion of these major projects, if they conclude at all. Post-mortems on early TQM initiatives are already raising questions about real benefits. Organization-wide business process reengineering initiatives are similarly risky in nature.
Concurrent Engineering is synonymous with reengineering the new product development function in a company. It is a high value reengineering initiative. The goals are clear.
The scope is finite.
Gaining consensus on the specific needs for a Concurrent Engineering program in a given company is best achieved through the use of a fact-based approach. A series of metrics and analytical tools should be applied to a representative portfolio of past and present development projects by knowledgeable and responsible people to determine and establish the current baseline of company new product development performance. These tools should then be applied in an ongoing manner on all future projects and the measurements should be recorded.
There are 5 major areas where metrics should facilitate and promote a rapid product development environment. Of these five areas, four areas are directly relevant to establishing baseline performance and forging a consensus on the specific needs for concurrent engineering programs in a given company. Team Contract metrics apply specifically to ongoing concurrent engineering programs.
Rapid Process-Oriented Concurrency Metrics - POCMs will be required for the accelerated development environments of the 21st century.
*** *** *** *** *** *** *** *** ***
This is a lecture that Mr. Goldense presented on December 3, 1993 at the DISTINGUISHED SPEAKER LECTURE SERIES held the Gordon Institute of Tufts University located in Medford, Massachusetts.
BIOGRAPHY OF BRADFORD L. GOLDENSE
Brad Goldense is Founder and President of Goldense Group, Inc. [GGI], a ten-year old Cambridge, Massachusetts consulting and education firm concentrating in advanced business and technology management practices for line management functions. GGI is a virtual firm with a small number of staff and numerous alliances with other professional service firms.
Mr. Goldense has consulted to over 50 of the Fortune 1000 and has worked on productivity improvement and automation projects in over 150 manufacturing locations. He has worked in North America, Europe, and the Middle East. Abbott Laboratories, Sikorsky Aircraft, Carrier Corporation, Molex, Monsanto, and Bose Corporation are representative among GGI's clients.
Prior to founding GGI in 1985,
Mr. Goldense worked for CSC/Index, the company that invented and initially developed the "reengineering" body of knowledge.
He worked for Price Waterhouse's Manufacturing Consulting Practice.
In the late 1970s, he worked for Texas Instruments as a Design Engineer and then Program Manager where he was responsible for managing complex engineering projects. Brad had turn-key responsibility for designing and starting-up two TI manufacturing plants.
Mr. Goldense is a Member of the faculty at the University of Dayton in Dayton, OH and at the Gordon Institute of Tufts University in Medford, MA.
Mr. Goldense holds a BS in Civil Engineering from Brown University and an MBA with a concentration in Cost Accounting from Cornell University.
Brad is a Certified Manufacturing Engineer [CMfgE] by the SME, a Certified Computer Professional [CCP] by the ICCP, and is Certified in Production and Inventory Management [CPIM] by APICS.
He is a member of the Board of Directors for Society of Concurrent Engineering [SOCE] and is the President of the Boston Chapter. He maintains memberships IEEE, ASEM, ASME, ACM, APICS, ASQC.
Brad holds an elected position on the University Council of Cornell University and is outgoing Chairman of the Cornell Business School Alumni Association in Boston.
Mr. Goldense is an member of the Society of Manufacturing Engineering's Computer and Automated Systems Association [CASA] National Technical Committee and Past-Chairman of the SME CASA Chapter located in Boston.
Brad has authored numerous articles on competitive product development and manufacturing with known industry publications such as Design News, Machine Design, Purchasing, Manufacturing Breakthrough, World Class Design To Manufacture, and Industry. He is an internationally recognized expert on rapid product development.
© Copyright 1996 Goldense Group, Inc. All Rights Reserved
