自从华为使用IPD流程在产品开发领域取得成功后，IPD就成为一种主流的优化产品开发及管理的方法，很多咨询公司也在实施这一方法，但鲜有人介绍IPD流程体系的理论依据即美国PRTM公司的PACE理论。
PACE是指（Product And Cycle-time Excellence，产品及周期优化法），是由PRTM公司创始人迈克尔·E·麦克哥拉斯（Michael E.McGrath）等团队成员在20世纪80年代末联合提出。旨在帮助企业提高产品开发的效率和质量，缩短产品上市的时间，增强产品的竞争力。PACE理论已经被许多世界知名的企业采用，例如苹果、微软、IBM、华为、方太等。
（1）产品开发是由决策流程来推动的，是一个可以管理、可以改善的流程，并非只有靠天才和运气。
（2）产品开发过程需加以定义和实施，以保证企业相关人员都能有共同的认识，知道如何协调和配合。
（3）产品开发是一个结构化流程，需纳入一个逻辑流程框架中，问题必须通过综合的方法来解决。
（4）产品开发及生命周期流程的优化需要按部就班，将下一阶段的某一要素过早地引入到现阶段毫无意义，就如同给一辆自行车加上涡轮增压器一样，无助于速度的提高，反而增加了重量。
（5）产品开发需在一个公共决策流程中予以管理，高层管理者的管理重心就是决策和均衡开发进程的关键点。
（6）产品开发项目小组与管理高层需建立新的组织模型（核心小组法），产品开发团队应有一位经授权的产品经理和若干跨职能的成员，管理高层转为产品审批/管理委员会。
（7）强调设计手段及自动化开发工具必须有起支持作用的基础设施才能发挥效力，产品开发流程的改进，不能依赖被誉为“银弹”的设计手段和自动化开发工具。
PACE认为产品开发要关注七个核心要素，包括阶段评审决策、建立跨职能的核心小组、采用结构化的开发流程、运用各种开发工具和技术，此外还要建立产品战略、进行技术管理、对多个产品及资源的投入进行管道管理。
产品战略是新产品开发的起点。通过产品战略，公司得以定义要开发产品的类型，如何区分自己与竞争对手的产品、如何能将新技术引入新产品以及开发新产品的优先顺序是什么。
选择开发的产品应与整个产品战略保持一致，但情况往往不是这样。产品战略常常没有被定义或表述清楚，甚至在公司内部也没有组织任何非正式的讨论。如果没有一个清楚的产品战略，开发人员在提议新产品及执行开发项目时就必须进行猜测，他们往往是通过反复试验才得知哪些合适，哪些不合适。
有时产品战略与开发项目相离太远，以致于前者是一纸厚望，对于实际选择的项目却没有任何作用。有一家公司，压倒一切的战略目标就是去开发多种新产品。当再无其它指导，或在缺乏产品思想的评估框架和优先顺序的设立框架的情况下，许多项目是根据开发人员个人或其经理们的提议同步增长启动的。尽管有的取得了技术上的成功，这些项目中的大多数永远不可能完成，或永远不能完成，或永远不能商品化。该公司的CEO告诉我们说，“如果我早知道他们都在做些什么，我会尽早制止他们。他们的大多数项目与我们的战略并不一致。”
产品战略制定和交流的常见不足之处如下：
公司将眼光过分集中于个体产品，而对产品平台的重视不够。
公司里没有人明确负责产品战略。
既然产品战略没有一个正式流程，它往往成为年度预算流程中的一项表面工作。
由于公司不能有效地评估其产品战略机遇，开发出了平庸的产品。
产品战略过时，原因是将眼光集中在当前而非将来顾客的需要和市场潮流上。
由于产品战略是内部驱动而非客户驱动，因而造成产品不具竞争力；竞争性分析肤浅，竞争定位不明确。
由于没有产品战略眼光指导项目开发工作人员，所以实际产品开发与初衷不符。
与盛行的信念相反，最佳产品战略并不是来自于令人眩目的革新念头，也不是从数百张具有图表的市场分析报告中得来。例如，数字设备公司只用三面记录定义未来VAX平台，就概述了计算机历史上最成功的产品战略之一。有效的产品战略来自于一个严格的产品计划定义流程，这些产品计划的制定依据是对市场交替变化、技术进步和竞争态势所带来的机遇的理解。
PACE是通过阶段评审过程来贯彻产品战略，在阶段评审过程中形成的决策会决定哪些产品机会会被保留，资源应该如何统筹分配。PACE产品战略流程将产品战略按照自顶向下，或从概括到具体，分成四个层面，如下图所示，每个层面具有明显不同的特征。
处于结构顶层的是产品战略愿景。产品战略始于一个清晰的、提供背景和方向的战略愿景，用于描述目标是什么，怎样达到这个目标，以及为什么能达到这个目标；它决定了处于其下一层的产品平台战略的性质、时机和竞争定位。
对于一个基于核心技术集合来开发产品系列的组织来说，产品平台战略是产品战略的基础。产品平台是一个通用于一系列产品的、若干个核心技术的集合，它定义了这 些系列产品的成本结构、能力及差异。产品平台的开发与具体产品的开发具有明显的差异，它的目标不是要开发一个新产品，而是为一个产品系列的开发创造一些核 心的技术要素。产品平台战略定义了一个产品平台应包含哪些核心技术要素以及如何开发它们。一个新产品平台完成的标志是其所包含的核心技术要素可以被成功地 应用于一系列产品中去。
因为每个公司都有自己的商业战略作法、机构建设、产业及竞争地位，所以具体的产品战略因公司的不同而有所不同，虽然如此，但产品战略仍可作为一个流程来管理。PACE产品战略要素对这一流程进行了定义。
产品线战略源自于产品平台战略，是产品平台战略不可分割的一个方面，但重要性相对要小一点，因为对一个不合适的产品平台战略，再好的产品线战略也无济于事。产品线战略是为具体某个产品线决定其开发和发布产品的正确顺序，并可以根据市场、竞争因素和资源状况不断调整。
所有的公司都有一个新产品决策流程，尽管他们可能并没有认识到这是一个有明确定义的流程。在决策流程薄弱的公司，因优柔寡断造成的延误很普遍。例如，如果某个实际流程是顺序性的，要求许多经理一一确认某产品设计概念的优劣，那么，起动延误就会发生。我们看到，许多良机的错失，只是因为产品先驱们不知道如何运作这种不正规的决策流程。
产品开发是由决策流程来推动的，这一流程在最初阶段决定要开发什么产品及如何分配产品开发资源，在开发过程中决定这一产品是否继续开发下去。通过这一流程，高层领导可以引导产品开发，实施产品战略，并授权项目小组开发新产品。
在PACE流程中，新产品决策是通过阶段评审过程实施的，这种阶段评审需要在开发过程中一些具体定义点上作出决策。一个产品开发项目必须在预定时间内达到明确定义的目标，才能获准进入下一阶段。
产品审批委员会（PAC）是指在一个部门或一个公司内负责主要新产品决策的高层领导小组。PAC有权在开发周期内的具体决策点通过给新产品拨付资金或修改新产品的途径来批准或拒绝新产品。PAC负责通过产品开发活动实施公司的战略，所以，具有资源分配权，以推进新产品的开发。
PACE通过阶段评审过程来作出决策分配资源。没有这样一个过程，高层领导就几乎不可能有效地引导新产品的开发。然而，只有一个评审过程（或有类似的一个过程，如把关过程或阶段开发过程）是不够的。定义不清、实施不当，或与开发过程中的其它必要要素不协调，都可能使评审过程效率低下。
阶段评审流程在产品开发中还扮演另一个重要角色。通过它，PAC可以直接明了地授权项目小组分阶段地开发产品。项目小组为产品制定详细的建议，提交产品开发计划，并申请下一开发阶段所需的资源。如果PAC批准工作小组的各项建议，它会赋予项目小组以权力、责任、以及实施小组计划的下一阶段所需要的资源。
阶段评审流程就像一个漏斗，在最初的概念阶段会有很多产品创意涌入，在开发过程中，经过每个阶段的决策筛选，最后只剩下很小一部分最可能取得市场成功的产品，它们会得到正确的投资。
在评审中，大多数公司有正规的项目小组，但多数并不成功。总的来说，这些项目小组的结构、角色和责任并没有明确的定义。结果，沟通、协调和决策便显得效率低下、纷繁混乱。
有这么一家很典型的公司，不计其数的经理们只在他们有空的时候或是有什么特别原因使会议变得最优先的时候，他们才参加产品开发小组的会议。由于这种方法产生的效果差，所以公司尝试用不同的方法来改变这种状况。他们建立了项目管理部门，负责监督进度和参与问题，以明确由谁去做什么以及事情做了没有。后来，每个部门都给每一个主要项目指定了自己部门的项目经理。但这些方法效果并不理想，只是增加了毫无价值的劳动，而这种劳动已经是太多了。许多公司建立了项目小组的组织形式，但大多数效果不佳。对不成功的案例，典型原因有：
如果项目小组和职能部门的责权不明确，将造成困惑。
项目小组没有实权去实现目标，所以效率低；有时候，他们只被赋予责任，却没有相应的权力和资源。
缺乏并行工程，一些职能和技能无法和谐地融入到项目小组的工作中去。
项目领导工作效率低，这源于几个因素：项目领导人没有经验；对项目领导人角色不明确；培训不足；项目领导人更换频繁；或者项目小组的组织有缺陷。
项目小组缺乏项目实施所需的人手和技能，因而无法实现目标；各种资源在项目小组间调来换去，对于资源该调拨给哪个项目小组没有明确的决断。
由于没有明确定义项目小组和职能部门之间的协作方法，两者之间便有冲突和困扰。
小组成员任务分配造成的困扰使整个小组效率低下；比如说，小组成员把自己看作职能部门的评估者或记录者，而非真正地帮助进行实时决策。
项目小组的构成是产品开发流程的一个关键要素。一个高效的项目小组能极大地增进沟通、协调和决策。在评审初期，我们就发现许多广为接受的项目小组模式效率低下，而低下的原因与上文所述颇为相似。我们开发了一个新的模式，这个模式既能发挥项目小组这种组织形式的最佳方面，又能克服上述缺陷。我们把它称之为项目小组构成中的核心小组模式（Core Team approach）。
核心小组是有权开发特定产品的一个小型跨部门项目小组。一个典型的核心小组有五到八个成员，有权利也有责任管理所有与开发该特定产品相关的任务。这些特定任务分配到核心小组的每个成员身上，每个成员都利用为该项目服务的人员完成这些任务。小组成员们对指定给他们的工作进行引导，与职能部门打交道，并作为核心小组的一员集体作出决策。PAC则在开发工作的每一阶段通过阶段评审过程赋予核心小组人员责任和权力。每个核心小组都有一个指导和引导小组工作的领导人。小组在执行每一开发阶段时遵守与PAC签订的“合同”，该合同规定出重大项目目标以及可变动的范围。
开发活动是开发新产品的实质性工作。在PACE中，结构化的开发流程明确了应做什么开发工作，相应的先后次序，其间的关联性，以及开发项目的标准术语。在评审流程中，我们发现，开发活动的结构中有三种一般性的缺陷：
（1）没有任何明确的产品开发结构的公司，
（2）有具体流程手册但并没得到遵守的公司，
（3）有结构化的流程但并不能改进或加快开发进度的公司。
对“没有任何明确的产品开发结构的公司”来说，公司必须在产品开发流程中不断地“重新发明车轮”，即重新定义产品开发流程。每一个项目小组都定义它要遵循的流程，结果，不同的项目小组即使在执行相同的或相似任务时，开发方式也迥然不同。这种模式延长了开发周期，整个公司的项目小组都易犯同样的错误。
对“有具体流程手册但并没得到遵守的公司”来说，流程被文档化了，但是并没有得到执行。典型的情况是，某个职员在程序手册里定义开发流程，然后把手册散发出去，天真地期待着每个人都会遵守它。结果当然是他们并不遵守，多数情况下，他们不遵守反而好上点。项目小组又各自将自己的那一套流程搬了出来。
对于“有结构化的流程但并不能改进或加快开发进度的公司”来说，开发流程已得到明确和遵守，可惜这个流程天生就效率低下。令人吃惊的是，许多公司在规范流程时，只是简单地将他们的现有做法写成文件，哪怕这个流程效果差。结果是把问题制度化了。
在评审开发流程时，普遍存在着下列缺陷：
无章可循的开发活动导致产品不断更改。
由于对必须完成什么样的开发活动及何时完成有误解，因而造成项目计划不周、及准备不足。
缺乏通用术语以及由此引起的理解问题，导致开发工作不理想。
产品开发定义过于详细，尤其是缺乏结构的定义，使得开发效率不高。
每一步都有多个签字盖章的官僚流程延缓了开发工作。
缺乏并行工程，因为它没有被设计到结构化开发流程里。
缺乏开发活动的周期时间指导，导致项目进度不准确。
由于没有将责任落实下来，导致未能不断地改进产品开发流程。
在PACE范围内，核心小组用结构化开发流程开发产品，这将确保一致性并避免各小组创立各自的流程。一个通用的结构化流程也可以使用通用的周期时间指南并为持续改进打下基础。
按照PACE的方法，一个结构化开发流程包括几个等级。在阶段评审流程所提供的框架中，一般有15到20个主要步骤来定义一个公司的产品开发流程，每一步又分成10到30项任务，规定每一步如何在公司里得以实施。这些任务又为每一步骤定义出标准周期时间，因此可以根据这些基本步骤制进度表、预估资源需求、制定计划及进行管理。
每一项任务还可进一步细分成各种各样的开发活动。根据任务的性质，每一步骤的开发活动数量从几个到三十或四十个不等。总的来说，各步骤与任务永远适用于各种项目，但开发活动则因项目不同而不同。
设计技术如QFD、DFA和DFM可以提升产品成功率和运作效率，但没有一种技术能解决所有问题。举例来说，一家高科技公司投入大量资源培训全体员工的QFD技术，但九个月后产品开发没有进展，项目小组解散。这是因为人们期望一种技术能填补整体综合方法的不足。
近年来，开发了许多自动设计工具，如CAE、面向对象的软件开发工具、产品数据管理系统和模拟工具。然而，没有单一工具能提供完整解决方案，而是需要一个结构化的流程作为先决条件。
在使用这些技术和工具时，许多公司犯了错误，如未使用正确的方法或工具，或者因缺乏整体产品开发流程而效率低下。常见问题包括：期望一种设计技术解决所有问题；新产品无法制造或不耐用；产品开发时间过长；自动化工具无法发挥预期效果。
PACE流程并未对新技术或工具做具体定义，而是强调在整体产品开发流程中适时运用合适的技术或工具。PACE概述了一系列技术设计和自动化开发工具，并说明它们如何适用于该流程。
技术管理在产品开发流程中起着重要作用，可以发现应用新技术的机会，提升公司的核心竞争力并使多种产品受益。然而，一些技术型公司未能有效管理潜在的技术，将技术开发作为次要项目而专注于产品开发。有些开发项目也因技术难题而陷入困境，因为公司意识不到缺乏基本的技术知识。产品开发依赖于技术，无论是内部开发、许可使用还是外部获取。为了及时利用可用技术，必须了解当前和未来的核心技术，因为技术开发和联盟需要时间。为此，项目小组不应被要求创造或获取必要的核心技术。技术开发是项目风险中最具不确定性和潜在延误的因素之一。缺乏技术管理的公司，研发部门致力于开发各种技术，但未充分利用现有技术基础。当核心技术到期时，公司无法替代，导致市场份额丧失。评审产品开发流程时，常见的技术管理缺陷包括技术意外导致延迟、缺乏对核心技术的投资、技术开发与产品开发混淆、技术风险控制不足导致项目失败。PACE中的技术管理要素定义了技术开发流程和技术向产品开发的转换，澄清了产品开发、技术开发和产品战略之间的关系。
最后，当公司消除了产品开发中以项目为基础的各个方面的不足之处后，它就明显变化地需要一个更好的管理模式，来管理所有产品开发项目。随着各个项目对有限资源的竞争趋于明朗化，管道管理就成为下一个首选对象。
下面几个问题可由管道管理来解决：
低效的资源调度系统常常导致资源调拨过度，从而延迟了开发项目。
作“救火”决策时未考虑互项目的优先顺序。
职能部门预算与项目资源分配不一致。
项目技能要求与部门资源不一致。
产品开发决策没有考虑到公司的增长、产品组合、或长/短期侧重点等目标。
这些问题存在于所有产品开发项目，也应在所有项目中得到很好的处理。PACE管道管理要素解决这些问题的方法是给项目优先次序的确定的跨项目资源管理提供一种框架，并且将职能部门能力和项目要求协调起来。
在组织结构方面，PACE采用了简单的两层结构：产品开发委员会和核心小组。
产品开发委员会一般由公司的CEO和三至四名副经理即部门经理组成，如由市场、生产、研发、财务等部门经理组成，这样的跨部门团队，便于快速协调和决策。其职责主要有：
a.撤销项目或重新设定产品开发的优先权；
b.保证开发中的产品符合公司的战略；
c.给产品开发分配研发资源。
可以看到，主要的决策都是跳出项目之外或是站在项目间的角度，如不符合公司战略，产品开发委员会可通过资源的重新分配来撤销项目或推迟项目的研发时间。具体涉及到项目研发操作层面时，决策和协调则由核心小组负责，产品开发委员会不予干涉。对决策范围的进一步细分，既明确了职权，又保证问题能得到迅速而有效地解决，这样就最大程度上避免了信息传递过程中的失真。核心小组直接对产品开发委员会负责并接受其对工作的评价。
在产品开发的每一阶段，产品开发委员会通过对资源的分配授权核心小组，并允许核心小组在执行过程中独立作出决策，避免了单纯地由各职能部门负责的诸多弊病。因为各职能部门有各自的部门负责人和分工，也有各自的目标，追求本部门的局部最优化，与产品开发的目标很难协调。
向PACE的演化共分为5个阶段，不同的阶段，产品开发周期和开发效率有明显的差别，阶段越高，开发结果的可预测性也越强。
PACE的演化可分为五个阶段，产品开发周期和效率随阶段提升而改善。在零阶段，开发项目无结构和明确定义，导致竞争力下降。第一阶段聚焦于职能流程成熟和优化，但项目周期长且管理效率低。第二阶段建立简单跨职能流程，但缺乏解决跨项目问题的成熟流程。第三阶段引入新流程，实现跨项目要素和战略一致性，提高竞争力。第四阶段平衡项目组合和与合作伙伴协作。逐步演化新产品开发流程需要时间和重点关注要素的实现。
PACE是一个用于产品开发流程的目标，它可以被看作是一幅蓝图或参考模式。它提供了产品开发的综合流程，将子流程、组织结构、开发活动、技术和工具有机地结合在一个整体框架中。PACE的系统结构由七个相互关联的因素组成，既适用于项目管理，也适用于跨项目管理。其中四个项目管理要素（阶段评审流程、核心小组、结构化开发流程、开发工具和技术）构成了PACE的基础。这些要素对于每个产品开发项目都是必要的，掌握它们可以使公司缩短产品上市时间、准确安排项目进度、提高研发效率，并减少对未进入市场的产品的投资。尽管这七个要素可以单独描述，但只有在整个流程框架内才能发挥有效作用。每个要素的成功都依赖于整个产品开发流程中的其他要素。例如，如果核心小组没有真正的授权，他们的责任和权力级别就会变得模糊不清。
联系客服
