当研发项目具有相当的实施难度时，仅仅关注进度就不够了。另外，我们也发现，有些研发项目从管理角度来看还算规范，但是过程中的一些意外总会打乱项目节奏，项目最终趋于延期或者失败。此时需要采用更加完整、深入的手段去管理项目，这就是高级项目管理关注的内容。

即使在一家公司内部，研发项目特点也各不相同，项目经理需要根据实际情况采取针对性策略去开展项目：有的项目在技术实现方面没有成功先例，该项目就应将技术风险放在首位，尽快验证技术成熟度；有的项目在交付周期方面具有严格的限制，就应该采取一系列手段加快项目进度；还有的项目团队新近组建，彼此缺乏默契，团队建设将成为项目经理重点考虑的因素。如果项目经理对待任何项目都采用千篇一律的管理，只能说明他缺乏对项目特点的透彻认识，没有重点的管理将使得项目运作低效。

进度是一个研发项目最关注的目标，实际上进度目标包含了诸多要素和目标的实现。我们无法想象在产品质量不成熟、功能实现不完整的情况下，“按时”交付产品具有多少价值。也就是说，对质量、成本、资源、风险等诸多要素的管控，最终是为进度目标而服务的。

某公司为了提高研发项目运作效率，参考了行业标杆公司的优秀实践，制定了规范化的研发项目管理制度。但是在执行时发现项目效率并没有获得相应提升，很多项目经理反映新的管理体系尽管很规范，但是过于烦琐，相当比例的文档对项目的实际意义不大。

需要注意的是，并非按照要求“做了”就是规范化管理，就能够提高效率；更重要的是“做好”，以真正发挥作用。项目管理的诸多要素、工具、过程就像字典一样，做文章时，需要将这些字词进行有机组合。

接下来看一个失败项目的案例：

软件提供商A获得了为香港地区知名的电信运营商M开发软件系统的机会，这是关乎A公司未来发展方向的关键项目。A公司计划以成熟的BOSS18系统为基础，根据M公司的需求进行定制。

项目经理小W响应迅速，立即落实了项目成员，并积极做客户沟通等相关准备。然而市场负责人很快发现M公司要的不只是BOSS所能实现的计费功能，而是一个办公软件系统。

考虑到该项目对A公司步入海外市场意义重大，在软件设计师颇有非议的情况下，公司还是决定：“M公司要什么功能，我们就做什么功能。”

项目经理小W开始了马不停蹄地工作：编写了近200页的需求规格书，进行了4个多月夜以继日的项目开发；在产品部署之前，项目团队为客户进行了一次远程演示。这时，大家才惊讶地发现M公司要的是一个业务操作平台，新系统的实现方式不符合M公司的业务操作习惯。

在这种不利局面下，项目团队再次做出努力：认真了解M公司的业务需求，将原来的工作推倒重来，重新进行开发。期间也遇到了客户接口人抵触、需求不断变更、沟通存在障碍等困难，项目团队坚持着积极负责的态度。

但是随着无休止的开发、演示、沟通、返工，项目已经延期半年有余，这几乎耗尽了双方的耐心。面对M公司给出的终止项目和赔偿的通牒，小W画了半天的决策树，也没能理出个头绪来，不知道该把队伍引向何方。

这是一个令人遗憾的案例。

决定研发项目效率的首要因素是项目经理的管理经验和项目团队的业务能力。在上述案例中，以小W为首的项目团队，既没有及时识别重大的实施风险，也没有对M公司的业务需求有一个清晰理解，想当然地认为修修改改就能够满足客户的需要，因此项目失败并不意外。

虽然A公司对此类项目有着一套成熟的管理方式，但是这只能算得上“初级项目管理”，达不到“高级项目管理”的层次。当研发项目具有明显复杂度时，即使达到了初级管理的要求，也会由于管理重点失当、风险缺乏识别等问题，致使项目失控。

在高级项目管理中谈到的项目策略，指的就是及时识别项目在交付周期、技术/业务难度、产品需求等方面的重大风险，并采取有效措施进行预防。

在该案例中，称职的项目经理应该在项目启动时就意识到这是一个全新系统研发项目，在技术难度、业务理解方面存在巨大风险，并且立即采取应对措施：

​ 在启动之前对项目的可行性进行评估，判断该项目是否应该承接；

​ 要求业务领域骨干参与项目，并且与客户建立密切联系；

​ 通过建立原型、迭代等方式，尽快明确客户需求；

​ 慎重评估项目工作量和资源需求，制定合理的进度计划。

◎​ 项目群管理

当企业的研发项目出现大范围延期、资源冲突屡屡发生时，我们需要反思的是，整体的研发资源供给是否充足。

图3-36项目群管理

项目群管理主要关注于将研发资源按照项目优先次序进行配置，这需要在单独项目管理成熟的基础上进行。如图3-36所示。其中最重要的是产品线这个层面，担负着确定项目优先次序、配置研发资源和及时解决资源冲突的任务。

下面我们关注一个研发项目资源冲突的典型场景。

B项目的某模块主力工程师Y，因其对该模块的熟悉程度，在对应的换代产品项目C启动时，从B项目调至C项目，从事同类模块的开发工作。Y在C项目组的工作量达到了满负荷。

在C项目的进展期间，B项目的补丁版本随即启动。作为不可替代的一员，Y还须参加B项目原负责模块的开发及维护支持。因为B项目中该模块的开发计划早在Y调离前已制定，且该模块并无他人可以替代。

此时B、C两个项目在人力资源和项目进度问题上存在严重矛盾。

以上述案例为背景，C项目经理如何应对问题呢？

显然C项目经理立足于促进本项目的顺利交付，他可能采取的措施包括：坚决不释放资源、与B项目经理协商Y的工作比重、向高层领导施压、要求Y付出更多精力以兼顾两个项目、对Y提供更大的利益等。类似的，B项目经理也会采取同样策略进行应对。这是完全符合逻辑的。如果项目经理妥协，他所领导的项目将趋于延期，这显然不是一名合格的项目经理。

那么此时，作为项目经理的上层管理者，如何应对该问题呢？

这位管理者应该立足于项目组合的顺利交付，综合考虑两个项目的重要程度和资源配置，做出最有利的决策，也就是“两利相衡取其大，两害相较取其轻”。他的判断难度在于如何避免被项目经理的夸张表演所左右，把握资源冲突的真实情况和研发项目的重要程度。

产品线层面出色的资源调配，可以提高研发资源的使用效率，却无法化解资源总体短缺的瓶颈。如果公司层面能够对业务发展具有清晰的预期，及时培养和储备关键性资源，将会令资源冲突问题大为改观。

预测未来的业务发展趋势并非易事。通常做法是，研发资源的配置相对富余一些，或者按照一定的折扣比例去计算研发资源的产出，这样会为突发事件提供周旋余地。

将研发项目管理分为三个层次，源于实际工作中的各类典型问题。如果改进措施选择错位，将无法解决问题。为了缓解整体研发资源短缺的矛盾，需要在项目群管理上下功夫，评估项目的重要性和优先级，将资源合理的投放，而此时强调项目的规范管理则无济于事；对于规模庞大、需要跨专业协作的研发项目，配置缺乏经验的管理人员，采取初级管理手段，这显然也是不恰当的。

需要注意的是，项目的复杂程度决定了项目管理的涵盖范围。在项目交付周期短促、风险可控、工作量不大的情况下，一套的初级项目管理就可以满足需要；当项目趋于更大规模且风险复杂的情况下，则需要高级项目管理机制。如果一味追求研发项目的规范化管理，诸多管理要素一个都不能少，将会出现“高射炮打蚊子”的尴尬局面。

下面我们展示若干研发项目管理改进的案例：