Introduction
New Product Development Projects are judged not only by the execution success of the project, but also by the marketplace success of the product. Both types of success, in turn, depend on efficient cross-functional integration of multiple technical disciplines. This integration is typically accomplished using a structured project management process with reuse of proven project management practices as the integrating tool. While the functional specialists on the project teams generally recognize the need for structured reuse of best practices within their own disciplines, they often show resistance to applying the same type of structured best practice re-use to the integration (project management) part of the product development process.
“But we're different” and “you can't schedule the unknown” are objections continually heard by any group attempting to standardize (or introduce) a structured project management process across related new product development organizations. In fact, these objections can become quite intense if the organizations involved have different business models and/or customer models or a history of strong functional organization control. Even though 90% of the project planning and execution tasks are common, the involved organizations will invariably focus on the 10% of the tasks that are different and use them as a reason not to standardize on the common 90%. The basic problem then becomes one of how to bring about organizational “buy-in” to the benefits of project management process standardization without unduly limiting their ability to respond to legitimate business process differences.
Often the first change management task is to get the people in the involved organizations over the uninformed mindset that a project management process must necessarily involve either complete “bureaucratic control” or “creative anarchy.” In analogy with computer systems, they often assume that project management is either “mainframe” (all uses managed and controlled by a central group) or “individual PC” (everyone chooses what they want). In fact, to carry the analogy further, a better approach is often one of “distributed project management.” In this model, the upper level structure of “what to do” and “when to do it” requirements (the project management environment) are mandated and standardized. Standardized “how to do it” tools are provided for the development organizations to use, but the details of “how to do it” are left to the individual organizations to tailor to their particular business needs (within the upper level requirements). In analogy with distributed computing, there is a centralized support group (often called a Center of Excellence), but its role is to provide centralized expertise and consulting rather than centralized management of individual projects.
This paper will present a case study of how this “distributed project management” model was successfully implemented within the Mixed Signal and Analog Integrated Circuit New Product Development groups of Texas Instruments in Dallas. The upper-level “what-to-do” requirements (project management process phase structure and phase deliverables) will be described and examples will be given as to how the deliverables were tailored to specific business models within the framework of these upper-level requirements. Actual product development metrics for two of the seven business units using the process will be presented and discussed. The particular two business units were chosen because they have very different business and customer models. One develops mass-market catalog products to fill specific product market space needs and the other develops custom and semi-custom products to meet specific customer requirements.
Because the business/customer models of the two business units are different, different results metrics are used to track their new product development performance. Using appropriate metrics, it will be discussed how the mass-market catalog product business unit increased its product development throughput efficiency by a factor of 2.5 in three years while simultaneously increasing its yearly new product development rate almost six-fold. Likewise, it will be shown that the custom/semi-custom product business unit improved its ability to meet customer delivery commitments by 30% in a similar time period while simultaneously increasing it yearly new product development rate by almost a factor of five.
Finally, it will be discussed how successful project management is a necessary, but not sufficient, condition for successful new product development. Other business processes must be in place and successfully executed in tandem with successful project management to achieve desired results in the marketplace. Because of the need for the separate processes to work together smoothly, the project management process must be adaptable enough to work with different business processes and flexible enough to evolve as these business processes change. When done successfully, the resultant tailored process not only increases individual project efficiency by allowing the team members to concentrate on those aspects of the project which are truly unique, but it also becomes a tool to help new personnel efficiently learn the business.
Exhibit 1. New Product Development Project Management Process Flow
Project Management Process Overview
Exhibit 1 is a diagram of the standardized project management process flow. The project management process structure is a version of the standard phase gate process tailored for integrated circuit development. Five project phases are specified; Business Plan, Project Plan, Execution, Release to Production and Production. Within the Execution Phase, three subphases are specified; Create, Make and Evaluate. There are five phase reviews, three of which (Kick-off, Project Plan, and Post Characterization reviews) are sponsor level “go/no-go” Decision Point Reviews and the remaining two (the Product Design and Closeout reviews) are team peer reviews. There are also weekly and monthly tracking project reviews as well a specification control process for maintaining configuration control of the specification during the development of the product.
Exhibit 2 is a diagram of the relationships between the process description documents within the distributed project management framework. This “documentation tree” begins with a released specification of high-level “what to do” and “when to do it” requirements. It is the only “auditable” released specification in the “documentation tree” and is the only document under configuration control. This high level specification is ISO 9001 compliant and describes “what to do” and “when to do it” to meet the process requirements, but not “how to do it.” This document specifies the deliverables for each phase, the information to be included in the agenda for each review, and the “go/no-go” decision criteria for each decision point review. In addition, product development team organizations with high-level roles and responsibilities are defined along with specific subprocesses for specification change control and release to production. In effect it is a high level collection of project management best practices, which have been found to be most useful for integrated circuit product development. In keeping with the corporate computing analogy, this document is the equivalent of the computing environment specification in that it specifies what the project management environment will be.
Underneath this high level specification is a second level series of approved general templates, forms, review agenda and procedures, which were developed to be fully compliant with the upper level requirements. Because these general templates are not released documents, each product group is encouraged to tailor them to their particular business needs. Again, carrying through the corporate computing analogy, these documents are the project management equivalent of the “application programs,” which are provided and maintained within the overall project management environment.
To help the business groups and individual projects successfully tailor these templates, the third level of documentation provides continually updated procedures, results and sample templates developed by the various development groups. This best practice sharing for both the project management and functional excellence aspects of the projects is the project management equivalent of the sharing of application programs in the corporate computing environment analogy.
Project Management Process Implementation
In 1996, Texas Instruments reinvented itself to focus on its core semi-conductor business competency and achieve dominance in certain chosen segments of the semi-conductor market with accompanying high levels of profitability. It was recognized that to do this a steadily increasing number of products would have to be brought to market using a steadily increasing number of recently hired product development personnel while simultaneously steadily increasing product development efficiency. One of the major initiatives undertaken to accomplish this within the Analog and Mixed Signal Product Divisions was the “distributed project management” process discussed here.
Exhibit 2. Distributed Project Management Documentation Tree (Web Based)
The design and implementation of this distributed project management process initiative was accomplished in stages. First, a high-level management team carried out the design of high-level process specification of the project management environment. This team was made up of division and department level product-line managers, functional managers and support group managers and was facilitated by an outside group of project management consultants. This team make-up ensured that the resulting specification achieved standardization at the level needed by upper product-line management and properly described the high-level interface needed to the associated support organizations such as manufacturing and marketing.
In addition, this upper-level team properly resisted the temptation to specify the process details. They recognized that to achieve “buy-in” and maintain flexibility, the details would have to be worked out by the actual users of the process, not the managers. They also understood that the details could not be static but would have to evolve and adapt to changes in the business environments and to grow along with the increasing level of project management process maturity of the product development organizations. To do this, the R&D Effectiveness team was chartered to facilitate a Project Management Center of Excellence staffed by representatives of the user groups themselves.
Another team of experienced product development project managers kicked-off the implementation by developing the first iteration of the generic standard forms and templates, which tied to the upper-level specification. Next, a training course was developed which explained the philosophy behind the process specification and how to use the standard forms to meet the intent of the process and which was used to train over 1,000 people in two months. Finally, a continuous improvement structure was put in place consisting of a steering team and a continuous improvement team. The steering team was made up of department level product-line managers and functional managers, which were designated to be the “owners” of the process specification and who monitored and directed the progress of the process implementation. The continuous improvement team was made up of individual contributors from the product groups using the process, with the membership rotating periodically to insure a steady input of new ideas. It was the continuous improvement team members who actually developed the best practice sharing documentation and tailored the standard forms to individual business needs. Thus, the best practices and standard forms were developed and updated by the people who would actually be responsible for using them.
Project Management Process Tailoring Examples
The high-level released specification provides a consistent upper-level structure both for management oversight and review and to provide a consistent interface to other business groups such as manufacturing and marketing. Allowing the distinct business units to tailor the standard templates and procedures to their specific needs within the upper-level structure allows them the flexibility they need to be successful. Each tailorable template deals with a specific best practice with all the specific best practices held together by the upper-level structure. Examples of two such specific best practices will be discussed as a way to show how the “distributed project management” process is tailored to specific business needs.
The first best practice-tailoring example deals with risk assessment and risk mitigation. The high-level process specification states that during the Project Plan phase, a risk mitigation plan will be developed and presented at the Project Plan review for sponsor approval. It further states that this plan will be updated and reviewed at the monthly tracking reviews, product design review and post-characterization review. It does not, however, specify in detail how this will be accomplished.
Exhibit 3. Relative Development Throughput and Relative Number of Products Brought to Market Versus Year for Catalog Product Business Unit
To guide the team in the implementation of this specified best practice, the standard forms portion of the web site provides a Failure Modes and Effects Analysis (FMEA) template, which lists the risks and risk mitigation actions generally encountered in integrated circuit product development. The project management best practice sharing section, in turn, provides a list of questions for the teams to ask themselves in putting together their specific FMEA, a list of commonly encountered specific manufacturing hand-off risks and their potential impact, and lessons learned from previous projects. It also provides a spreadsheet for assessing the technical complexity of the design to ensure that development personnel with the appropriate level of expertise are assigned. The functional specialty best practice section, in turn, provides guidance and links to other web sites for the latest risk mitigation strategies for the individual functional risk elements in the plan.
In this way, each new project can tailor its risk mitigation plan to the specific business needs of the project. For example, in the mass-market catalog businesses, efficient use of scarce resources to maximize the number of products developed to adequately cover a target market segment is of prime importance. In the custom/semi-custom business units, on the other hand, efficient use of resources is not as important as providing specification compliant product to the customer in time to meet the customer production ramp. By using this “distributed project management approach,” each project can develop its risk mitigation plan to address the staffing, development and manufacturing risks in a standardized way while giving priority to the risks unique to its business model.
The second best practice-tailoring example deals with specification compliance assurance. The high-level process specification states that during the Project Plan phase, a plan for full design characterization and test will be developed and presented at the Project Plan review for sponsor approval. It further states that this plan will be updated and reviewed at the monthly tracking reviews, product design review and post-characterization review. It does not, however, specify how this will be accomplished.
To guide the team in the implementation of this specified best practice, the standard forms portion of the web site provides a “specification compliance matrix” (SCM) template for the project team to prepare and update as the project progresses. The template provides lines for listing each performance parameter and columns for the specification parameter value, the predicted value based on design simulations, actual values based on measurements on a statistically valid number of units, and the manufacturing variation margin. The project management best practice section provides examples of filled in templates from various business units and guidance on how to determine how to determine which parameters to include in the matrix. The functional specialty best practice section, in turn, provides links to the latest tools and techniques for design performance simulation, performance characterization and test and manufacturing margin analysis.
In this way, each new project can tailor its test and characterization plan to the specific business needs of the project
Exhibit 4. Actual/Promised Commitment Ratio and Relative Number of Products Brought to Market Versus Year for Custom/Semi-Custom Product Business Unit
For example, the custom/semi-custom projects use the specification compliance matrix to make certain that they are meeting all the customer requirements with enough manufacturing margin for adequate profitability. The mass-market catalog will use the SCM to make certain that the product performance is correctly differentiated from other products in the product line to adequately cover the targeted market space.
Results
Exhibits 3 and 4 show the results for specific mass-market catalog and custom/semi-custom business units. For both business models, the rate of product introduction increased dramatically while simultaneously improving key business metrics.
For the mass-market catalog groups, the key metric tracked in Exhibit 3 is the development throughput, or number of new products developed per million dollars of R&D expenditures. It can be seen that the mass-market catalog product business unit increased its product development throughput efficiency by a factor of 2.5 in three years while simultaneously increasing its yearly new product development rate almost six-fold.
For the custom/semi-custom groups, the key metric tracked in Exhibit 4 is the ratio of the time taken to deliver a product to the customer to the time originally promised the customer. It can be seen that the business unit improved its ability to meet customer delivery commitments by 30% over a period while simultaneously increasing it yearly new product development rate by almost a factor of five.
In 1996, this ratio was 1.42, meaning that on the average the actual product delivery time was 42% greater than promised. There was an immediate large improvement when the project management initiative was introduced, with smaller improvements following. Since the “ideal” ratio is 1.0, the closer the ratio gets to 1.0, the harder it will be to improve.
Conclusions
Even though this paper is on project management and directed at an audience of project managers, it should be noted that the above results were not be achieved by disciplined project management alone. Simultaneous with the “distributed project management initiative” described above, initiatives were also launched to achieve industry excellence in emerging market identification, customer need identification, product design robustness, and next generation manufacturing processes. However, it can be argued that it was the project management initiative that provided the “glue” to integrate all these functional excellence initiatives into effective product development. By specifying an upper-level structure for all projects to follow while providing tools that could be adapted to specific project needs, “buy-in” by the functional specialists was achieved along with flexibility needed to adapt to fast changing (and different) business environments. The resultant tailored process not only increased individual project efficiency by allowing the team members to concentrate on those aspects of the project that were truly unique, but it also became a tool to help new personnel efficiently learn the business.
In addition, a robust continuous structure was designed into the process from the beginning. This structure is a Center of Excellence type of structure where the membership of the COE is drawn from the user groups themselves on a rotating basis. A small support group of project management specialists supply facilitation and continuity for the process implementation, but do not get involved in actually managing the projects. In this way, “buy-in” of the team members is maintained while keeping the support costs low.
