|
案例一：延津信用项目心存侥幸没有做好范围管理
案例描述：该项目在制作项目范围文件，有一项工作是手机客户端，包括做微信公众号、安卓app和iosApp，由于当时我们公司没有ios工程师，也没有做过ios的app，做ios的app比较困难，就跟客户沟通了一下，说是否可以只做微信公众号和安卓版的app，这三个客户端入口的业务功能都是一样的，客户也同意了，但是后来客户调走了，到项目验收时，第三方评估验收公司发现少了iosApp的手机客户端，需要补上才能通过验收，接手的客户要求以第三方意见为准，不得已又让公司技术人员研究和开发iosApp，从而导致验收延期2个月。
案例问题：
（1）、只是跟客户口头沟通，没有按照流程变更范围；
（2）、心存侥幸，由于有技术难点，就想稍作功能；
（3）、风险评估不足，没有对客户会调离以及缺少功能验收不通过的风险进行充分考虑。
再遇到此类问题的处理方法：
在项目启动初期就制定项目变更流程，在做范围梳理时要涵盖合同包含所有工作内容，有问题的部分要跟客户沟通清楚，需要变更的按照变更控制流程进行变更，有书面证据。在实施项目时确保项目范围的工作内容全部做完，并制定合理的工作计划，并按计划节点进行工作完成情况检查。
案例二：武汉项目需求没有书面确认就开工，导致需求多次变更
案例描述：由于当时为了在一定的时间内给领导做汇报，销售人员承诺客户我们项目团队一个月之内能够完成平台开发和上线，所以，项目一开始就没有按照流程进行启动和策划，而是按照一个月的期限进行倒排计划，没有过多考虑计划可行性，也没有跟客户确认项目范围和功能需求，只根据标书的描述，做了一版《需求规格说明书》，并做了一次简单的内部需求评审就开始动工开发了，最终在项目团队加班加点的共同努力下也按时上线了，但是客户一看，很不满意，页面美观度和功能操作性跟预期都有很大的差距，又花了两周的时间进行了优化，然后给他们的一个领导进行了汇报，该领导又提了很多问题，又花了两周的时间进行了修改，满足了该领导的要求，但是又跟一个大领导汇报，大领导又提了一些问题，有些问题跟之前领导提的问题还有冲突，客户要求以大领导提的意见为准进行修改，这样反反复复改了多次，花费了将近半年的时间终于满足了客户的要求。但是在项目开发期间，客户一直不给确认需求文件，因为他们不确定领导还会提什么问题，为了不承担责任，就一直不给确认。虽然后面也顺利验收了，但是我们在该项目中投入的成本比预期大幅增加，团队士气也比较低落，项目需求一直处于不可控状态。
案例问题：
（1）、销售人员在没有跟公司后端人员沟通的情况下盲目承诺；
（2）、在项目启动阶段没有按照正式流程启动，没有制定项目整体变更控制流程，没有建立变更控制委员会；
（3）、在项目启动阶段没有充分评估项目范围蔓延的风险；
（4）、没有足够重视需求评审，导致很多返工。
（5）、没有进行有效沟通，促使客户进行需求确认；
（6）、没有确定统一客户对接人，导致多个领导提了不同的意见，做了很多无用功；
（7）、没有根据既定事实去调整项目管理模型（瀑布模型调整为敏捷开发模型），导致项目团队士气低落。
再遇到此类问题的处理方法：
不管时间有多紧，项目启动和范围确认工作不能应付，一定要确认清楚，根据确定的工作范围，制定合理可行的工作计划，有问题要提前跟客户沟通，可以通过减少工作内容的方式进行赶工，减少的工作内容后面期再补上。从而保障开发的系统功能是客户需要的，减少返工，提供工作效率，降低实施成本。在项目启动阶段就明确项目变更控制流程，建立变更控制委员会，委员会成员要有甲方代表，要进行范围和需求变更都要走正式的变更控制流程。项目一开始就要跟甲方沟通清楚，要确定一个对接人，不管是需求变更以及其他工作都要在甲方内部形成统一意见后，由对接人传达，从而降低客户方中有不统一的意见传递给我们。
实战项目案例三：姑苏信用二期项目，没有严格执行变更流程，导致需求多次变更，范围蔓延
姑苏信用二期项目是智慧姑苏项目的一个子项目，各种流程标准都统一使用智慧姑苏项目的标准流程，项目启动后也制定了项目整体变更流程，在项目范围确认阶段，做需求调研的时候，客户增加了一些合同中中没有的功能，去掉了一些功能合同中写的功能，按照正规流程是需要走变更控制流程的，但是智慧姑苏项目部和监理公司认为变更比较麻烦，因为涉及项目金额的变动评估，所以就没有做变更。在做需求确认的时候，客户改了一些需求规格说明书的文字描述，比如好几处加了“等”、“后期根据需要再定”等字眼，以方便他们后期有功能增加或修改，我们当时为了能够按计划完成需求确认工作，就同意了。在系统上线试运行后，客户经常给出修改意见，每次都比较急，导致后端开发人员在试运行阶段做了7、8次的功能优化开发，大大超出了计划工作量，导致后端开发人员有些怨气。最后验收时又需要加上需求调研时客户不要的功能，因为验收专家是根据合同来验收的，没有变更文件，所以只能添加，导致验收时间推迟了2周。
案例问题：
（1）、制定了变更控制流程，并没有严格执行；
（2）、在需求确认时，为了按时完成工作，当客户要求在需求文字描述中增加可变需求的文字描述时，做了妥协，为后期需求多次变更埋下了隐患；
（3）、没有跟客户有效沟通，每次功能优化都是紧急任务；
（4）、没有充分评估范围变更对验收的不利影响风险；
再遇到此类问题的处理方法：
在项目启动后，制定合理可行的整体变更流程，在确定范围时宁可多写工作时间，也要跟客户沟通清楚，不要模糊。如果跟合同或标书有出入的部门，评估是否需要变更，是否对验收有影响，如果有影响就必须走变更流程，不要怕麻烦，因为前期麻烦一下子，后期就不会麻烦一阵子。不要存在侥幸心理，不要妥协，跟客户进行平等沟通，如果遇到反复变更需求的情况，要跟客户沟通清楚优化频率，积累一定的时间和次数再统一优化，比如“一个月更新一个版本”，避免因频繁修改而影响项目团队士气。
（1）、项目启动后，一定要制定科学合理的整体变更流程。实质发生了范围变更，一定要严格按照正式的变更控制流程进行变更项目范围。
（2）、项目范围一定要明确，有不明确的，要各方（建设方、监理方、承建方）共同协商解决，并通过建设方的确认批准。
（3）、在制定和确认项目范围文件时，要请监理核实是否可以支撑项目验收。
（4）、在项目前期成立项目整体变更控制委员会，成员必须要有客户负责领导，所有范围变更都要经过变更控制委员会批准。
（5）、请甲方指定一个对接人作为甲方项目经理，全区与我方实施人员对接，我们只接受对接人的意见。
（6）、跟甲方沟通时要不卑不亢，平等交流，要知道我们只是合作关系。
（7）、需求评审不能走过场，每一项功能描述都要清晰，不仅要符合客户需求，也能通过公司技术人员的评审。
（8）、项目试运行阶段，要跟客户沟通明确版本更新频率（比如一月一次），在试运行期间，客户可以随时提优化建议，但是需要评审后再统一优化，按计划周期更新。
|