时间：项目启动期 地点：经理办公室

    老王[部门经理]：小项啊，销售部的这个CRM系统可是今年的重点项目，领导们都很重视，一定要确保按时交付啊！

    小项[项目经理]：老大请放心，保证完成任务！

    老王：好！不过有些情况还是要注意，这之前的几个拖期比较严重的项目，咱们内部也总结过，差不多都是因为需求变动造成的，这次你可要把好需求管理这道关，别犯过去的老毛病啊！

    小项：是，老大。以前那几个项目，都到了开发阶段还在不停增加新功能，才导致工期一拖再拖，这回我们从需求阶段就把好关，老大你也跟销售部的老大打个招呼，需求一旦确定后就不要轻易变更，这样工期也好控制。

    老王：行啊，没问题，我就等你的好消息了。

    时间：系统开发期 地点：项目组办公室

    小李[业务经理]：项经理，我们部门考核销售员拜访活动的规则做了调整，不但要考察拜访的过程和效果，还要跟具体的项目和客户挂钩，进行综合考察，所以之前咱们讨论过的功能需求也有些变化，你看大概需要多久能改完？

    小项：李经理，需求都已经定了，代码也开始写了，当初原型演示的时候你们也是同意了的，怎么说变就变？这个属于需求变更，按规定要项目管理委员会评审通过我们才能改，可能得延后交付日期，说不好要多久。

    小李：延后交付？那怎么行！上线日期都已经定了，怎么能说延就延？虽说需求我们确认过，可实际的业务发生变化，系统的功能要是不改就根本用不了，这个责任你能负吗？

    小项：我也没办法，反正需求变更的流程是这样规定的，要么不变，要变就得按流程走。

    小李：哼，行，我找我们老大去，就不信变不了！

    地点：经理办公室

    老王：小项，昨天小李他们老大过来找我，说那个拜访考核的变更很重要，直接影响上线后的使用，要不然你就先给他们改了再说，不然系统做出来也没法用，你说是不是？

    小项：老大，不是我不给他们改，确实是那个新考核规则太复杂，肯定会影响到项目进度的，再说，不是说要严格控制需求变更吗，如果这次不按规矩走，那以后……

    老王：哎，我也知道，这不也是没办法么，他们老大直接来找我，说要是不给改整个系统就没必要做下去了，这样的话咱们到老板那里也不好交待呀！

    小项：那变更流程还要不要走？

    老王：这个，你先把该改的改了，至于变更流程的文档什么的，事后补一补，做个记录就行了。

    小项：哦，那好吧。

    地点：项目组办公室

    小郑[QA]：项经理，系统功能里的很多功能点跟《需求库》里对不上啊，下礼拜的阶段评审可怎么做呀？

    小项：呃，小郑啊，这不是进度太赶还没来得及改么，要不这个周末我突击一下，把文档给你补齐咯？

    小郑：（叹气）项经理，文档可不是写给我的，还有，变更需求库之前是要作变更评审的，你连变更请求都没写，怎么能直接改呢？

    小项：唉，这不是没办法么，工期落后快2周了，我差点就焦头烂额了，哪还有工夫作那个什么什么评审的？

    小郑：可是，你不是说需求管理和变更的流程要严格执行吗？

    小项：咳，此一时彼一时嘛，要是有时间我能不写吗？

    小郑：那好吧，记得要在评审前补全……

    小项：知道啦。

    时间一天天过去，其间，销售部经历了一次组织架构调整，负责系统需求的小李被调去新的岗位，改由另一个业务经理接任。但是，这位新的业务经理和小李在许多问题上的看法都不太一样，尽管软件已经进入开发阶段，销售部提出的变更却越来越多。

    由于进度已经落后，小项已经没精力去做变更申请的评估，为了让系统尽快上线，他只好来一个改一个，修改完成后再抽点时间填个《变更实施记录表》了事。至于《需求说明书》也根本来不及更新，离系统实际的功能相差越来越远……

    经理老王也没闲着，他要顶住销售经理和老板的双重压力，拼命争取给项目宽限些时日。可是不管怎么努力，系统上线的日子依然遥遥无期。老王回过头责备小项，怪他没控制住需求，重蹈了过去的覆辙。小项也一肚子委屈，认为责任应归咎于需求管理流程的虚有其表，根本“管”不住蔓延的需求。

    两人各执一词，面对不断拖后的工期，一筹莫展。