项目组织是产品开发中的一个最重要因素，但是很少公司能够在这方面采取一套持续而又有效的方法。一些公司甚至连组织产品开发项目的方法也未能明确规定；它们让每个开发小组自己去想怎么组织。没有明确界定的项目组织，就好比挑选了一些人组成一个足球队，然后就直接叫他们上场踢球。这些队员对应该踢哪一个位置一无所知，更不知道如何进行团队合作。他们甚至不知道谁该什么时候上场以及每个队员该做些什么。一个足球队如果这样子一团混乱，要想赢球难过登天。

还有一些公司虽然能够描述他们的组织方法，却无法调动其小组有效地工作。这通常是因为组织内有冲突，或者组织成员在如何进行小组工作的问题上理解不一致。一些公司不断尝试各种各样的组织方法，希望终有一天找到能行得通的那条路。每当碰到大难题，他们就改变一套项目组织方法，希望借此推进产品开发。

一个配合默契、迅速将产品推向市场的开发小组，与一帮徒然将时间浪费在每周例会上的各职能部门代表的聚合，两者之间的区别在哪里呢？前者在沟通、协调以及决策方面卓有成效。这是一个成功的小组所必须具备的最基本的素质。

为了获得这些素质，PRTM开发了一套用于达成项目组织的核心小组法。这套方法通过有效的沟通、协调以及决策，达到尽快将产品推向市场的目的。核心小组法同时也提供了一个给小组真正授权的基础，以及产品开发过程中并行工程工作的实施基础。

成功项目小组组织的特征
成功项目小组组织的秘诀在于组织小组进行有效的沟通、协调以及制定决策。表现出色的小组成员彼此间能够十分有效、又非常自如地进行沟通。让小组成员习惯于互相通报各自工作的进度、问题和主要决策，这是第一个特征。在多数情况下，沟通是自然的一种事情，而且本该如此：沟通能够使事务迅速得以执行、将错误迅速消除，而在产品开发中，发生错误是最常见不过的事。
成功的项目小组习惯于协调无数个须同时进行的活动，这是第二个特征。每个小组成员都知道哪些工作必须与小组成员一起仔细处理、哪些工作可以独立完成。他们知道谁对各种各样的工作都负有责任、什么时候需要小组成员间的互相帮助。优秀的小组能够有效地进行这种协调，而不需要通过各种文山会海或其它不能带来增值的行政手段来促成这一点。
高效的决策是优秀的产品开发小组的第三个特征。小组成员对必须作哪些决定、什么时候作决定都有共识。小组成员心里明白，哪些决策是在他们个人的控制范围内的、哪些决策在策略上或技术上有更高的侧重点，因而需要其他队友的参与。他们主动决策，而不愿任由问题发生。

沟通
由于产品开发中存在大量的不确定因素和变动，因此良好的沟通就显得尤其重要。同在一个项目组的人有必要与其他小组成员沟通，将工作结果告诉他们，并指出会影响同组其他人工作的问题。如果产生了问题，应该告知那些能够帮忙解决的人。至于技术细节以及规格，则应该告知那些使用这些资料的人。很多问题，都应该及时提出、及时作答。

要想沟通富有成效，就必须同时进行纵向和横向的沟通。纵向沟通不考虑等级或官职等因素；横向沟通必须跨越部门界限。传统的沟通方式是通过发布一串指令来进行的，这样不但速度很慢，而且容易发生错误。很显然，项目涉及的人越多，有效沟通所需时间也就越多。如果在沟通中要求一个人向另一个人传达相同信息，那就容易造成延误。各项目小组之间需要进行无缝的沟通，而且在项目进展的关键时刻，应该能够与行政管理层进行沟通。

实际或真实的信息通过组织的层层过滤以后就会大量丢失。例如，经理向主管汇报工作时有意隐瞒情况，想以此来赢回一些时间把项目重新搞上去，而主管在向副总裁们汇报情况前，也同样经过了筛选，如此这般。当这一条信息传到高级经理耳朵里时，已经过滤得很纯净，以至于他们可能误以为项目进展一切顺利。最终，当他们看到项目“出人意料”地与原计划有出入，便十分惊讶。假设每个人都有效地进行沟通，那么高级经理也许可以采取措施帮助小组，以免局面出现失控。
要横向跨越部门界限、纵向越过等级界限、保证迅速有效地沟通的另外一个原因是为了避免理解有误。有一种小孩子玩的游戏，是将一条信息悄悄地告诉一个人，然后让他悄声往下传到最后一个人耳中时，愿意全变了。这种事情在很多公司并不鲜见。
最后一点要说明的是，很多产品缺陷或项目延误都是因为缺乏沟通之故。需要沟通的人没有沟通。举个例子说，在一个项目中，项目经理制定一个计划，打算花一周时间加工产品。采购人员知道加工某个部分需要十二周时间，但计划书上没有估计加工周期。人人都自以为沟通了，但实际上并没有。结果产品延迟了四个月推出，由于违约，客户跑了。

当产品构想演变成一系列潜在特征和功能之时，就需要开始进行有效的沟通了。在这段时间里，市场推广部和产品开发之间需要频繁、几乎是连续不断的沟通。只有在产品开发小组内部进行有效的沟通，才能够对产品功能、特征划分、竞争对手意向分析、公司实力、市场窗口预测、市场需求等等问题作出平衡的决策。从市场推广部门、设计工程部到制造车间，如果是采取单线传递信息的沟通方式，很少能够行得通的。产品开发小组的组织结构可能使得沟通更加容易、有效，也可能使沟通变得更加困难。
有些公司为了弥补沟通上的不足，而采用大量的书面文件。开发小组很可能会因此陷入大量不增值的工作之中而无法脱身，诸如准备状态更新报告、准备管理宣讲报告及协调正式批准的签字把关等。例如，有一个制造工控机的公司，开发小组里有技术骨干，介这些人员却将30％的时间花在与完成项目无关的事务上。他们每个星期要发两份行政简报，每个星期必须向其它部门做三次有关项目的汇报，并就他们的伟大设想进行技术演示。

这么多时间花在与完成项目开发无关的事务。我们估计，如果他们减少这些不必要的活动，可以将计划进程缩短六个月。他们不相信，认为这不可能。我们就鼓动他们每星期只用一天时间，把精力完全集中在产品开发的工作上，不作报告、不开会、也不参加任何管理动态课程，只准许参加设计和开发活动。这个小小的改变引起了显著的变化，结果该小组主动决定进一步减少与项目开发无关的活动。最后，该产品投放市场所需时间之短创下了记录，而质量水准比该公司历史上任何其他项目开发的产品都高。
如果一个既定项目的参与人数增加，那么可能存在的沟通渠道就会以几何级数增长。比方说一个项目的开发成员只有四个人，那么在这四位成员A、B、C、和D之间就会有以下十二种沟通渠道：

A®B B®A C®A D®A

A®C B®C C®B D®B

A®D B®D C®D D®C

然而，产品开发通常牵涉到更多人。说明了当更多人参与项目开发时，沟通渠道迅速增长（Nx（N－1））的情况。如果六十个人参与了产品设计，那么每个问题或每条信息就可能有三千五百多种沟通方式；当每个月要进行沟通的问题或信息多达数百个时，就显得相当杂乱无章了。

工作的协调

开发新产品要求开发人员完成数以千计甚至数以万计的开发活动；其中很多活动有联系。要有效地做好这无数件工作，就要相互协调好。而随着产品的复杂化或市场渠道的增加，要求为管理好项目而进行协调的工作量也随之增加。

如果协调不力，就可能导致项目延迟或效率降低。有一个跨国仪器公司就曾经遇到过这个问题。由于他们的产品开发组织错综复杂，用于将产品推向市场的时间大部分被用于资源协调工作上，如决定哪些技术专家应该在工作中的关键时刻调过来帮助开发小组或去顶设计人员的缺，因为他们早就被调到别的项目救火去了。
协调不力还可能造成工作次序混乱。工程师在市场部确定产品的要求之前就着手产品的开发工作，这样的事会一而再，再而三地出现。例如，一个公司为一台新电脑设计、制作了六种印刷电路板的工作样品，结果发现，当产品要求最终确定时，这些电路板都必须做很大改变。白白浪费了八人年的技术骨干力量。
一些公司试图通过使用综合计划体系来克服协调问题，例如使用详细的项目评估及审核技术（简称PERT）图表。一般来说，这样做需要大笔管理费用，而且不能有效地对工作进行协调。曾经有一个公司想要使用PERT图表来协调一个复杂的项目，他们的PERT表大得将一面30英尺高的墙都覆盖了。有两名全职工作人员不间断地对该表内容进行更新，但谁也不知道谁哪一天应该干什么。
并行工程需要将各部门之间的有效协调贯穿项目始终，在项目早期更是如此。有许多公司想要实施并行工程法，但却无法实现，因为协调工作是一只拦路虎。他们的项目小组组织并没有提供产品开发所需的协调。

成功的项目小组能够有效地进行协调，而白费精力的事情却很少。他们清楚什么应该做、谁该做什么。只需召开短短的小组会议，他们就可以协调下一步的工作。他们懂得利用小组的组织结构，而不是把调度体系作为主要的协调过程。

决策
进行一种新产品的开发，需要作出无数次的决策。有些决策事关大局，更多的只是小决定，但所有决策都必须有效地制定出来。是否能够及时作出正确的决策，是决定一个项目小组成功与否的另外一个因素。

有效的项目小组能够作出更好的决策。不同的观点、技能和背景在他们作决策时起到了一种增效的作用。在研讨会上，我们做了一个练习，对此进行了说明，这个练习叫做“迷失在海上”。在这个练习中，假设参加练习的人在茫茫大海上漂流，要求每个人按优先顺序排列出他将随身携带的十五种物品。然后分小组再进行这个练习，按美国海岸警卫队排列标准给每套答案打分。结果很明显，集体得分高于个得分，这说明凭借团队的力量就能制定出更好的决策。

产品开发的决策还必须及时制定。如果一个决策数个星期至数个月都迟迟制定不出来，就可能导致项目悬而不决，延长产品推向市场的时间。这是导致产品开发延迟的最主要的一个原因。举个例子，有一个公司无法确定产品应该使用哪一种微型处理器。这确实是一个不好决定的问题，但是，这个问题拖了差不多十八个月，一直没有解决。六个月后，工程师在还没有制定决策的情况下就开始产品设计。最后，当决策出来时，整个设计工作几乎必须重来一遍，结果造成产品延迟一年推向市场。如果上头没有指示，设计小组还是会无事找事干，即使是不对路也会照样做下去。

对项目小组授权的观点很普遍。这样，在需要时，小组自己有权作决定。然而不幸的是，这种授权往往因为项目小组的权责不明而无法发挥作用。

产品开发的职能组织
虽然在产品开发中，跨部门的项目组织取得了成功，但很多公司依然根据职能来组织产品开发。使用这种方法，每个职能部门依次对产品开发起作用，与接力赛跑差不多。开发周期是从市场部提出产品要求开始的。然后，这些要求转给工程部，制作出产品规格，并开始产品设计。生产部就根据设计制造出样品和测试产品；销售部把生产出来的产品派发到各个分销渠道。最后，客户服务部开始发挥作用，支持初期销售工作并处理客户投诉。
如果一个项目的先后工作顺序明确、重复很少，那么使用职能部门的方法可能很好，但一般来说，这种方法并不是十分适用于产品开发。我们发现，使用职能部门的方法容易造成“各人自扫门前雪‘的态度，也就是说，每个部门一完成他们那一摊子任务后，项目的其它事就撒手不管了。很多时候，这个问题并未能被人提示出来，因为项目组织忙得根本就没时间回头将整个项目的实际表现与最初的目标进行比较。
使用职能产品开发的方法还有一个弊端，那就是这种方法使得签字审批手续繁杂，没完没了地转来转去，造成机构臃肿不堪。在过去出现的问题当中，这种耗时的体制尤其多见。一旦问题得以解决，就有人做出决定，以后如果要避免类似问题，应采用正式签字的方式，各个职能部门对产品进行审视、批准后方可进入下一步工作。这样通过保留审查纪录，出现问题时就可查到责任人是谁。虽然过一阵后，问题不再出现了，但是关卡却越设越多，开发时间也变得更长了。
例如，有一家生产电子设备的公司在样品材料上比预算多花了$860。管理层于是制定了一个工作程序，规定生产一种新产品要购买样品材料时，需要四名副总裁签字批准。结果大量的时间花在找人签字上，这样大大增加了产品开发成本，也无谓地延长把产品推向市场的时间。

职能部门的体系纵向层次繁多，往往缺乏必要的横向网络，不利于进行有效的沟通、协调和作出迅速的决策，而在产品开发上要有所作为，必须要有有效的沟通、协调和迅速的决策。复杂的结构层次可能会导致部门沟通渠道不畅，从而拖延制定新产品的决策。例如，如果生产部门非得等到产品设计正式得到批准之后去订购样品材料，那么在连续的各个步骤间拖延就蔓延开了。一些最初有控制点的体系往往演变成官僚主义的迷宫，人们在里面打转转，而不是花时间将其改正过来。对于一些产品开发周期长的公司，这些是典型的症状。

在职能组织体系中，要开发新产品，信息在组织中必须横向流向多个职能部门，还要纵向穿过多个组织阶层。沟通渠道迅速增加，每个渠道都会延长整个开发周期的时间。
当职能组织法运作好时，进度却很慢；但如果运作得不好，很少有产品能及时推出而且具有竞争力。当产生矛盾时，皮球就踢到下一级，让他们去解决。最终，有关产品的决策是由嗓门最大或权利最大的人来作出，而不是由最了解设计和顾客的人员来制定。

职能组织法最主要的缺陷在于其结构本身。在任何一个职能部门中，工作人员的工作表现和奖惩完全是按该部门的工作目标评定的。因此，参与产品开发的人员一般会努力争取在该职能部门中表现出色。很多情况下，那些在具体职能部门中表现最好的人员，对产品或对公司整体而言却并非很好。职能部门的工作目标与公司的工作目标不能总是保持一致，而且也经常跟其它职能部门的工作目标不一致。
有一家微电脑公司的项目小组是按照职能组建的，设有市场推广和销售部、研究开发部、技术工程部、生产部和客户服务部。每个部门都负责产品开发过程中不同阶段的工作。开发工作通常从市场推广部开始，由市场推广部提出它认为新产品应该有的一系列需求。市场推广部将市场需求文件（MRD）交给技术工程部。技术工程部随后根据市场需求文件决定该做什么、不该做什么。产品功能规格（PFS）技术工程部提出设计要求。不幸的是，市场需求文件（MRD）和产品功能规格（PRS）往往不一致。

只有到制造试制品试时，生产部门才会加入到项目中来。由于工程师负责订购所有部件并制造他们自己的样品，所以生产部的工作必须从零开始。他们要花很多时间去搞清设计要求、找出标准和合适的部件。最后，在第一批货即将发运给客户时，客户服务部才猛然发现原来有这么一个项目。当然，从战略的角度来说，所有零部件都应合理散布在全国各地。这使得生产部更加手忙脚乱，而工程部就要把各种技术工程上的许多要更改的地方尽快地定下来。

由于采用了职能组织法，该公司开发一个新产品，要比它的竞争对手花多一倍的时间。后来，该公司被卖给一家外国公司。这家外国公司想做一些改进，却被其根深蒂固的“职能观念”弄得一筹莫展。

不同职能部门里的个人通常熟知自己本行当的事，但未必知道对于其它职能部门而言什么是重要的。一个职能部门的专家认为有用且有趣的事情，另一个职能部门的专家却常常并不以为然。个人所做的每一个工作步骤，都深深打上了个人专业兴趣的烙印。这种观念偏差所形成的产品，经常与成功背道而驰。
在一家电脑制造公司里，市场部指出一种新电脑应该满足从工业到军事的各领域广泛的需求。工程技术部在规格里又附加注明这种电脑应拥有最先进的处理器技术，而这种技术在一年后才面世。尽管这些过分的要求并不是非要不可的，但根据设计意见，产品还是包括了这些要求。一年后，该公司意识到开发这样的产品既费时又费钱。于是重新进行产品定位，着眼于现实的需要。

职能型构架蕴育障碍（在各自的专业领域，人们彼此孤立）
产品开发采取职能组织结构的做法，往往在产品种类不多又关系密切的小公司运作良好。在这些公司，每个人都互相认识，而且一般情况下他们在一起工作都很有经验。初建的公司往往使用这种方法，并且成为这种方法运作的典范。然而，当一个小公司只开发一个新产品时，整个公司就是一个产品开发小组。
有些大公司为了有效地沟通、协调和决策就试图效仿小公司的组织结构。他们成立了规模较小的自治事业部，自负盈亏而且在财务上有自主权。这种组织结构在该事业部内部的优势确实有所体现，但对外交流就越发显得困难了。结果，公司白白失去了对公共资源的利用，而利用这些资源正是大公司的优势所在。核心小组的方法是力求达到一种更好的平衡。

核心小组法
当我们第一次与客户一起改进产品开发过程时，我们推出核心小组法作为组织产品开发小组的备选方案。在多次运用核心小组概念并取得意想不到的成绩后，我们意识到核心小组是一种组织、指导和管理项目小组的良策。现在，我们相信它是针对产品开发的最佳项目组织形式。

虽然核心小组通常由5～8个具有不同技术的成员及一个核心小组组长组成，它并不采用传统的分级管理方法。所有产品开发责任都分配到各个小组成员身上，每个小组成员的职责通常与其技术能力相关。我们认识到有必要消除垂直等级制度、严格的部门分工及按级别付酬等政策。我们认为核心小组的结构应用一个不间断的圆形结构图来表示。如图所示，所有的小组成员地位相同。也没有任何一个部门的地位比其它部门高。
此外，这个圆形结构图还表明每个小组成员都面临相同的挑战：不惜一切代价尽快地把产品送到客户手里。这就是说小组成员要完成可能超出其严格意义上的部门范围的任务或是低于他们身份的工作。

小组成员不光要为本部门着想，但更多地是为项目的最后成功而努力工作。他们通常不把自己限制在通常工作岗位定义的框架内；他们工作弹性大，以小组身份去做该做的事。核心小组成员直接而独立地覆行职责，监督分派给自己的人员，协调各部门的专家。

核心小组法与其它项目组织形式截然不同，因为核心小组直接对项目的成功负责。在职能组织形式中，职责是强加的；而在核心小组结构中，责任是自愿接受的。在等级结构中，通常由更高级别的领导作出或批准详细的决策，但在核心小组结构中，通常由最熟悉问题的人尽可能在现场作出决策。为帮助小组成员作出最佳决策，核心小组可以从各部门专家那里获取建议、咨询及指导。
一个核心小组包括四个要素：核心小组组长、核心小组、全员项目小组及核心小组协调人。

核心小组组长

核心小组组长是核心小组的核心人物，他的职责是保证产品符合面市时间、质量、开发费用及产品成本等项要求。核心小组组长扮演的角色与矩阵组织的项目经理有细微但又是重要的差别。他是小组队长而不是一个兼职老板。重点在于领导而不是独裁。核心小组组长是枢纽前卫（套用一句美国橄榄球的术语），带领并激励核心小组去完成产品设计，实现项目目标。
此外，核心小组组长还负责管理项目预算、资源及日程安排。同时，负责解决核心小组成员之间的矛盾、小组成员与职能部门之间的矛盾。出现问题时，核心小组组长帮助找出解决方案。

一个优秀的核心小组组长不会对其小组存有不合理的要求。相反，最好的核心小组组长应具备出色的处理人际关系的技巧。曾经有一家电讯公司让一个颇有经验的产品经理担任核心小组组长组织开发一个重要的新产品，但此人未能完全理解职责，他经常拍桌子瞪眼睛，叫嚷着说他们误了工时而且开支超过预算，结果与核心小组中的工程人员及生产人员产生隔阂。这种做法对激励核心小组把项目带上正轨起到了反面作用。

核心小组成员

核心小组成员在核心小组组长的指导下进行各自的工作。核心小组将根据开发的产品、产品的复杂性及市场来确定小组的具体组成形式。如果是小型简单的开发项目，一个核心小组可能只有4个或5个成员。而大而复杂的开发项目，就需要一个大一点的核心小组来管理众多的成员。例如，由一个10人组成的核心小组管理一个有1，800人的大项目。无论是何种情况，一个核心小组一般都包括来自工程部门、生产部门、市场部门及客户服务部门的成员。

核心小组成员可以为不同的特殊部门协调项目工作。他们把各职能部门的需求传递到开发工作中，并把项目要求反馈到职能部门这可以保证产品具有可生产性、耐用性并能满足客户的需求。

核心小组成员还管理其负责的项目活动的资源。例如，一个在数据通讯开发小组中的电子工程核心项目的成员负责管理工作在处理器、通讯、接口板以及底板和电源系统等方面的工程师。这些工程师是全员项目小组的成员。全员项目小组成员负责过程中某些特定点的产品开发工作。全员项目小组成员加入项目并完成他们的工作后，就退出这个项目。全员项目小组成员的工作表现由核心小组的相应负责人给予评定。

有一个美国消费电子公司在核心小组中不再设有质量控制人员。因为该公司在提高质量方面已经非常成功，质量已经成为每个人工作中不可分割的一部分。质量不再需要它的质控代表，因为质量意识已经在小组中扎下了根。

全员项目小组

核心小组的下一结构层是全员项目小组。全员项目小组成员来自各个不同部门，他们参与项目中的一部分工作，该项目由核心小组内一个专门成员负责。全员项目小组成员可以是直接分配给该项目的人员，也可以是参与新产品支援的职能经理。

直接委派的小组成员主要是完成不同项目任务的产品开发工程师、技术人员及专家。例如，可派10位软件工程师去开发软件。全员项目小组成员可以是长期委派的或是临时委派的，也可以是全职的或兼职的。他们的工作由某一指定的核心小组成员进行协调。

职能经理及其他专家可作为全员项目小组的一部分参与协调某些特殊工作。例如，元器件工程师及采购工程师可参加一个新供应商的资格认证工作。
核心小组成员负责的全员项目小组里经常有些成员不是固定在其所属职能部门的。例如，一个硬件核心小组成员负责的全员项目小组里的成员常常来自CAD（电脑辅助设计）、调配、元器件工程、采购、生产工程等职能部门。

全员项目小组成员有全职的也有兼职的，视其工作范围和工作强度而定。他们通常在项目需要的时候才加入。核心小组成员有责任与各职能部门经理协商项目开发所需要的时间。核心小组成员通常为全员项目小组的个人绩效考评提供依据。

核心小组协调人

核心小组协调人在产品开发过程中协助核心小组组长和核心小组成员的工作。他们把过程改进重点与项目重点进行区别对待。多数人认为他们是在线辅助系统，即在开发过程过程中有步骤地引导核心小组或通过初级阶段审核来引导核心小组。

协调人帮助核心小组利用产品开发过程取得尽可能好的结果。他们是过程工程师，知道该怎么做。此外，他们还经常协助核心小组组长编制计划、进度及协调项目的各项工作。

除此之外，核心小组协调人还要了解开发过程的进度，密切注意发展方向，改进工作计划以及应用新工具。他们的职责是管理产品开发过程，并协助在所有项目中实施这个过程。

职能经理

一开始，许多职能经理对在组织中实施核心小组结构感到不自在，因为核心小组制定所有组织内项目级的决策，所以他们怀疑自己在组织中所起的作用。

事实上，对职能经理们来说，让其在管理一个或两个以上的开发项目的同时还要履行其在本部门的职责是不太可能的。一些职能经理想通过写详细的进度报告方法来解决这个问题，而另一些职能经理却采用每周写概要的形式，但所有这些只能帮助他们了解项目的现状，却不能使他们在推动项目的进程上起任何作用。结果是管理费用浪费过多，内部决策缓慢，而且职责不明。

按要求，职能经理需每日过问产品开发实施详情，而核心小组结构则取消了这种要求。这样一来，职能经理可专心于完善本部门的工作：促进本组织内技术水平的提高，制定长远计划和战略以及给多个核心小组配备资源。他们的工作效率提高了，经验也得到更好的发挥。

对于一个职能经理来说，进入核心小组结构也许有此冒险。那些过去常请示上级批准决定的人，现在自己要作出实施上的决策或与核心小组成员一起决策，会感到很不适应。这通常需要一个过渡阶段，因为这些人对自己在核心小组中的职责还不是很明确，所以对自己的决策能力缺乏信心。职能经理也需要看看决策的成功例子后才愿意移交权力。