【小白转型项目经理】实战案例13，项目处于整改阶段临近验收节点上如何交付不延期?

问题描述

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

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

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

在临近交付时间的节骨眼上，项目依然处在攻坚上。目前事业部高层对此事很关注，用户又非常较真的情况下（不想做延期）。我个人的意见是：先向用户提出验收申请，后面继续整改。但在流程上肯定会被用户打回来先整改，项目也会延期。

请问，在这种形式下，项目经理如何更好的破局？

解决方案一

一、问题的分析和解决

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

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

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

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

解决方案：

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

（一）关键路径：

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

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

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

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

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

4、快到验收节点了，其实能做到什么程度，已经是能心里有数的，一方面能做到什么程度，另一方面，剩下的一定是不影响主业务流程的功能模块，然后有明确的计划安排，给到用户承诺，一般以备忘录或者承诺函的形式让用户放心敢给你签字。 确定明确目标，方向没问题了，剩下就是投入了，这个就是每天确定任务，996 是福报， 该加班加班了。

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

二、需要反思的点

1、首先最重要需要反思或者搞清楚的是，“前项目经理，主要开发骨干都已离职”！！！ 这个是非常反常的事情，大家都是雾里看花，摸清楚这个深层次的原因，前期调研不清楚是一方面，不熟悉业务是一方面，衍生的，用户的需求变更是否频繁发生，为什么会出现重要组成成员都离职，这个是需要找找冰山下的东西。

2、这个攻坚，倾斜开发资源，我个人觉得这些都是在明确了目标之后做的事情。 整体来看，这个软件项目做到现在的状况，症结是不了解业务造成的，把握业务需求， 在标准化的业务流程基础上，可以做一些个性化定制，理论的东西就不在这里老生常谈了。

三、总结

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

2、接到救火任务那没办法，就是要往上顶了，回过头来想，正常带的项目过程。印象里有这么一个说法，提给大家共勉：好的项目经理不是说多么擅长收拾烂摊子的项目，而是会规避风险不让自己的项目陷入烂摊子的境地。

解决方案二

一、项目问题诊断

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

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

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

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

二、项目问题剖析和解决

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

项目的“需求管理”过程包括需求收集、定义范围、创建 wbs(需求分解）、需求确认、需求控制。 在项目前期，要重视需求管理，并做好项目文件的及时整理、细化，和确认。在需求原型、项目文件充足、客户及时确认需求的情况下，即使出现更换建机构部门也不至于出现因需求问题而出现返工的问题。

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

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

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

三、最后的话

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

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

作者：宋剑沁

十年 IT 工作经验

侧重项目实施和交付管理，GIS+智慧城市相关行业

作者：房爱德

10 年以上信息系统集成项目领域从业经验。主要从事城市公用事业领域的信息化建设

主要包括水气热公司的综合抄表、收费、客服呼叫、安检等方面的信息化建设

先后担任过十一五期间发改委发起的全国能源监控项目项目经理

北京 济南等大型水司燃气公司的信息化项目的项目经理等职务