范围变更管控案例_[范围管理]项目后期需求变更该如何控制

案例：

目前手上有一个系统开发项目，项目客户是一家从事房地产开发的企业，由于前项目经理请假的原因，现在由我接手负责这个项目。项目交接时，前项目经理表示目前项目所有配置都已经完成，并且项目实施人员已经和他们信息中心的人员把所有的配置都已配置好，就差培训了。可真正开始培训的时候，客户的老总又来检查我们的所有设置，包括各个表单字段等，并且还提出一些原系统上没有的需求，这样就导致需更改的东西非常多。

这个项目本身是一个小项目，目前公司这边催进度，客户那边又不断提出各种小问题，感觉真是一团糟，我改怎么办？

分析：

项目后期出现需求变更是件比较棘手的问题，我觉得应该从以下方面来进行解决

第一：加强与前一项目经理的项目交接工作，请前一项目经理转交项目需求说明书，项目范围说明书、项目变更控制流程说明书、进度说明等一系列文档，这样可以做到对整个项目比较快的了解和熟悉。

第二：对客户提出的需求变更进行分析，如果是开发出来的系统没有达到需求说明书里要求的成果，则要接受客户的要求，如果客户提出来的需求是原需求说明书范围外的新需求则要和客户提出来，和客户做好沟通，告知客户这些需求可以在这期培训或培训完以后，再进行开发。

分析1：

整体感觉出现这样的问题是由两个方面造成的：

1、需求本身并不明确，在系统设计初期，一般情况下与客户确认界面原型的工作往往会被忽视，实际上这就是典型的需求不明确。

2、工作交接不清楚，具体作了哪些，做到什么程度，是否与客户沟通并达成一致，看来没有交接清楚

解决问题，大体上分为几个角度：

1、首先将客户提出的问题也好，需求也好进行分类整理，大致可以分为如下三类：项目范围外的新需求、项目范围内的需求且对客户工作营销较大，必须进行修改的、项目范围内的需求但并不关键。

2、针对这三类，分别与客户进行沟通：对于需求范围外的，与客户明确，并确认是否必须要做，如果做的话需要追加合同；对于项目范围内且必须进行修改的，由于是前期工作出现失误，只能自认倒霉，列出问题列表进行修改吧；对于不关键的需求，尝试与客户沟通，寻找其他替代方式解决或让说服客户认可当前配置。

3、在项目过程中，本身双方就需要进行磨合，因此在功能并不是严重影响客户使用的情况下，说服客户培训与问题修改同步进行。

分析2：

首先，项目交接就出现问题了，文档齐全么？一定要和原来的项目经理有充分的沟通。口说无凭，要有文档，并且客户签字确认的。

其次，项目有范围说明书么？没有这个东西，项目是无尽头的。就算有了范围说明书，经过客户确认了么？不经过客户的认可，也是废纸一样的。

另外，客户的老总检查你所有的设置，那么配置说明书呢？在系统进行配置之前，这个应该和客户已经达成共识的。

最后，客户提出新的需求，那么是否在项目的范围之内呢？

解决的办法：

对项目的现状和客户进行沟通，出一份项目的现状分析。包括：完成了那些工作，那些没有完成，那些没有符合客户的要求。然后客户签字确认掉，给自己的老大审核。

分析好现状后，重新制定一个计划。客户签字确认，自己的领导当然要同意才行了。

然后，解决客户现在存在的问题，对所有的新需求，做好需求变更流程。