又双叒叕延期了！研发项目的准时交付，只能靠加班？

在走访企业的过程中，一提到项目延期的原因，可以说是五花八门：

1.前期设计不充分，导致技术方案调整：营销没参与前期方案阶段，或疏于参与设计的过程管控，导致产品上市后营销困难。

2.工作量评估乐观，实际工作量超预算：老板理所当然地认为，觉得既然其他企业都能做到，那我们肯定也可以，却忽略了别人的经验积累和技术优势。

3.资源协调问题：一些企业的计划性比较差，没有做好资源的有效管理。哪个项目急就先做哪个，早期的项目不断被插队，进度只能不断推后。

4.紧急市场项目需求：实际工作中，很多企业没有依靠IPD（集成产品开发）流程，缺乏市场需求定义/评审环节，仅凭开发人员个人经验识别，产品推出后问题不断，客户经常有临时需求需要修改。

5.新产品开发中使用的技术不成熟：技术尚未成熟，项目就急于进行下一步，导致开发周期延长。推出产品之后，反复出现质量问题需要返工。

除了以上的这些，更有人力配置不到位、关键技术人员瓶颈、跨部门协助困难、供应商不能按计划交付等等。

每个研发项目都会面临各种各样的问题，但这些都不是延期的理由！

要知道，研发项目延期带来的影响是巨大的。就像多米诺骨牌一样，只要其中一个环节出错，就会产生连锁反应：

零部件的采购/库存受影响、市场机会窗的错失、生产制造计划的被迫调整、市场推广活动的推迟......最重要的，是会损害客户对企业的信任感和忠诚度，导致客户流失和口碑下滑。

试想下，一个老是说到又做不到的企业，又怎么吸引客户建立长久的合作关系呢？

针对项目延期的问题，其实也不是无法解决的。

同一个产品需求，明明都在同一个研发部门，为什么有的人（精英）做了一次就过，而有的人则需要反复返工？

能不能把精英的经验复制成组织的能力，形成企业的产品开发管理体系，让所有的产品开发人员都按这套方法操作，一次性把事情做对呢？

标杆的实践证明，95%以上的研发项目都能按计划交付。

按照IPD产品开发、技术开发流程，做好需求分析分解和工作量评估，做好项目计划并高效执行，管控进度和技术风险，项目按时交付是完全可以实现的。

产品开发不仅可以被管理，更是可以被流程化、规范化管理的。

工欲善其事，必先利其器。

首先，打造一支胸怀梦想、充满活力、团结奋进的研发队伍十分重要。

只有团结一切可以团结的力量，全营一杆枪，才能持续构建最具竞争力的产品和解决方案。

就像是一群人拉一块大石头，如果所有人都往同一个方向发力，拉起来就很轻松，前进的速度自然就飞快。但如果有的人往东拉，有的人往西扯，力量被相互抵消，石头就会缓慢前行，甚至停在原地不动。

在这过程中，牵引所有人都往一个方向发力是关键。

企业可以建立合适的研发项目绩效管理机制，将项目进度的偏差当作产品开发/技术开发项目考核的最主要指标。

这个指标与团队绩效相挂钩，直接影响到整个团队的奖金评定和职位晋升。

在职能式管理组织中，员工的绩效直接由部门领导说了算，部门领导决定了员工的前途和命运，所以员工更愿意直接听部门领导的，工作重心自然就偏离了项目本身，更别说要以客户为中心了。

但面向市场的研发项目是需要跨部门协助的，甚至需要直接面对客户，一旦沟通协助不畅，就会导致项目延期。

IPD流程明确了项目经理要对项目目标的实现负责，建立基于矩阵式的绩效管理模式，让项目经理责、权、利对等。

需要注意的是，项目管理和技术管理的能力要求不同。

项目经理需要对业务有较深入的认知，站在全局思考者的角度，思考项目的进度、质量、成本等，以及是否能为公司带来更大的价值，并及时处理问题和规避风险。

虽然许多技术人员在技术表现上很出色，但这并不意味着他们也具备强大的沟通能力，能敏锐地感知市场风向以及准确地获取客户需求。

因此，重视基层管理人员的能力建设，设置专职的项目经理，打通人才培养通道也是十分重要的。

很多企业的工作量评估往往比较粗糙。

例如，一个最小的任务经常被评估为需要2~3个月来完成，这意味着我们要在2~3个月后才能对成果进行评审或测试，即使发现问题了，也很难在一两周之内赶工修改到十分细致和完美。于是，项目也就只能延期了。

为了解决这个问题，我们可以借鉴标杆企业的做法，对WBS粗粒度进行管理。

企业可以利用过往的经验数据来建立一个基准，以避免项目经理完全依靠个人经验识别WBS，后期不断修改增加改正成本。

通过将研发项目活动从上到下按照树状结构逻辑性地分解下来，每个任务的工作量不超过40个工时，也就是一周的时间。这样，研发部门可以及时纠偏，从而更好地控制项目进度。

没有分解不了的工作，如果你认为分解不了，那么大概率是因为还不够了解。

其次，要尽量减少任务之间的耦合，避免出现过多任务相互依赖的情况。

研发部门应该努力实现任务的并行处理，让团队成员能够同时推进不同的任务，从而减少依赖点。

耦合度越低，模块之间依赖的程度越低，模块的独立性、复用性和可移植性就越强。

才能尽量避免被动陷入“牵一发而动全身”的窘境，在测试和变更管理中也能更灵活处理。

在这过程中，要切记不能仅仅只是埋头苦干，又或者是将里程碑设置得过于宽泛。

很多项目经理的进度设置时间范围跨度很大，比如只按照IPD的流程将几个Tr点设置为里程碑。

大多数人在工作时都有“前松后紧”的习惯，里程碑可以强制规定在某段时间做什么，从而合理分配工作，细化管理力度。

每一阶段的进度都需要逐步逼近目标，里程碑产出的中间“交付物”就是每一步逼近的结果，也是控制的对象。

管理者需要思考，如何让企业有限的资源实现价值的最大化。

在进行项目相关工作时，研发部门不应该抱着侥幸心理，认为公司资源（人力资源/实验室/设备等）随时可调用，特别是在需要共享资源的情况下更要谨慎。

企业可以使用SPAN（战略定位分析）组合管理工具进行项目优先级、规划路标的制定，合理分配和管理资源。

对于新加入的项目，要进行专项决策评审，不能随意插队进入到公司资源管道中。

在新产品的研发项目中，以客户为中心的要求使得紧急需求的变更不可避免。

首先，根据过往项目经验数据，研发部门可以先预留一定的工作量以应对可能出现的变化。

其次，面对客户的新需求，研发部门其实不一定需要无条件满足。可以先进行需求分析，考虑需求实现的必要性。

产品管理/SE可以在需要的时候到一线与客户沟通，理解客户的真实意图。如果需求确实合理，那么再来考虑实施的问题。

事实上，很多需求可以通过暂缓或者其他方式处理。

因此，理解客户的真实需求并做出合理判断，是项目管理中不可或缺的一环。

如果市场需求变化无法避免，且这种变化对进度产生了重大影响，研发部门需要采取相应的措施来确保进度不受过多干扰，比如和一部分优先级相对低的需求进行置换或降低部分规格，以保证整体进度不受影响。

在这里要注意的是，在保证质量的前提下，进度是最优先的考虑因素。

例如，原计划可能包括10项任务，但如果进度受到威胁，研发部门可能会调整为9项，以确保项目能在规定时间内完成。

在项目管理中，我们需要特别注意技术成熟度的问题。

为了避免在开发过程中因技术不成熟而导致的创新滞后问题，企业应该适当分离产品中的技术，并对不成熟的技术进行提前预警和准备。

就像搭积木一样，先把成熟的技术模块准备好，打好底座，在产品开发的时候即拿即用。

如果涉及与供应商合作，与供应商保持密切沟通则是确保项目顺利进行的关键。在极端情况下，研发部门甚至需要与供应商联合解决问题，如采取工程师驻场等方式来确保问题得到及时解决。

同时，企业也要准备备选方案（Plan B)，以确保项目不会因单一方案的失败而受阻。

最后，要做好风险管控。通过各种手段来控制风险，其中包括定期的会议机制，如每日站会、项目例会和PDT例会等，及时了解技术、进度、资源等风险，及时给出应对措施。