Embed Size (px)
Citation preview
Technology Stage-Gate™:A Structured Process forManaging High-Risk NewTechnology ProjectsGreg M. Ajamian and Peter A. Koen
Traditional Stage-Gate™ (SG) (Cooper 1993) or PACE® processes (McGrath andAkiyama 1996) assume that there is little uncertainty associated with the technologiesto be utilized. However, the inability to manage high-risk technologies as part ofproduct development is frequently the cause of canceled or significantly delayed newproduct development projects. Unlike product development, the ultimate outcomes oftechnology development efforts are unpredictable. Prematurely introducing atechnology into the product development process when there is high uncertainty thatthe technology will ever meet the desired specifications often leads to project delays,project uncertainty, and project cancellation.
We have found that a different management process, the technology Stage-Gate™ (TechSG) process, is needed to manage technology development efforts whenthere is high uncertainty and risk. TechSG, initially described by Eldred and Shapiro(1996) and Eldred and McGrath (1997), brings a structured methodology formanaging new technology development without thwarting the creativity needed inthis early stage of product development.
The overall objective of this chapter is to provide the reader with more insightinto the process and to describe the tools and methodologies that make up theTechSG process. The process is specifically intended to manage high-risk technologydevelopment projects when there is uncertainty and risk that the technology discoverymay never occur and therefore the ultimate desired product characteristics mightnever be achieved.
To understand the difference between TechSG and traditional SG processes andthe need for the TechSG process, consider the following extreme example. Imaginethat due to unanticipated changes in regulations a business has decided that it willneed a new product in its line that would best be described as "water withouthydrogen." If the business immediately began a traditional SG process, it would verylikely get bogged down in the product development stage, since no one had everproduced such a molecule. The product development team
would be trying to complete the product design while their scientists were still tryingto discover how to make the molecule in the laboratory. By using a TechSG processto focus on the technology development issues (with a long-term view towardbusiness strategy, plans, and needs), the business can manage the technologydevelopment effort separately. The effort would continue until it is feasible to startproduct development or it becomes evident that the risks are too high or the rewardstoo low to pursue the technology. In this example, the TechSG process would beused to manage the technology development effort until the risks have beensubstantially reduced by demonstrating the ability to at least produce such amolecule in the laboratory.
The overall innovation process may be divided into three areas: the fuzzy frontend (FFE), new product development (NPD), and commercialization, as indicated inFigure 11-1. Many companies utilize traditional SG systems to manage the NPDprocess. For most companies, even for a totally new offering, product developmentis essentially a known, predictable, and repeatable process. From 70 to 85 percent ofthe process is the same from product to product, e.g., planning, laboratory trials,preliminary design, internal and external testing, manufacturing scale-up, supporttraining, market launch planning, and commercialization (Cooper 1993). Creativityis less of an issue in the actual development and commercialization of the product.Project leaders need good project management skills and decision makers need toconcentrate on the overall costs and benefits to the business. Traditional SGprocesses have brought dramatic reductions in product development cycle time inmany companies by bringing structure and an overall business process to the NPDprocess. However, a frequent complaint about and limitation of the traditional SGprocess is that product development begins when the ultimate outcome of thetechnology development efforts still contains significant uncertainty and risk. Thishas often been a source of frustration, causing significant delays and wasted
FIGURE 11 -f. Overall innovation process may be divided into three parts: the fuzzy frontend, new product development, and commercialization.Traditional SC processes are utilized to manage protects in new product development.TechSG is used to manage high-risk projects within and at the transition between thefuzzy front end and new product development.
Commercialization
New ProductDevelopment
FuzzyFront End
Traditional Stage Gate Process
Technology Stage Gate Process
effort as the advantages and limitations of the new technology are determined. Thetechnical uncertainty and continuing missed project deadlines associated withintroducing a yet-to-be-completed technology discovery often results in canceledprojects.
TechSG lies within and between FFE and the traditional SG process. The FFErepresents the initial part of product development, from idea generation todevelopment of a concept that includes primary features and customer benefitscombined with a broad understanding of the technology needed. The traditional SGprocess typically begins with a well-defined concept, although many companiesinclude the FFE in the initial part of the traditional SG process. Due to highuncertainty—especially in high-risk projects—we prefer not to include the initial partof the FFE in the traditional SG process. Further, we recommend that high-riskprojects do not enter the traditional SG process if the project contains technologieswhere the ultimate outcome of the technology development effort has elements ofboth high uncertainty and high risk. Conceptually, the traditional SG portion of theproduct development process will not start until the TechSG process is completed andthe technology development risks have been substantially reduced. In actuality, manyprojects start the traditional SG process in the later stages of the TechSG process,when significant risk has been reduced, in order to get to the marketplace earlier.
New technology development is by definition new, different, and unpredictable.It is difficult to capture and leverage past experience for future efforts, making cycletimes difficult to estimate. One cannot "schedule" technology discovery. The range ofpossible experiments and their outcomes is almost limitless. Detailed overall projectplanning is therefore impractical. Too much structure or repetition of past work canseverely inhibit creativity. It is often difficult to determine when the new technologyis ready to transition to product development. This can be a very subjective decision,arrived at through informed discussions. Much more than in traditional SG, duringnew technology development, project leaders need the ability to manage uncertaintyand do "good science" while focusing on project goals. (Examples of project goals fora next-generation copier [see Table 11-3] could be higher productivity, environment-friendliness, and lower operating cost.) Decision makers need to be able to balancerisk and probability versus business needs and potential rewards.
The overall purpose of the TechSG process is to bring both scientific andbusiness rigor into the technology discovery process, to better select and allocateresources to high-risk projects, and to reduce technology development times. Thehallmark of a well-functioning TechSG is a project that is being executed using soundscientific principles and is properly resourced. Traditional SG projects also need to beproperly resourced, but the importance of doing good science is less of an issue sincethe technology is already known. Initial reluctance to implement a TechSG process isrelated to the presumption that the added structure will inhibit creativity. In fact, wehave found just the opposite. Technology development teams embrace the TechSGsince it brings a scientific rigor often missing in many of their projects
Traditional Stage-Gate™ Technology Stage-Gate™
FIGURE 11-2 In traditional SG, shown on the left, the gates are transparent. The productdevelopment team can "see" all the deliverables at the gates. In contrast, in TechSG, shownon the right, the gates are opaque. The technology development team can only "see" to thenext gate and understands that the deliverable may change as the technology is developed.From Eldred and Shapiro 1996. Reprinted with permission.
due to inadequate manpower allocation and financial resources, lack of the correctscientific expertise, and lack of peer review.
The differences between the traditional SG process and TechSG may beconceptualized in Figure 11-2. In the traditional SG process the gates—representedby walls—are transparent, since most of product development is predictable. Thegates can be identified, clearly defined, and planned for, and their outcomes areknown right from the beginning of the project. The product development team can"see" through the walls to the end of the project and can clearly envision the endresults. Like the traditional SG process, the TechSG process consists of a series ofgates or reviews. However, the details of the development plan are known only tothe next stage. Although there is always a rudimentary overall plan for the entireproject, the number of gates is only an estimate at the start. In new technologydevelopment, you know only what you are going to do next, not how it is going toturn out. So you cannot plan subsequent actions in great detail. Thus the gates in theTechSG process are opaque for all but the next stage. In contrast to the traditionalSG process, in the TechSG process the gates are different in nature and the numberof gates is highly variable. There is overall agreement about the desired outcome—the last gate—but there is uncertainty about how to get there. The TechSG processrecognizes that the deliverables at each of the subsequent gates may change due tothe need to take a different approach, unexpected discoveries, or scientific barriersor limitations uncovered during the technology development process.
The primary benefits of using a formal business process are to ensure thatcritical, limited resources are allocated to the projects of most importance
TTRR00
TTRR11
TTRRNN--11
TTRRNN
to the business and to reduce overall the time to market of new technologies and theproducts that they enable. The technology planning and review process highlightsbusiness, process, and investment issues very early in the project and allows them tobe more effectively addressed. Technology goals are well understood by all involved,are aligned to the product/platform strategy, and are revalidated from stage to stage.The TechSG process creates a collaborative environment between the technical andbusiness communities, whether the entities are within one company or a joint venturebetween companies.
The remainder of this chapter is broken up into two main parts. The first partexplains each of the six elements of the TechSG process. The second part discusseshow this process may be implemented.
DESCRIPTION OF THE PROCESSThe TechSG process consists of six elements, as represented in Figure 11-3: theproject charter, the technology review committee (TRC), the technology reviewprocess, structured planning, the technology development team, and the processowner. While similar in name, in most cases these elements are different from thoseused in the traditional SG process for managing NPD. A comparison between each ofthe elements is shown in Table 11-1.
All TechSG projects start off with a project charter to define the initial scope andobjectives of TechSG effort. Although the TRC has business representatives, it isprimarily a technology-focused team. Representatives from both the marketing andR&D divisions along with internal and external scientific peers are part of thisdecision-making group, which is responsible for making a go/no-go decision at eachof the gates. The technology review process mainly
FIGURE 11-3. Six elements of the technology Stage-Gate™ (TechSG) process,
Technology Review Committee(TRC)
ProjectCharter
…
TR 0TR 1
TR 2TR TR N-1
TR N
Technology Review Committee(TRC)
Technology Development TeamStructured Planning
ProjectCharter
ProcessOwner …
TR 0TR 1
TR 2TR TR N-1
TR N
0 1 2 N-1 N
TABLE 11-1.Comparison of the Traditional SG Process with the TechSG Process
TechSG Traditional SG
ProjectCharter
Formal pre-agreement with uppermanagement on the technologiesto be investigated and the high-level approach.
Formal pre-agreement with uppermanagement on the entire project,including the timing expected forproject completion.
ReviewProcess
Emphasizes the technologyportion of the project and focusesalmost entirely on the technologywork and timing to the next gate.The gates are relatively opaque,with the deliverables known onlyto the next gate. The number ofgates is unknown and variessignificantly between projects.
Discusses the entire project,deliverables, and timing expectedfor the entire project. The gates arerelatively transparent, with well-accepted deliverables known for allgates from the start of the project.Number of gates is usually thesame for all projects.
ReviewCommittee
Representation focused ontechnology. The chairmantypically is the technology leader,with business representatives andscientific peers.
Broad representation of keyfunctions of the business: R&D,marketing, regulatory, andmanufacturing. The chairman isusually the division businessleader.
StructuredPlanning
Detailed project plan exists onlyto the next gate and is veryspecific to each project.
Detailed plan throughout all of thegates. Same general plan for allprojects; fairly detailed and knownfrom the start of every project.
DevelopmentTeam
Primarily consists of R&D orR&E.
Multifunctional. Typically made upof representatives of R&D,marketing, regulatory, andmanufacturing.
ProcessOwner
Responsible for making sure thatthe TechSG process is adhered to.
Responsible for making sure thatthe traditional SG process isadhered to.
focuses on the next stage of work rather than on the deliverables for all of tin gates,since the range of potential outcomes is vast. In addition, the gates lack thepredictability that occurs in the traditional SG system. Structured planning utilizestechnology development and performance tables combined with anchored scales sothat all of the stakeholders understand the technologies being worked on and theproject risks. The fifth element is the technology development team, which typicallyconsists of scientists and engineers doing the actual development work. The finalelement is the process owner, who shepherds the methodology, assists process users,and ensures the continued use and improvement of the process over time. Each ofthese elements is discussed in more detail in the sections to follow.
EXAMPLEFor an example, we will use a modified version of an actual technology developmentproject that was designed to enable XYZ Chemical Company to produce a molecule forsale that other companies were already producing, (Certain aspect of the project havebeen modified to maintain confidentiality.) Market analysis indicated that demand wouldincrease significantly in future year and that the other companies would have difficultymeeting the increased demand. Furthermore, applying their expertise in certainprocesses and new technological advances might enable lower-cost production thantraditional methods. Although other companies were already using three differentpossible route: (chemical reaction, thermal reaction, and a patented process), XYZChemical had never produced this molecule, with its unique properties, hazards, andrisk. It would therefore have to "discover" the specific details of how to make aproduction process work effectively and to investigate the new technologies that no onehad yet used successfully in this application. Therefore, it was appropriate to start aproject using the TechSG process before entering into a traditional SC process. Thisexample will be used throughout the chapter to better explain the characteristics of theTechSG process.
Project Charter
All projects begin the TechSG process with a charter that is typically developed bysenior executives, members of the TRC, and key members of the technologydevelopment team. This is similar to the product innovation charter discussed byCrawford and DiBenedetto (2000) but focuses on areas of technology improvement.The purpose of the charter is to provide a clear set of expectations for the project forboth management and the development team, the resources available to begin work,and the expected timing for the first review (TR0). Specifically, the charter should (1)define the scope and overall objective of the project and confirm its fit with theoverall business strategy, (2) describe the specific technologies to be investigated, (3)indicate the key technical, business, regulatory, and marketing assumptions and risksassociated with the technical and anticipated product development efforts, and (4)state the proposed resources that will be needed to develop the T0 plan (usually a leadscientist/ engineer, with some assistance from a planning/marketing/strategyrepresentative and possibly from technical services/application support). Thechartering process provides clarity around both the project and business goals beforethe work begins and saves considerable time and wasted effort by the project team.An outline of a project charter is in Figure 11-4.
The impetus to draft a charter can be driven by the business strategy, portfolioplan, or long-term technology plan, or it can be precipitated by some technicalbreakthrough or business development. The charter is usually written by the leadscientist or engineer based upon a request from technical management and presented(in person) at a meeting of the senior business leadership. The purpose is to getalignment on the technology to be investigated and its fit with the business needsprior to utilization of limited resources.
Although the focus of the charter is clearly on the technology development
Chartering TeamsTo be successful, you must define who writes the charter, whom it is delivered or presented to,and who decides to accept, modify, or reject the proposal. Whoever is chosen to make thedecision must have the authority to free up and reassign the resources (people, time, dollars,equipment, etc.) to make things happen. The goal is one sheet of paper (front and back). Thecharter must identify the key assumptions, expectations, deliverables, roles andresponsibilities, and timing, plus provide a framework, a process, and a forum for discussionand understanding.
Charter Outline1. Initial scope and objectives of work (very briefly comment on each)♦ Fit with the business strategy
What business strategy (competitive, growth, other) does this project support? What markets are addressed? How will the business win in the marketplace?
♦ Fit with the product/platform strategy What product/process platform is improved or created? What is the market impact (productivity, performance, cost position)? What is the impact on manufacturing? (manufacturability, contract, supply chain)
2. Primary areas of technology improvement♦ Brief description of the technologies to be investigated / pursued / developed
3. Key assumptions and risks♦ What are the key assumptions behind this development? » What are the key risks
associated with this project?4. Recommended process: normal (full) process, scaled-down process, other (specify)5. Proposed resources to do the first-stage work♦ Team leader (usually the lead scientist/engineer at 100 percent)♦ Other technical resources (often a process engineer at 10-25 percent)♦ Business resource (often a marketing manager at 5-10 percent)
6. Proposed timing for first stage review
FIGURE 1 f -4. Technology development charter outline.
work being proposed, the business reasons why such work should be undertaken willnot have been addressed anywhere else. Since the technology development projectcharter precedes any work on either the technology or a product, senior managementwill have seen no other documents describing the fit with the overall businessstrategy, business plans, technology plans, or product platform plans. The charter isspecifically intended to justify the technology development work. However, business,product, and market assumptions must be included to get the leadership to considerassigning the resources to begin this work.
Unlike in the traditional SG process, the output of a technology developmentproject is not a specific product or system. It is often a demonstration of an enablingtechnology or a proof of concept for a manufacturing process. Although the projectmay begin with a product (or more likely a product family
EXAMPLEIn the example, a product line manager at XYZ Chemical Company discussed the needfor the molecule with the research director, who then asked a senior researcher to drafta charter. That senior researcher presented the charter to the business committee afew weeks later and answered question with the limited information available at thetime. The team leader was given the resources to complete the stage T0 work in theTechSG process.The business committee is typically made up of the senior executives of the business,who determine if this is a valuable enough concept to charter a project and allocateresources. The business committee is not the same as the technology reviewcommittee. While the latter contains some members from the business committee, thetechnology review committee’s focus is on technology and its membership comes morefrom the technology community.
or platform) in mind, at the end of the technology development project the businessmay still have nothing that resembles the product that it eventually wants to take tomarket.
Technology Review Committee
Just as in the traditional SG process, in the TechSG process there is a decision-making body with clear roles and responsibilities for the TechSG process thatoversees development projects. The decision-making body in traditional SG systemstypically consists of the senior executives of the business unit: general manager orCEO, VP of marketing, VP of research and development, VP of finance, and VP ofoperations (McGrath 1996). The leader of the decision-making body is typically thegeneral manager or CEO. In many companies the members remain unchanged fromproject to project even though other senior executives may attend the meeting for onestage or one project.
In contrast, the TRC has considerably more variability. The authors' experiencesin both chemical and consumer products companies have been that some, if not all,of the members of the TRC are different for every technology development projectundertaken by the business. Since each project typically works on new or differenttechnologies, and since the review committee's primary function is technical innature, the experts needed to make decisions and recommendations will be differentfor each project. The makeup of the TRC may change many times as the projectevolves, with new technologies required and others no longer needed.
Ostensibly the variability of the TRC within and between projects could makecontinuity and consistency a challenge. In reality, the most important issues in theauthors' experience have been associated with the initial TechSG implementation,when the company is unsure of the process. After the first several projects the TRCand the TechSG process begin to work more efficiently as the company gainsexperience. Later projects, which may use a different TRC, typically do not have thesame start-up difficulties, since the company
has learned how to achieve quality technology plans and conduct effective Stage-Gate™ reviews. In addition, the chairperson as well as a few of the senior technologypeople remain on many of the technology review committees.
Since the focus of the TechSG process is on technology development, thechairperson of the TRC is often the technology leader for the business or businessunit, not the business leader, as in traditional SG systems. There is a representative ofthe business who usually comes from the marketing organization to ensure a link tothe downstream business and to provide input on customer needs and wants.
In the case of technology development, there are also additional members toprovide advice about the key technologies involved. These advisors may be seniorresearch fellows or advisors from inside and/or outside of the company. Theseadvisors, scientists who are acknowledged to be leaders in their field, subject thetechnology development plan to a scientific peer review. The presence of scientificpeers on the TRC elevates the scientific aspirations of the project and helps ensurethat the science involved meets the necessary standards of excellence and rigor. Manytechnology projects in companies are not accomplished with the correct scientificrigor as a result of inadequate resource allocation. Peer review forces the TRC andproject team to address the hard scientific issues, and this will typically result insounder scientific plans. Scientific peer review represents a fundamentalcharacteristic of the TechSG process that is essential for ensuring technical rigor.While scientific peers may exist within the company, the authors recommend thatcompanies Utilize external scientific peers at the gate reviews. External peers are bothmore likely to provide a fresh view of the project and typically are more forthright intheir evaluation of the technical risks associated with the project. The external peersinvited to participate typically are required to sign a confidentiality agreement, whichincludes a non-compete clause and assigns any invention that occurs as a result of thisengagement to the company. The scientific representation on the TRC will alsochange depending on the expertise required for the technology being developed.
In traditional SG the decision-making committee members are truly thegatekeepers; they focus on the proper completion of all deliverables and milestones,adherence to the process, and the cycle time commitments. In contrast, the TRC ismore of a review board. This committee does make specific decisions aboutallocation of resources and approval of plans for the next stage of work—the link tothe ultimate needs of the business and the customers. But its primary focus is advisingthe team about their technical approach, proposing alternatives, and suggesting otherfactors to consider and other experts to contact.
The logistics of the technology review process are schematized in Figure 11-5. Inorder to ensure timely decisions, the TRC must make a decision to either fund, notfund, or redirect the project at the end of the technology review. The actual stagereviews are often divided into two parts. The first part is the technology review, andthe second focuses on the business issues. During the first part, the scientific merit ofthe project is reviewed with a focus on the
FIGURE 11-5. Logistics for a typical technology review process.
overall quality of the science. Often the business managers do not participate in thisinitial session. The second part of the review focuses on business and resourceissues.
At the conclusion of the meeting the process owner, as indicated in Figure 11-5,has the responsibility for producing a memorandum that summarizes the meetingand the resulting action items within three days of the meeting (many companiesrequire completion of the memorandum within twenty-four hours).
Technology Review ProcessThe review process consists of a series of reviews (TR0 to TRN) where the details ofthe development plan and the technical approach are known only through the nextstage. Periodic reviews help the team to think about the entire project and its impactupon and value to the business. And, like other processes, preparing for the reviewand planning the next stage's work helps the project team to regroup, rethink, andrefocus on common goals. In contrast to traditional SG, neither the project team northe decision makers can say how many reviews there will be for a given projectexcept that the number of reviews will probably be different from project to project.
Technology development teams are asked to provide an overall plan and anestimate of how many gates there will be and how long the work will take,
EXAMPLEThe technology review committee at XYZ Chemical Company was chaired by thedirector of R&D for the business that would eventually use the molecule. Theremaining members of the TRC consisted of two senior research fellows from thecentral research laboratory, a senior researcher from within the business, and onescientific peer from another business who was recognized as an expert in thesynthesis path for the molecule being developed. The business perspective in theTRC would be the responsibility of the chairman, who would continue to updatethe divisions’ senior executives who Initially approved the project for the TechSGprocess and provided the funding for this effort. Other TRCs have morerepresentation from people on the business side— though nontechnical seniorexecutives sometimes lost patience when technology issues are criticallydiscussed.
Preparation Stage Review Meeting Follow-Up
TRC ReceiveDocuments Stage Review
MeetsStage ReviewMeeting Ends
Technology ReviewBusinessReview
1 ½ - 3 hours5 days 1-3 days
Minutes Distributedto TRC and Team
Issues andConcerns
but it is necessarily only an estimate since, as many researchers are quick to point out,technology discovery cannot be scheduled. The endpoint for most stages oftenrepresents a significant technical milestone, such as the demonstration of a criticalpiece of the technology or process. In the extreme example given earlier, it could bethat a single molecule of "water without hydrogen" was actually produced in thelaboratory, proving that it could be accomplished. This would not be enough to beginconstruction of the new production facility, but it would be promising enough to fundthe next block of possibly costly experiments.
Milestones, which might trigger a gate review, could be successful in achievingan intermediate goal. For example, if the current process was only capable ofproducing something with 55 percent purity, and the ultimate goal was 99 percent, thetechnology review committee might ask for a review when the team coulddemonstrate 75 percent purity or six months from the last review, whichever camefirst. For the former condition, they might want to discuss the next steps or techniquesto investigate; in the latter condition, they might want to decide if the project is worthfurther effort or investment.
The failure of a key assumption would also trigger a review to immediatelyrethink any future efforts. In the earlier example, everyone assumed that when theTechSG team got to a certain point in the experiments, the use of a certain chemicalprocess would yield at least 60 percent purity. But when they finally performed theexperiment, best efforts could yield only 20 percent purity. That would require arethinking of the project and agreement on a new path forward, if any, and wouldtherefore trigger a gate review.
Of course, a major change in any critical parameter would also trigger a review.Examples might include (but are not limited to) a change in anticipated market need,a change in estimated development cost or time, a shift in the market window ofopportunity, a new patent, or an unforeseen disclosure or action by a competitor.
On occasion a gate may be a specific actionable event, such as signing a letter ofintent or filing a patent application. Ideally the gate should occur at a significant andmeasurable milestone so that clear deliverables and kill points may be established. Akill point might be at the end of six months; if there is no progress toward resolving acritical issue, the project might be canceled and other high-risk projects begun.Alternatively, a kill point might occur when all conceivable routes to resolving acritical need (agreed to at a previous review) have been exhausted without any signsof potential future success. A third kill point might be a significant drop in theprobability of success as more details are learned from experiments or the realizationthat a critical safety or economic factor could not be overcome.
However, the measurable milestone may be too long a time for the TRC tocomfortably wait. Thus in more complex projects the endpoint may simply be anagreed-upon "time in grade" or the information necessary to commit to the next levelof effort. Most technology development teams plan their work for a block of time,usually two to six months, depending upon the complexity of the work, the nature ofthe industry (for example, pharmaceuticals development
and Internet businesses have different time scales), and the risk tolerance of theTRC.
Using options theory to assess the potential of the project at each of the gatesmay also help the TRC committee in assessing projects. Three recent articlesdiscuss applying "real options" assessment, with examples in the chemical andpharmaceutical industries (Boer 2000; Angelis 2000; McGrath and MacMillan2000). McGrath and MacMillan (2000) advocate a scoring methodology that maybe used to assess the option value of the project. This scoring model could beused at each gate in the TechSG process to determine if the option is increasing invalue, as a result of what is learned in the preceding stage, or decreasing in value,as might occur when the development costs and technology risks are beginning toexceed expectations.
In the traditional SG process, the activities and deliverables for all stages arecommon to all projects and are expected from the moment the project is begun. InTechSG, only the first stage (T0) and the last two stages (TN-1, and TN) haveenough predictability from project to project to be clearly defined in advance. Thefirst stage (T0) focuses on planning future work, clarifying goals and boundaryconditions, and aligning expectations. The initial gate (TR0) defines the overalltechnology development plan, including the overall technology strategy andapproach, program team structure, resources, a detailed plan (includingdeliverables) for proceeding to the next gate (TR1), and an overall risk analysis.
The next-to-last stage (TN-1,) is typically focused on the planning for thetechnology development work to achieve all of the agreed-upon feasibility pointsand to begin the transition to the NPD process. In stage TN-1, it is recommendedthat the future NPD team leader be added to the technology development team tobegin the transition. The final stage (TN) is focused on transferring the knowledgeabout the technology to the product development team. Technology transfer oftenbegins before the final gate (TRN) in order to get to the marketplace as early aspossible, although technology development may continue after the transition inorder to approach the ultimate performance goals.
Approval of the T0 plan represents the launch of the technology developmentprogram. Subsequent technology reviews (TR1 to TRN-1,) focus on theexperimental outcomes of the stage just completed and the revised plans for goingforward with agreed-to kill points. If and when a kill point is reached, the projectteam has a review with the TRC to decide if the project should be continueddespite the condition, redirected, redefined, changed in scope, or if all work onthe project should be stopped and resources reassigned.
The use of agreed-to kill points creates an environment of "fast failures." Theproblem with many high-risk projects are that they are allowed to linger in thehope that the technology barriers will be overcome. An environment of fastfailures allows the company to investigate more technologies. There is always theconcern that a technology may be killed too soon. While this certainly mayhappen, it is the authors' experience that most companies have too many projectsthat should have been stopped earlier. The second value of having
agreed-to kill points is that it creates a learning environment. It is important that theproject be stopped without "killing" the people involved in the project. Having theteam define the kill points helps change the paradigm for stopping technologyprojects from what may appear to be an arbitrary decision by management to asituation where the development team, along with advice and consent from the TRC,defines the characteristics.
Early involvement of key members from the traditional SG product developmentteam during the TechSG process helps ensure a smooth transition. Transitions areeven more seamless when the members of the NPD team have been involved inpreparing for the TR0 review and when the key technology members (who were partof the TechSG process) transition to the NPD team before the first traditional SG. Inaddition, the TRC should always contain executives from the division(s) thateventually will utilize the technology. In these cases, the leaders responsible forfuture product development will be aware that certain key technology discoverieshave yet to occur and that the NPD effort may represent wasted effort if theremaining technology hurdles cannot be surmounted.
Structured Planning
Once the business committee has approved the charter, the designated resources beginwork to prepare for the first stage review (TR0). The purpose of this first stage is toflesh out the plan for the project, to provide the next level of detail about the proposedfuture technology work, and to get agreement quickly on specific work to be done andthe resources required. The structured process provides a framework forcommunicating the project plan and executing it. In preparation for the TR0 meeting,a technology development plan is developed that will be updated for all subsequentreviews. The team leader needs to expand upon the information contained in thecharter to clarify the details of what technologies will be developed and why, andwhich approaches will be investigated. The details of the technology developmentplan need to be defined by the company so that they are congruent with its culture andexisting planning systems. However, there are a number of differences between astandard business plan and the technology development plan. Specifically, it includesmuch more about the technology and its development, but much less detail aboutbusiness plans, projections, and financial analysis. The technology development plandocument usually includes the sections shown in Table 11-2. While the focus of theTechSG process is on technology development, the business strategy, organization,marketing, financial, and regulatory assumptions and risks will also need to beaddressed, since the TR0 review is typically the first time a business plan is developedfor the project.
Unlike a traditional SG process, the TechSG process emphasis is not on a specificproduct and its financial contribution to the future of the business. There is a greatdeal less detail about the expected financial performance of any specific product inthe TechSG process. There is a lot more emphasis on the
TABLE 11-2.Outline of a Typical Technology Development PlanSection Description #of
Pages
Executive summaryII Introduction, including fit with strategy, market need, and why
this project will winIII Competitor analysis 2IV Project objectives, including high-level financial analysisV Technical approach(es) 2-12VI Summary of previous stage plan activities 1-5VII Technology performance and potential development tables 1-3VIII Future stage objectives and timing 1-2IX Updated stage planX Project organizationXI Conclusions, risk assessment, and decisions required 1-2
Total 13-33Appendix A Original project charterAppendix B Glossary of termsAppendix C Status of action items from previous stage review
technology needed for future business plans and the work required to demonstratethat the technology is feasible, rather than on the production of a prototype of aspecific product design. Although the plan for the next stage must be sufficient tojustify the dedication of the necessary resources for the next stage of work, just likein the traditional SG process, only a small portion of the deliverables is devoted tofinancial justification. There is much more emphasis on technology issues in theTechSG process.
A technology performance table like the one shown in Table 11-3 is prepared tohelp explain the specific performance capabilities to be developed and to helpmanage the expectations of everyone associated with the project. It is important tonote that this is not a final product specification. Rather, it is a guide to help managethe technology development effort. It has also been found to be the document that isthe most difficult to properly develop, the one that typically gets the most attention,and the one that provokes the most discussion.
The example shown in Table 11-3 identifies specific performance criterianeeded to enable the key product capabilities for a new product (in this case, a newoffice copier). Note that the table is not a complete set of design specifications, butsimply a definition of the technology feasibility points that must be met in order forthe project to proceed into product development. For example, it does not specifyhow to move the paper within the device, but rather the technologies required tocontrol the static and dry the ink in order to meet the market need for more copiesper minute. In order to avoid assumptions and
TABLE-11-3.
Exam
ple
of a
Tec
hnol
ogy
Perfo
rman
ce T
able
for
a N
ext-G
ener
atio
n O
ffice
Cop
ier
Cap
able
of
Rep
rodu
ctio
nSp
eeds
of 2
5 C
opie
s pe
r Min
ute
For t
his e
xam
ple,
ass
ume
that
cur
rent
cop
iers
can
onl
y m
ake
ten
copi
es p
er m
inut
e, U
ltim
atel
y, th
e go
al w
ould
be to
dev
elop
a c
opie
r ca
pabl
e of
pro
duci
ng tw
o hu
ndre
d co
pies
per
min
ute.
The
tabl
e sp
ecifi
es th
e ov
eral
lpe
rfor
man
ce
crite
ria,
te
chno
logy
fe
asib
ility
po
ints
, an
d co
nfid
ence
le
vel
for
each
of
th
e de
sire
dch
arac
teri
stic
s.
Mar
ket N
eed
Des
irabl
ePe
rform
ance
Tech
nolo
gy-
Perfo
rman
ce C
riter
ion
Tech
nolo
gyFe
asib
ility
Poin
tC
onfid
ence
Leve
lU
ltim
ate
Perfo
rman
ce C
riter
ion
Con
fiden
ceLe
vel
Hig
her p
rodu
ctiv
itySi
gnifi
cant
ly m
ore
copi
es p
er m
inut
eH
igh
evap
orat
ion
rate
for f
aste
r ink
dry
ing
Dry
ing
time
of 3
0m
icro
seco
nds
50%
Dry
ing
time
of 2
mic
rose
cond
s<3
0%
Sign
ifica
ntly
mor
eco
pies
per
min
ute
Infra
red-
sens
itive
ink
for f
aste
r dry
ing
Hig
h-sp
eed
pape
rtra
nspo
rt
Infra
red
abso
rben
cy b
y te
st#4
1X >
25%
25 fe
et p
er s
econ
d
<50%
70%
Infra
red
abso
rben
cy b
y te
st #
41X
>75%
195
feet
per
sec
ond
<30%
<30%
No
pape
r jam
sLe
ss s
tatic
elec
trici
ty to
redu
ce ja
mm
ing
<50
volts
at
50%
rela
tive
hum
idity
by
test
#21
50%
<2.1
vol
ts a
t 50%
rela
tive
hum
idity
by
test
#21
<30%
No
wai
ting
No
war
m-u
p tim
e1
seco
nd p
rehe
at50
%0,
1 s
econ
d pr
ehea
t<3
0%
Envi
ronm
enta
llyfri
endl
yN
o da
nger
ous
fum
esN
oen
viro
nmen
tally
rest
ricte
d so
lven
ts
0.0
ppm
hydr
ocar
bons
30%
0.0
ppm
hydr
ocar
bons
30%
Low
er o
pera
ting
cost
sLo
nger
-wea
ring
brus
hes
Mai
ntai
ns s
tiffn
ess
<20%
stif
fnes
s lo
ssaf
ter 1
yea
r90
%<
10%
Stif
fnes
s lo
ss a
fter 1
year
50%
:
TABLE 11-4.Anchored Scales for the Technology Confidence Levels Used in Table -3
Level OverallExpression
Influencing Variables Information Sources
Totally uncontrollable; manyunknown variables andunpredictable experimental results
Instinct and intuition, belief ofthe technology team, and fewif any experiments
30-50% Possible More uncontrollable thancontrollable; some unknownvariables and low predictability ofexperimental results
Experience in a fewanalogous areas, somepreliminary experiments
50-70% Probable Somewhat uncontrollable; fewunknowns and moderatepredictability of experimentalresults
Extensive experience,theoretical and experimentalfoundation combined withbroad internal input
70-90% HighlyProbable
Controllable; most variables areknown and understood,experimental results arepredictable
Preliminary database,independent confirmationwith broad multifunctionalinternal input
>90% Certainty Totally controllable; variables areknown and understood,experimental results have beenreproduced
Large database andfamiliarity, multipleindependent confirmationswith broad multifunctionalexternal input
misinterpretations, a set of anchored scales, as indicated in Table 11-4, is used tocommunicate the technology development team's confidence level around each of theperformance goals and feasibility points. The TechSG project should be managedthrough the gates so that the overall confidence level is increased through succeedinggates. The technology development table also contains the ultimate performancecriteria and confidence levels for each of the technical criteria that may be requiredfor future products.
In order to increase the confidence level at succeeding gates, resources and focusshould be directed at the performance criteria with the lowest confidence level. Inmost cases, as the performance of one of the parameters approaches the feasibilitypoint, the tendency is to try to complete the work on that parameter. The level ofunderstanding is typically higher and the difficulties fewer, and there is a desire for asense of achievement and a certain degree of closure. However, if the feasibility levelof some other key parameter is never achieved, there is no hope of success for theoverall project. Therefore it is important to restrict or even stop work on theparameters that are close to feasibility and to concentrate on raising confidencearound the parameter with the lowest confidence level. Resources during most stagesshould be focused on the technology feasibility characteristic with the lowestconfidence level, in contrast to spreading the resources across all the technologyinitiatives. During later stages, efforts may be required to increase the confidencelevel in multiple technologies. In
EXAMPLEFigure 11-6 show a typical stage plan for the XYZ Company as it might appear for the firstgate. The plan for the first stage was to better define the problem, focus the technologydevelopment work, extensively study the available literature, and to begin doing seriousexperimental work. A portion of the Technology Performance Table developed by the team isshow below. The team proposed three known ways to produce the molecule as part of thefirst stage. The goal in the second stage was expected to be to identify the least attractiveroute and to recommend at the TR, review that future work would concentrate on only two ofthe three original routes. After the TR, review, the plan would be to experiment on theremaining two routes with the intent of selecting the best remaining option. The last stagewould focus on the completion of the laboratory experimental programs, the completion ofthe early scale up work, and the technology transfer to the Product Development Team andthe traditional SG process.
At the beginning of the Technology Development Project, the team did not know which routewould eventually be chosen. Whether or not a new test facility would need to be built was notinitially known since the synthesis route was not identified. Because a large capital outlaymight be need for the test facility and no specific plans for the commercial process could bemade
Market Need DesirablePerformance
TechnologyPerformance
Criteria
Chemical process yieldMore ofMolecule X available
Mfg. process yieldThermal processYield
Environmentallyfriendly
No Mfg. waste stream No environmentally restrictedby-products
Safe process No chance ofexplosion
No combustibleby-products
some instances the confidence level may even decrease at the next gate as addi-tional knowledge is obtained.
Projects at TR0 are also required to evaluate both potential and actualdevelopment along various dimensions of the project, including team organi-zation, marketing, financial, regulatory, and technology issues, as indicated inthe potential/development plot shown in Figure 11-8. Anchored scales for eachof the factors are indicated in Table 11-5. These potential/development plotshelp evaluate project uncertainties beyond just the technology factors reviewedin the technology performance table. Project potential characterizes the abilityof the project to ultimately be successful in the marketplace. A project with avery high potential will typically be characterized by some or all of the follow-ing criteria: It can be protected by patents; it can be launched in a large, fast-growing market with few competitors; and it has few regulatory requirements
it was impossible to calculate a single NPV estimate. But, the high level plan that was presentedallowed the business leadership to understand its strategic value and what was needed in order toplan the specific work for each subsequent stage. The TechSG process facilitated the appropriatefocus and discussion at each point in the project and helped to manage the expectations of allparties.As shown in Figure 1 1-7, the last stage plan for the project shows that it required building a testfacility and modifying it to evaluate both of the last two possible routes before a decision could bemade between them. The product development team leader was identified early enough to beinvolved in the scale-up testing of the selected route even though the product development Stage-Gate™ process did not begin until the end of stage T4 because all of the feasibility points had notyet been demonstrated. Note that even though the Product Development project had begun workon the business plan and product definition, the technology project still had one more stage ofwork. That last stage was to complete certain planned experiments and to transition knowledgeabout the technology to the product development team.
Technology FeasibilityPoint
ConfidenceLevel
Ultimate PerformanceCriteria
ConfidenceLevel
75% conversion of rawmaterials in lab 50% 95% conversion of raw
materials at plant scale<30%
50% conversion in lab 70% 93% conversion of rawmaterials at plant scale
<50%
5 ppm molecule Y 50% 0.0 ppm molecule Y 30%
<10 ppmmolecule Z 50% <1 ppm molecule Z <30%
that will prevent its introduction. Project development characterizes theuncertainty along these same dimensions but evaluates the internalcorporate risk factors that may jeopardize the project. Although the majorfocus of the TechSG process is on technology development, there may beadditional activities needed to reduce market, regulatory, and financialuncertainty in parallel with the technology development effort before thetraditional SG process begins.
Subsequent plans (TR1 to TRN-1) focus on project planning andexecution to the next stage. The marketing, customer, and competitorportions of the business analysis are typically not redone unless there hasbeen a significant change that will affect the direction and course of theprogram. Both the technology performance table and the projecttechnology/development plot are presented at each gate with the expectationthat overall confidence levels will all be increasing.
FIGURE 11 -6. Example of initial stage plan for XYZ Company.
FIGURE 11 -7. Example of final stage plan for XYZ Company.
Stage T0
TR 0
Scouting research on molecules - Three potential routes Perform preliminary literature search and initial patent
analysis Program Definition
- Develop Overall Stage Plan - Develop feasibility points - Technology Performance Table - Potential / Development Plot Prepare for first Technology Review
Stage T1
Experiment on all three potential routes Decide which two are most promising
TR 1
Stage T2
Complete lab experiments Complete scale-up testing Transition to product Experiment on two best
routes
TR 2Stage T3
Complete experiments on best lab method Complete scale-up tests Transition to product development team
TR 3
Identify Product Development Team LeaderBegin Stage 0 of traditional SG
4/97 6/97 10/97 4/98 10/98
DetailedPlan Estimates Only
Stage T0
TR 0
Scouting research on three potential routes Perform preliminary literature search and initial patent
analysis Program Definition
- Develop Overall Stage Plan - Develop Feasibility Points - Technology Performance Table - Potential / Development Plot Prepare for first Technology Review
Stage T1
Experiment on all three potential routes Determine best potential routes on paper
- Analyze theoretical chemical reactions - Perform associated economic calculations Analyze process hazards and process design Continue literature search and patent
analysis Complete experimental work on route 1 Recommend routes 2 & 3 as most promising
TR 1
Stage T2
Conduct laboratory work on routes 2 & 3 Locate, design, and build process test facility Start-up test facility Conduct larger scale tests on route 3 Document experimental results
- Route 3 impractical at larger scale Recommend route 2 as best
TR 2
Stage T3
Complete lab experiments Complete scale-up testing Transition to productdevelopment team
TR 3
Stage T4
TR 4
Stage T5
TR 5
Continue laboratory experiments on route 2 Modify test facility for route 2 Conduct larger scale tests on route 2 Document experimental results Complete analysis of route 3 Continue analysis of route 2 Recommend work on route 2 only
Continue experimental program on route 2 Scale-up process testing on route 2 Begin preparation for product development
activities Document experimental results
Identify ProductDevelopment Team
Leader
4/97 7/97 1/98 8/98 1/99
History
5/99 10/99
Stage 0 ofTraditional SG™
FIGURE 11-9. Example of a potential/development plot.
TABLE 11-5.Anchored Scale Used to Determine the Project Potential/Development asShown in Figure 11-6
Team/Organization
Criteria Team Potential Organizational Development1-2 No people/facilities; must hire. No project champion exists.3-5 Acknowledged shortage in key areas; There is a project champion, with
business people acting us advisers6-8 Resources are available but in demand;
must prioritize. No team member iscommitted to project 100% of time.
Project has an executive championat the department head level.
>9 People/facilities are immediatelyavailable, Key team members arecommitted to project 100% of time
This project is a high priority to theCTO and company CEO, with atleast one acting as a champion forthe project.
Marketing
Criteria Market Potential Market Development1-2 No apparent need; market is in decline. Market is entirely new to the
company; extensive studies arerequired. A considerable challengefor the company
3-5 Need must be highlighted for customers;mature/embryonic market.
Market study is required, Achallenge but doable.
6-8 Clear relationship between product andneed; moderate growth.
Market study is required but isstraightforward.
>9 Product immediately responsive tocustomer needs in rapid growth market.
Market is well known to thecompany; no additional studies areneeded
Potential
Development 10
1
10
Technology
Regulatory
Marketing
Financial
Team/Organization
1
TABLE 11-5. (continued)Financial
Criteria Financial Potential Financial Development1-2 Declining product demand and large
competitive pressure. Lower-than-acceptable gross margin. Product beingdeveloped as a defensive response.
Unknown start-up costs. Moreinformation is needed in order toestimate unit and capital costrequirements.
3-5 Slow product demand and competitiveresponse expected, which may forcecompany to accept low gross margin.
Unit and capital costs are guesses.Extrapolation of costs fromproducts currently in productionmay not be reliable.
6-8 Modest product demand and competitivepressures. Acceptable gross margin.
Unit and capital costs may beestimated with reasonable degreeof confidence.
>9 High product demand, low competitivepressures. Higher-than-normal grossmargin.
Knowledge of unit costs andcapital costs are well known.Similar to other products inproduction.
TechnologyCriteria Technology Potential Technology Development1-2 Easily copied, Technology new to the company
(almost no skills).3-5 Protected but not different. Some R&D experience, but
probably insufficient.6-8 Solidly protected, with trade secrets,
patents.Selectively practiced in company.
>9 Solidly protected (upstream anddownstream) through a combination ofpatents, trade secrets, raw materialaccess, etc.
Widely practiced in company.
Regulatory
Criteria Regulatory Potential Regulatory Development1-2 No regulatory claims are needed to sell
this product.Controversy around the correctclinical and regulatory tests neededto support claims.
3-5 Regulatory claims provide no productimpact but are necessary to sell product.
Clinical/regulatory tests have beendesigned but have yet to be started.
6-8 Regulatory claims will provide a highimpact to sales but may be easily copiedby competitor.
Enough clinical/regulatory testshave been completed so thatdesired claims are expected to beachieved. However, there is nolegal approval.
>9 Regulatory claims will provide a highimpact to sales and a barrier tocompetition.
Clinical/ regulatory tests have beencompleted, with legal approvingclaim.
The technology development team is a small technical team empowered by the TRCto develop and evaluate a technology or group of technologies against a set ofperformance criteria. In the beginning the technology development team is chargedby the technology and/or the business leadership to develop a team charter. Thecharter is then presented to the senior business management for their advice andapproval. Once the charter is agreed to, the technology development team then beginsplanning their work for presentation at the first TR0 review.
A technology development team will typically consist of a team leader and asmall group of scientists and laboratory staff as an inner circle. Where corporate-levelresearch or external partners are significantly involved, individuals from those groupsare often also included on the inner circle of the team. In some cases, the technologydevelopment team may be composed of leaders of subteams representing groupsworking on various aspects of a project. The T0 team often also includes marketingand product development members who assist the team in formulating the businessrationale of the project. These members typically are not part of the inner circle instages T1 through TN-1, In most cases, there is also an outer circle of downstreamfunctional advisors who are assigned to provide a broader perspective to the innercircle members. They may be technical advisors, technical experts who will beconsulted on specific topics, and/or other subject-matter experts in areas such aslegal, finance, regulatory issues, manufacturing, and marketing. These outer circlemembers play more of a supportive role to the project, in contrast to the inner-circlemembers, who spend major portions of their time focused on work for their onespecific program.
Team leaders in the traditional SG process need to excel in project planning andmanagement and to focus on overall business issues. Team leaders in TechSG need amastery of the scientific method and the ability to manage uncertainty. As with anyteam in any process, by clearly identifying roles and responsibilities, this teamstructure facilitates effective communication, coordination, and issue resolution. Theteam leader is often the lead scientist for the technology development work. As such,he or she will design, plan, and direct experiments that will lead to understanding thecapabilities and limitations of the technology. The team leader schedules and leadspeer reviews when appropriate to support the project work. He or she also managesthe project work by providing overall project leadership—drafting overall projectobjectives and plans within the agreed-to budget and other constraints. The teamleader is also responsible for scheduling stage reviews with the TRC, ensuring high-quality experimental procedures, and the completion of the review.
EXAMPLEThe technology development team at XYZ Chemical Company consisted of a teamfeeder from central research who had excellent interpersonal skills and was skilled inthe synthesis techniques involved. Also on the team were two senior scientists. For theinitial T0 stage, representatives from marketing and technical service were alsoassigned to help the team develop the initial T0 plan. The marketing and technicalservice people were no longer active team participants after the TR0 review. The teamthen consisted of a team leader and two senior scientists through stage T1. Duringstage T2 two engineers were added to the team who had responsibility for developingrunning the test facility (see Figure 11-7 for more details). During stage T4 an additionalengineer was added as scale-up of the process continued. People from marketingR&D, and operations from the business side, who were also destined to be part of thetraditional SG process, joined the team as they prepared for their TR4, review.
Process Owner
Someone must "own" the TechSG process. That person must understand all of thedetails of the process and be ready, willing, and able to train and advise thetechnology development team and the TRC at any time. The process owner must beable to focus on the process, especially during development team meetings andtechnology reviews, without becoming overly involved in the content of the meetingor the details of the technology. This person's primary focus must remain on theprocess; otherwise he or she becomes another member of the development team,leaving no one to monitor the process itself. Senior management must activelychampion the process owner, since the process will not be followed without realtangible support.
The ideal process owner should have superb interpersonal skills and be wellnetworked throughout the company so that he or she knows where to find and/or sendpeople for information. This implies that the process owner should be someone withboth experience and credibility whose opinions and insights are useful and valuable.Ostensibly one might have different process owners for the traditional SG andTechSG processes, with the former having considerable knowledge about productdevelopment and the latter having considerable experience in technologydevelopment. However, the typical $200 million-$300 million division can usuallysupport only one full-time process owner. The skills of the process owner are dictatedby the type of projects he or she is most likely to facilitate. For example, a processowner in a research division would typically have more technology developmentexperience as compared to a process owner in a more traditional product developmentdivision. However, the process owner's most important skills are interpersonalabilities, which enable him or her to facilitate and motivate the product team, and helpthe team solve problems through his or her people network and experience.
The process owner also has the responsibility for continuous improvement. He orshe must be observant to identify what is working well and
EXAMPLEResponsibility for the TechSG process was assigned to the process owner for thetraditional SG process that already existed at XYZ Chemical Company, This was,believed to be an excellent choice, since the current process owner posited the keyrequirements for a successful TechSG process owner: excellent interpersonal skills, agood reputation among well-respected scientists in the laboratory and engineers in thedivision, a strong technical background, and excellent contacts and linkages throughoutthe corporation.
what is not. Where appropriate, the process owner needs to document procedures,techniques, and tools that might be of use to future teams. The process owner alsohelps teams that are struggling with the process and seeks to make the instructionsclearer or to propose changes to the process in order to be more responsive to theteams' needs. As in product development, the process owner also needs to be avisible, outspoken champion of the process, spreading the word and reinforcing itsvalue and benefits wherever possible. He or she must continuously update theprocess, provide recurrent training, and continue to facilitate the projects. In abenchmarking study Shapiro and Gilmore (1996) indicated that companies withannual sales between $300 million and $500 million were devoting ten person-yearsof effort every year to maintain their traditional SG process. Experience in traditionalSG processes has shown that without a process owner to keep the process alive, itwill quickly wither and die despite any benefits the business or individuals may haveseen in the past. Similar to Cooper's (1999) and Shapiro and Gilmore's (1996)experience in the traditional SG process, the authors have never seen the successfulimplementation, necessary rigor, and continuation of the TechSG process without aprocess owner.
IMPLEMENTATION METHODOLOGY
We have found that successful implementation follows three chronological steps: (1)understanding the need for change, (2) getting started, and (3) full implementation.The following sections will discuss these steps in more detail.
Understanding the Need for Change
Like any new business process, the work of implementing the TechSG processrequires a significant amount of change management. Successful implementationneeds to be preceded by both senior and functional management understanding thathigh-risk technology development projects are being poorly managed. Typicallythese high-risk technologies are often prematurely intro duced
into the traditional SG process. As a result, there is considerable delay and frustrationfor the product development team, as the actual performance characteristics of thetechnology are found to be different from the initial assumptions, resulting in the needto significantly redo many of the product development activities. Some companiesrealize that this problem is occurring and are proactive in implementing the TechSGprocess. Unfortunately, implementation often occurs following a crisis when a majorproject was significantly delayed or canceled because the development was poorlymanaged, the technology never met the desired characteristics, and/or the inherentrisks and assumptions concerning the technology were poorly understood andcommunicated. The TechSG process should be implemented whenever thetechnology is new to the company, even if it is not new to the world. The projectshould start in the TechSG process rather than a traditional SG process as long as thetechnology represents a significant risk or uncertainty due to the need for discovery orinvention by the company.
Getting Started
TechSG is best implemented in a division or company that already has a well-functioning traditional SG process in place. Based upon the authors' experience,implementation typically takes approximately six to twelve months, depending on thesize of the business, the type of projects, the business environment, and theorganizational readiness to change. Implementation usually begins with a one-timeprocess design team led by the process owner and consists of four to six people,including one marketing or business representative and one or more researchers. It isbeneficial to have the team leader for the first project also included as part of thedesign team. The design team has the responsibility of developing the overallplanning documents, procedures, and processes that the technology developmentteams will follow.
Implementation should begin with one or two projects that are typical of the kindof project undertaken by that business. They must be real projects that are meaningfuland significant to the business. They should not be projects that are created just to testthe process, and they should not be projects that have already been worked on for along period of time without any formal management process. The purpose of the firstproject(s) is to test the TechSG process design, evaluate the effectiveness of theprocess, identify improvements, build confidence in the process, and ensure that it fitswith the culture and environment of the organization.
The TechSG process will involve senior researchers who may be accustomed toworking alone or with minimal management oversight. They often take great pride intheir work and their ability to eventually make the breakthrough discovery that helpsthe business, but they may have little patience for meetings, reports, and customer-focused plans. They may get great satisfaction from solving a difficult technicalproblem and little from preparing for a review.
They may feel threatened or even insulted to have other people question their choiceof experiments, procedures, or approaches. On the other hand, many technologydevelopment team leaders and members often recognize the benefit of having animpartial review and getting suggestions for alternative routes and additionalcontacts.
The process owner and those responsible for implementing the process will needto help the early users see the value of using the process and immediately addressconcerns and problems. Many teams later admit that getting ready for reviews helpedthem organize their thoughts, facilitated valuable discussions, and identified potentialpitfalls and solutions much earlier than in the past without such a process. But untilsome success can be demonstrated, the process will need visible support from seniormanagement for its value and usefulness.
Full Implementation
Only after the first one or two projects have each had at least two stage reviews, andany minor adjustments to the process design have been made and tested, should theprocess be rolled out to the rest of the organization. Projects that are nearingcompletion without any formal process or with whatever older process may havebeen in place should be allowed to finish without forcing them to use the newprocess. Of course, the tools and techniques of the TechSG process can providevaluable upgrades to their work, and their use should be encouraged.
It is best if eventually all technology development projects use the TechSGprocess. Small projects might be allowed to informally use the process, while thosewith significant risk, cost, or need for resources would use the process in its entiretyand with the most rigor. Each business must decide how much flexibility it will allowbased upon its risk tolerance and the past behavior of the organization. Like any otherbusiness process, it has been demonstrated over and over that allowing too manyshortcuts too early in the implementation will keep the process from ever being usedto its full extent and its full benefit from ever being enjoyed by the business. Until thenew methodology becomes well known and well used, it is strongly recommendedthat shortcuts not be allowed.
The first few projects are often focused upon technology development for aspecific end product. Documents in the first few projects tend to be lengthy andverbose. In addition, the project teams initially struggle with the technologyperformance table and the potential/development plots. As the process becomes morewidely utilized, the business begins to see the benefits of reduced development time,better-focused projects, aligned expectations, and a smoother-running TechSGprocess. At that point, many businesses begin to focus on long-term technologyplanning. It is then that the TechSG process begins to be used for the development ofenabling technologies and core competencies needed for the future health of thebusiness, with less focus on a single end product.
CONCLUSIONS
The primary benefits of using the technology Stage-Gate™ (TechSG) process are toensure that critical, limited resources are allocated to the projects that are of highestimportance to the business and to reduce overall the time to market of newtechnologies and the products that they enable. The technology planning and reviewprocess highlights business, process, and investment issues very early in the projectand allows them to be more efficiently addressed. Technology goals are wellunderstood by all involved, are aligned to the product/platform strategy, and arerevalidated from stage to stage. The TechSG process creates a collaborativealignment between the technical and business communities.
In addition to significantly reducing overall cycle time for high-risk projects, thetools used in the process have brought additional benefits. The increased clarityaround both project and business goals—before work or even planning begins—thatresults from formally chartering project teams saves time and wasted effort by theproject team. The use of the technology performance table and thepotential/development plots as well as other parts of the structured methodologyenables and enhances communications, eliminates confusion and misunderstanding,and manages expectations of both the project team and the business leadership.
Periodic reviews, as in the traditional SG process, help the team to evaluate theentire project and its impact upon and value to the business. And, as in otherprocesses, preparing for the review and planning the next stage's work helps theproject team to regroup, rethink, and refocus on common goals. The advisors andexperts at the reviews provide a fresh view of the work and can provide possiblealternatives and additional contacts and references. The clarity of the informationdeveloped and the efficiency of the review process significantly increase theprobability that the company will allocate resources to higher-risk and potentiallymore profitable projects. By using the structured process, possibilities discovered inthe course of one project have often led to new, even more exciting projects.
Without such a process, many companies either shy away from doing any high-risk projects, begin product development before technology discovery has occurred,or poorly manage the scientific resources of the company. All of these situations areunsatisfactory. In the first case, the company does only incremental-type projects,which typically have a low profit margin. In the second case, the lack of knowledgecauses frequent project delays, frustration, and redesign when the characteristics ofthe required technology unfortunately do not become clear until the middle of productdevelopment. In the third case, the scientists often have inadequate resources, a lackof adequate scientific peer review, and a tendency to continue projects without anymeasurable kill points. Based upon the authors' experience, the TechSG processchanges the paradigm and creates an environment of "good science," whichencourages fast failures. With effort focused on demonstrating a basic understandingof the technology first, subsequent product development does not get stalled waitingto make the
technology perform as planned. In addition, the use of scientific peers helps elevatethe scientific stature of the project to further ensure that good, rigorous scientificapproaches are being followed. Furthermore, TechSG holds the scientists accountablefor demonstrating scientific goals while clearly recognizing that one cannot scheduletechnology discovery.
BIBLIOGRAPHY
Angelis, D. 2000. "Capturing the Option Value of R&D." Research Technology Management43, 4: 31-35.
Boer, P. F. 2000. "Valuation of Technology Using Real Options." Research TechnologyManagement 43, 4: 26-30.
Cooper, R. G. 1993. Winning at New Products, 2nd edition. Reading, MA: Addison-Wesley.
Cooper, R. G. 1999. "The Invisible Success Factors in Product Innovation." Journal ofProduct Innovation Management 16: 115—33.
Crawford, C., and A. DiBenedetto. 2000. New Products Management. Boston: Irwin/McGraw-Hill.
Eldred, E. W., and M. E. McGrath. 1997. "Commercializing New Technology—I."Research Technology Management, 40, 1: 41-47.
Eldred, E. W., and A. R. Shapiro. 1996. "Technology Management." In M. E. McGrath,ed., Setting the PACE in Product Development. Boston: Butterworth and Heinemann.
McGrath, M. E. 1996. "The Phase Review Process and Effective Decision Making." InM. E. McGrath, ed., Setting the PACE in Product Development. Boston: Butter-worth andHeinemann.
McGrath, M. E., and C. L. Akiyama. 1996. "PACE: An Integrated Process for Productand Cycle Time Excellence." In M. E. McGrath, ed., Setting the PACE in ProductDevelopment. Boston: Butterworth and Heinemann.
McGrath, R. G., and I. C. MacMillan. 2000. "Assessing Technology Projects UsingReal Options." Research Technology Management 43, 4: 36-49.
Shapiro, A., and D. P. Gilmore. 1996. "Implementing PACE: How to Make It Real andMake It Lasting" In M. E. McGrath, ed., Setting the PACE in Product Development.Boston: Butterworth and Heinemann.
