项目有延期风险，该怎么去和客户沟通？

Posted 2023-04-19

项目的启动会终于结束了，老张长长地舒了一口气，接下来项目就算是正式开始，一个项目从开始到结束时有好几个阶段的。

项目初始建立，项目中的各项资源还处于招募阶段，项目中的各项流程和规则还在摸索中。

项目的交付件输出非常不稳定，对于项目的风险识别明显不足，项目内外部各种意外事件频繁出现，一般情况下，这就是被称为项目的爬坡期。

项目组人员来自各个兄弟部门的内部人员以及本地招聘，这些四面八方的人员聚集在一起，摩擦不断，感觉难以管理。

项目组组织松散，执行力差，项目运作效率低下，客户侧的沟通也不顺畅。

对客户的需求和问题总是处于被动响应的状态，疲于应付，压力和责任似乎总是压在项目经理一个人身上。

项目交付总是处于被动的局面，好像是在打乱战，项目进展缓慢，不仅客户不满意，领导不认可，还被项目组的同事抱怨项目管理水平低。

“首先从内部抓起吧，不是说攘外必先安内吗。”

老张想了想，接下来就看老张这个项目管理团队的能力了，老张在项目例会上开始安排任务，

“第一步要建立和客户的沟通矩阵，用来适配客户的组织架构。”

“考虑到项目交付业务的特点、范围和便于管理的基础上，针对客户组织结构，项目组需要在自身的组织架构设计中设置足够的客户接口，以便于和客户分层分级进行对等沟通，以利于客户配合问题处理和快速解决。”

这是老张安排项目管理团队需要做的第一件事情。

“第二件事情就是要建立项目的报告机制，项目报告通常由周报、月报和日报等，项目周报和月报通常例行发给双方的项目关键干系人和项目组相关人员。”

“其内容不仅要包括项目的进度状态，还应该包括阻碍项目进展的问题，客户负责的工作，这样项目的进展和问题在客户和欣尧项目组相关的干系人之间透明化。”

“同时可以把压力传递到客户的中层和实施层的人员中去，加快项目问题和客户配合问题的解决进度。”

“第三件事就是要有项目例会机制，项目月度例会主要有项目经理，项目管理团队和客户高层月度召开例会，重点解决项目层面的重大问题和风险。”

“项目周例会主要是项目组关键核心岗位人员和客户参与，就项目的进展、问题、风险以及求助开展讨论，会后就会议达成的一致意见输出会议纪要并存档。”

老张说完这三件事情，技术负责人还补充了一点，

“技术管理团队还需要和客户的技术团队相应的召开技术周例会，以讨论和解决项目的技术问题。”

“对于某些临时遇到的特别和重要紧急的问题，我们可以和客户约定特别问题会议机制来应对此类问题的发生，使此类问题和风险得到及时的处理和解决。”

“项目交付过程中，如果存在这样那样的问题在项目组层面得不到及时解决，需要和客户约定重大问题升级处理机制。”

有了明确的任务，那接下来就是需要项目组和客户的配合问题，这才开始攘外，老张在项目例会上继续强调，

“各项目负责人要切实地担负起责任来，要和客户建立点对点的沟通和问题解决机制，问题解决不了的再逐层升级解决。”

“而不是所有问题都集中到项目高层来和客户沟通解决，这样项目高层就成了整个项目的瓶颈，项目交付效率也就不会高。

参考技术A 坦白沟通。跟客户坦白这样的事情，这样能让客户理解你，不会失了信誉。

项目延期的一些原因

概述

---

没有特殊原因，项目延期，这个字眼是不能随便说的，如果项目才开始不久或者还有一半的时间，就开始提延期，是不负责任的行为。因为还有很多努力的空间呢，如何解决如何应对才是你该想的事情。如果有些风险，就要延期，是很难跟老板、业务方交代的，同时也会让老板觉得，你态度和能力都有问题。

但是呢，我们还是要好好分析可能导致项目延期的原因，并做好的一些预防的动作，尽量避免由于项目失控，搞的项目的相关参与人手忙脚乱，压力山大的。

---

可能的一些原因

---

产品PRD问题

• 不清晰，PRD不清晰，描写的不清楚，看完后，有一种感觉就是：【你猜，我要做什么】？这种几乎是属于致命的问题，因为会给各个项目阶段，带来极大的沟通成本。无论是在需求评审阶段，还是在开发和测试阶段。有人可能会提出，不是能在需求评审的时候，对齐吗？不要指望需求评审，需求评审阶段，N多人有疑问，觉得PRD没讲清楚，产品经理调整完PRD后，会暂时达到一致。但是从实际的项目经历来看，一旦PRD从一开始就不清晰了，靠需求评审后去调整，后续也是有一堆不清晰的问题暴露出来，这个其实是写这个PRD的产品经理的能力问题，他/她压根就无法写出一个清晰的PRD。后续前后端和开发和测试人员，会经常性的在群里问问题或者开会对齐问题，浪费了非常多的时间，也就压缩了开发和测试人员做本职工作的时间。
• 不完整，也即是PRD有遗漏的地方，没考虑到。这种会加大开发和测试人员的工作量。
• 产品功能的设计过于烦琐，大而全，兼复杂。本来可以简化的功能设计的太复杂了，这个会导致不可控制性和复杂度的加大。产品经理也需要有项目的视角，多从项目整体执行和风险性的角度审视自己写的PRD的复杂性。

产品PRD是源头，如果在这个阶段出现了问题，一般都是致命的。产品经理写完PRD后，最好产品之间有内审，且提前跟开发和测试多沟通，尽量保证PRD的质量。具体的可以看一下技术经理成长复盘-产品研发要配合好。

开发和测试时间预估不准确

也即是过于乐观了，原本可能需要两周的工作量，却只评了3、4天。这种一般加班加点，也比较难搞定了。

• 开发时间的评估，稍微复杂一些的模块，最好让熟悉业务的资深开发帮忙评估一下，会相对准很多。另外也尽量有技术设计和技术评审这些环节，技术设计是逼自己努力想清楚，具体要做什么，有哪些关键的任务需要重点做。而技术评审，是请其他人review，尽量往正确的方向走。
• 测试时间的评估，同样的方式，需要让熟悉业务的资深测试协助评估。

沟通问题

也即是没有及时把风险同步出来。比如说，开发人员开发任务进行到一半的时候，觉得实现难度很高，但是想硬扛，在项目关键里程碑节点快到的时候，才提出来，耽误了工期。这种的话，只能通过监控的手段来避免。你可以在项目的每个里程碑节点的前几天，都主动去询问和了解进度，让相关人员及时出声。注意，不是说要搞每日站会哈。

第三方依赖的问题

因为第三方依赖它不可控，如果没有及早的梳理和对清楚，到了项目后期才暴露出问题，那真的是回天无力了。无论你多急都没用，第三方公司就是有自己的节奏和规章制度，不会听你的。像美团、支付宝、微信、外包公司等等，只要项目有涉及到第三方的，一定提前把所有事情都对清楚。

需求变更

这个可能是PRD质量有问题，也可能是来自外部的原因，比如说，业务方或者大老板有新的想法。
无论需求变更是大还是小，出于降低风险的角度出发，开发、测试都需要重新认真评估的，这无疑又会多出来很多工作量。

研发流程体系不完善

前面列到的几种原因，很多都是研发流程系统不完善导致的。项目要有序执行，除了靠人，还需要靠流程体系。
研发流程体系，不只是研发内部需要遵循，研发外部的产品、运营等业务方也需要遵守。因此需要有一个强有力的老大去落地推广这套体系，这个真的很重要，如果没有这号人的话，基本上流程要很好的落地，都是极其渺茫的。