信息系统项目管理师--项目范围管理案例分析

         项目的范围管理影响到信息系统项目的成功。在实践中，“需求蔓延 ”是信息系统失败最常见的 原因之一，信息系统项目往往在项目启动、计划、执行、甚至收尾时不断加入新功能，无论是客户 的要求还是项目实现人员对新技术的试验，都可能导致信息系统项目范围的失控，从而使得信息系 统项目无论在时间、资源和质量上都受到严重影响。

2 ．1 案例一：范围定义

        阅读以下关于信息系统项目管理过程中范围管理方面问题的叙述，回答问题 1 至问题 3。

2.1.1 案例场景

希赛信息技术有限公司(CSAI  原本是一家专注于企业信息化的公司，在电子政务如火如茶的时 候，开始进军电子政务行业。在电子政务的市场中，接到的第一个项目是开发一套工商审批系统。 由于电子政务保密要求，该系统涉及到两个互不联通的子网：政务内网和政务外网。政务内网中储 存着全部信息，其中包括部分机密信息；政务外网可以对公众开放，开放的信息必须得到授权。系 统要求在这两个子网中的合法用户都可以访问到被授权的信息，访问的信息必须是一致可靠，政务 内网的信息可以发布到政务外网，政务外网的信息在经过审批后可以进入政务内网系统。

张工是该项目的项目经理，在捕获到这个需求后认为电子政务建设与企业信息化有很大的不同， 有其自身的特殊性，若照搬企业信息化原有的经验和方案必定会遭到惨败。因此采用了严格瀑布模 型，并专门招聘了熟悉网络互通互联的技术人员设计了解决方案，在经过严格评审后实施。在项目 交付时，虽然系统完全满足了保密性的要求，但用户对系统用户界面提出了较大的异议，认为不符 合政务信息系统的风格，操作也不够便捷，要求彻底更换。由于最初设计的缺陷，系统表现层和逻 辑层紧密耦合，导致 70％的代码重写，而第二版的用户界面仍不能满足最终用户的要求，最终又重 写的部分代码才通过验收。由于系统的反复变更，项目组成员产生了强烈的挫折感，士气低落，项 目工期也超出原计划的 100％。

【问题 1】(10 分)

请不超过 300 字，对张工的行为进行点评？ 【问题 2】(9 分)

请从项目范围管理的角度找出该项目实施过程中的主要管理问题？不超过 200 字回答。 【问题 3】(6 分)

请结合你本人实际项目经验，指出应如何避免类似问题？不超过 200 字回答。

2.1.2 案例分析

这是一个失败的项目，张工在项目管理中既有闪光点，也有失败的地方。但项目管理中的任何 差错都会影响项目的结果，而范围管理的失误对项目的影响更为明显。模糊的项目范围定义、错误 的工作分解、缺失的范围确认和无力的范围控制都将严重影响项目的结果。

张工对项目范围有一定的把握。在范围定义中，张工发现了不同行业间具有不同的特点，电子 政务行业对系统运行环境有着特殊的要求。根据国家对电子政务的要求，政务内网与政务外网是该 行业一致的标准，这与企业信息化是完全不同的。张工捕获到该需求，并对这个需求进行了清晰的 定义，根据瀑布模型的要求，对设计和实现都进行了严格的控制，因此在系统交付时完全满足了用 户对保密性的要求。在这一点上，张工是成功的。如果在范围定义时忽略了行业标准，项目肯定会 招致更大的失败。

但用户界面的风格和操作的便捷性也属于系统范围的一部分。与系统运行环境一样，我们通常 称这类需求为隐性需求。这类需求往往不是由用户直接提出，而且受行业特点决定的范围所约束。 对于电子政务来说，系统保持一致的风格非常重要。作为政府对公众开放的窗口而言，并不需要很 强的个性化，但一致的界面风格可以体现出政务的严肃性。考虑到全体民众层次差异较大，大多数 访问系统的用户一般都没有接受过系统使用的培训，操作的便捷性也是政务系统必须实现的功能之 一。很明显，对于这些系统的隐性需求张工没有充分考虑，从而导致一而再，再而三的变更。

对于软件项目，所有的需求都必须经过清晰的定义，这些需求都是项目范围的一部分。张工仅 仅注意了其中的一部分，而忽略了用户界面，最终导致项目的失败。

对于电子政务信息系统，尤其是面向公众开放的信息系统，范围定义更加困难。这些系统的最 终用户几乎不会参加需求开发的工作，他们的需求都是间接的，通过政府部门的负责人传递到项目 组。但最终用户的意见对项目的结果会有巨大的影响，这是就对范围管理提出了更高的要求。

除了在范围定义方面的问题外，张工在范围确认和范围控制方面也存在不小的失误。当系统第 一次更改时，就应该意识到系统界面风格和操作便捷性的重要性。这时应该清晰地定义系统的界面 风格和操作风格，并设法进行确认。如果采取了恰当的措施，第二次的变更是完全可以避免的。

在刚刚进入一个陌生领域的时候，其中充满了各种各样的风险。隐性的行规和行业特点都是项 目范围的风险。面对这些风险，即使再细致的调研也无法完全避免，也不能完整定义系统的范围。 因此可以考虑采取原型法等方式来提前暴露风险，减少风险带来的损失。因此在案例中，张工也没 有进行充分的风险管理，采用严格的瀑布模型增加了风险发生后带来的损失。

对于这个案例，缺乏良好的设计也是很明显的缺陷。用户界面中耦合了大量的业务逻辑，这必 然增加变更的代价，从而导致大部分代码重写。若在项目初期意识到界面变更的风险，随之采用良 好的设计，将表现层和业务逻辑彻底分开，系统变更的代价也会小得多。

综上所述，项目经理张工在整个案例中，针对范围管理做了一些工作，但不全面，在风险管理 和质量管理上也都存在缺陷。

有了上面的分析，这道题就很容易作答。项目的闪光点在于对系统运行环境进行了清晰的定义， 并最终满足了用户的要求；但不充分的范围定义和范围  确认招致了项目的失败，而采用了抗风险 能力较弱的瀑布模型和低质量的设计又雪上加霜，最终导致项目延期 100%.