项目处于整改阶段，临近验收节点上如何交付不延期？

本期话题:项目处于整改阶段，临近验收节点上如何交付不延期?

一、背景介绍

受诊人职位： 交付项目经理(救火项目)

公司：从事于政府机关单位业务系统开发的公司，以事业部划分业务，我处于负责政府业务的事业部。事业部架构由项目管理、开发、实施等岗位组成。

情况：由于公司近期转型：项目由一个很熟悉业务的机构部门，转至了一个陌生业务的机构部门。由于前期调研不清楚，开发出的业务系统，在试运行期间出现了大量的返工。

前项目经理，主要开发骨干都已离职，虽然补上了新人，在我接手之后发现项目进度依然落后太多。由此，我向事业部高层申请了 倾斜一些开发资源对项目进行攻坚，但质量问题依然频繁的出现。

问题：在临近交付时间的节骨眼上，项目依然处在攻坚上。目前事业部高层对此事很关注，用户又非常较真的情况下(不想做延期)。

我个人的意见是：先向用户提出验收申请，后面继续整改。

但在流程上肯定会被用户打回来先整改，项目也会延期。

在这种形式，请问怎么更好的破局?

二、嘉宾分享

01

一、问题的分析和解决：

从案例反馈的信息来看，提到几个点是需要请各位关注的，抽取出来，后面的总结，我也会提出自己的疑问和思考，供大家参考。

1、“项目转到陌生业务部门”——是否可以理解部门对该项目业务陌生，目前状况如何，如果依然对项目的业务陌生，那问题就有点过分了。

2、“试运行期间出现大量返工”——已经到试运行阶段了，从字面来看，猜测是业务流程契合度不够造成，返工是否找到符合业务逻辑的路径。

3、“质量问题依然频繁出现”——这里我的疑问，这个质量，是业务满足用户需求，只是功能性bug还是说业务流程不符合造成的质量问题。

解决方案：

“面对的是政府机关单位的业务系统，临近验收时间”，软件产品的交付，一定都是有个磨合的过程，先把自己建议的关键路径开门见山，然后提出一些认为需要大家反思的点。

(一)关键路径：

1、这个事情比较好的一面是，其实已经前面已经有人试错了;关键的业务流一定要重点保障，如果这个到现在都还没有明确，那这个事情基本上就没法玩了。

2、内部一定是要多次组织需求和业务流程的讨论会，召集真正懂业务，了解用户一手需求的相关干系人，多次讨论，并且把阶段性结论与用户多碰几次。

3、政府单位，现在要着急验收，其实要考虑他的痛点，到年底了，他们报的预算想办法都要把钱花出去，业务系统一定要能用起来，不然过不了审计考核。

所以我是赞同受诊人的意见，肯定是要验收，不过这个验收不是一厢情愿，一定是要跟用户交底的，首先核心业务一定能保障，然后在验收前，详细的跟用户交底能做到什么程度，在这个问题上与用户需要达成一致。

用户核心诉求满足之后，用户较真归较真，这个时候需要打配合的，市场人员和交付都要配合着来，有必要高层也出面，该搞关系要搞搞关系。

4、快到验收节点了，其实能做到什么程度，已经是能心里有数的，一方面能做到什么程度，另一方面，剩下的一定是不影响主业务流程的功能模块，然后有明确的计划安排，给到用户承诺，一般以备忘录或者承诺函的形式让用户放心敢给你签字。

确定明确目标，方向没问题了，剩下就是投入了，这个就是每天确定任务，996是福报，该加班加班了。

5、确定明确目标，方向没问题了，剩下就是投入了，这个就是每天确定任务，996是福报，该加班加班了。

二、需要反思的点：

1、首先最重要需要反思或者搞清楚的是，“前项目经理，主要开发骨干都已离职”!!!

这个是非常反常的事情，大家都是雾里看花，摸清楚这个深层次的原因，前期调研不清楚是一方面，不熟悉业务是一方面，衍生的，用户的需求变更是否频繁发生，为什么会出现重要组成成员都离职，这个是需要找找冰山下的东西。

2、这个攻坚，倾斜开发资源，我个人觉得这些都是在明确了目标之后做的事情。

整体来看，这个软件项目做到现在的状况，症结是不了解业务造成的，把握业务需求，在标准化的业务流程基础上，可以做一些个性化定制，理论的东西就不在这里老生常谈了。

三、最后总结下：

1、一般这种救火项目，短时间要说做多大扭转其实很难，之前做的那些工作推翻重来不太现实，我们重点还是以核心业务出发，抓住这个之后再去修剪其他枝节。

2、接到救火任务那没办法，就是要往上顶了，回过头来想，正常带的项目过程。

印象里有这么一个说法，提给大家共勉：好的项目经理不是说多么擅长收拾烂摊子的项目，而是会规避风险不让自己的项目陷入烂摊子的境地。

02

个人介绍：

房爱德，10年以上信息系统集成项目领域从业经验。主要从事城市公用事业领域的信息化建设，主要包括水气热公司的综合抄表、收费、客服呼叫、安检等方面的信息化建设。先后担任过十一五期间发改委发起的全国能源监控项目项目经理、北京 济南等大型水司燃气公司的信息化项目的项目经理等职务。

项目问题诊断：

问题一：“由于前期调研不清楚，再加上更换了承建机构部门，导致需求与客户真正需求差距较大。”这说明项目的“需求管理”存在问题。

问题二：“前项目经理及技术骨干离职，造成返工。”这说明项目的“资源管理”存在问题。

问题三：“在临近交付时间的节骨眼上，项目依然处在攻坚上”这说明项目的“进度管理”存在问题。

问题四：“先向用户提出验收申请，后面继续整改。”这是PMP^®标准管理中不推荐但一般行业内比较常用的策略。且不说结果是否按题目中项目经理所料，这种方式的处理一定要做好“风险管理”。

项目问题剖析和解决方案：

1、“由于前期调研不清楚，再加上更换了承建机构部门，导致需求与客户真正需求差距较大。”这是导致返工及项目延期的根本原因之一。

项目的“需求管理”过程包括需求收集、定义范围、创建wbs(需求分解)、需求确认、需求控制。

在项目前期，要重视需求管理，并做好项目文件的及时整理、细化，和确认。在需求原型、项目文件充足、客户及时确认需求的情况下，即使出现更换建机构部门也不至于出现因需求问题而出现返工的问题。

2、“资源管理”最重要一块是团队的建设，前项目经理及骨干的离职也更一步加剧了项目返工和延期问题的出现。项目经理要运作项目管理技巧，建设团队，处理冲突，建设一个稳定高效的团队是项目成功的基础。

3、“进度管理”在贯穿项目各阶段，字义好项目活动，评估出优先级，列好关键路径，始终监控项目进度是否符合计划。而不是在临近交付结点时才想到要重点监控。

4、“先向用户提出验收申请，后面继续整改。”这种方式不推荐，若一定要采取这种方式则要做好“风险管理”。评估出这样的各种风险情况，包括项目范围，后期成本，预防成本超支造成的项目失败。

最后的话：

1. 项目管理最关键不是在于问题出现后的解决，而是预防。预防问题出现远远重要于出现问题后的解决。

2. 重视项目范围管理，特别是需求的明确与确认。还要重视项目的文件的重要性，它会是沟通管理的重要支撑。

03

/ 我有话说 /

㊧佚名氏㊨-上海-IT：

“整理清楚有哪些要整改的东西，是已经全部整理出来了但是来不及整改，还是说还在不停的冒出未知的问题来? 对于已经出现的问题，罗列优先级，哪些必须什么时候改完，哪些可以拖到验收中再整改(验收也需要过程)，什么样的整改需要投入什么样的人。 根据整改的状况，需要加班的加班，实时监控进站。 需要公司高层向政府部门展开公关，看是不是可以延期，或者分批次验收。”

小明童鞋-长沙-集成：

”项目的核心问题应该是业务需求不清晰导致的返工，造成的工期延误。项目的进度管理没有做好，那么解决的办法只有两种可能。与客户协商，小批量交付或者内部解决，赶工和追加资源，既然公司领导重视，那么从内部的解决来说可能力度更大一些。另外还的看看当初和客户协商的交付方式，几个方面结合起来看怎么解决。“

MISS丁 杭州 软件：

”破局处理： 1.了解此项目成败对公司的影响有多大?会不会影响其他项目的进展?客户对此项目的成败持什么态度? 2.进度延迟的根本原因是什么 有没有解决方案? 3.方案实施后?能否解决?方案实施的难度有多大? 4.如果方案能解决且客户对项目成功很重视，与客户沟通列出整改里程碑计划及整改后的成果优势。 5.预估可能的成本增加。“

李洁兰-广州-软件：

”1、梳理交付设计的确认版本需求文档，检查整体业务流、功能模块。 2、对比当前项目成果，全部开发完成没有?哪些是不符合验收标准的?哪些是变更的? 3、跟接口人确认验收标准、协商计划。 4、先按初始版本验收、上线，变更部分再协商为优化版本。”

“对外：协商。 对内：协调资源，扫坑。“

Fiona-福州-软件：

”我觉得， 可以先交付已经可以交付的小的模块 ，暂时还不能交付、 还在整改的东西 ，罗列出来 。跟客户讲明白为什么还在整改 ，是因为客户需求变更 还是其他原因 ，并且要说明大概需要多久整改 ，什么时候可以提交给客户。“

”重新梳理需求，然后确认优先级， 与客户经常沟通进度 ，已经做完部分成品就可以先演示给客户看，然后再加加班，赶进度。“

木凡-沈阳-医疗IT：

”完成的模块签字验收，未完成的部分通过备忘录的方式进行验收，并与客户确认修改方式，明确可实现的开发交付计划。”

小糊涂仙-重庆-物联网

“赶工、增加资源、提升质量避免返工、外包，培训或引入高技能项目成员，无非这几种方法。”

Bysing-广东-珠宝：

“向领导汇报当前进度，重新做好进度规划，把控时间点，可交付哪些，延后交付哪些，内部协调好后再找项目接口人协商，提出自己的建议想法。”

精髓总结：

1、与客户沟通协商，明确客户态度，再确认需求优先级，找准病根，重点攻坚。

2、好的项目经理不是说多么擅长收拾烂摊子的项目，而是会规避风险不让自己的项目陷入烂摊子的境地。

三、讨论内容整理

[以上关于项目团队管理的内容都来自于希赛「PM创造营」群内话题讨论，由@小M妹妹 妹妹整理，由以下小伙伴分享完成@浙江-小王-汽配PM@啊潮-广州-互联网@凉风有信-广州-ERP@踏风而至-北京-通信@王金陽−杭州−IT@星子-广州-智能建筑-轨道交通@Fiona-福州-软件@Zen.Wu-政务教育高校@MISS丁 杭州 软件@追星骑士-深圳-金融IT@㊧佚名氏㊨-上海-IT@简单-西安-软件@熊猫-拉萨-系统集成@huang—上海—通信@小明童鞋-长沙-集成@꧁云淡风清꧂-大连-电控@Soda-宁波-汽车@小唐-郑州-软件@kawasaky-哈尔滨-金融@阿敏敏-武汉-互联网产品@李洁兰-广州-软件@凉风有信-广州-ERP@浩-深圳南山-金融行业@阿德-淄博-城市公用@Bysing-广东-珠宝@黑科技-贵阳-IT@天天-北京-铁路自动化@闪光创世-上海-IT@木凡-沈阳-医疗IT@D-深圳-OTA@Roy-济南-智慧停车@牧云-成都-互联网产品@山东-软件-李工@建庆-深圳-智慧城市-GIS@Kerwin-成都-政务@阿正-北京-物联网@彭祥-上海-供应链SCM]