| 知识下载 |
| IT项目范围管理案例剖析 |
M公司是一家致力于为电子政务市场提供应用系统开发的软件公司，最近接到一个开发一套向公众开放的政务信息发布与查询系统的项目。由于电子政务项目有一定的保密性要求，该系统涉及到两个互不相通的子网：政务内网和政务外网。系统要求在这两个子网中的合法用户都可以访问到被授权的信息，访问的信息必须是一致可靠的，政务内网的信息可以发布到政务外网，政务外网的信息经过审批后可以进入系统。
柳工是该项目的项目经理，在了解到系统要求后认为保密性是系统的难点，需要进行技术攻关。为了顺利的完成该项目，柳工找到了熟悉网络互通互联的技术人员设计了解决方案，在经过严格评审后实施。在系统完成开发，进入试运行前，项目发包方认为虽然系统完全满足了保密性的要求，但系统使用界面操作复杂，要求以增加向导的方式来简化操作，必须在交付前在系统中增加操作向导的功能。对于增加“操作向导”的问题，柳工安排程序员小陈向项目发包方口头了解“操作向导”的需求后，直接进行开发。但在操作向导功能交付后，项目发包方根据公众用户反馈的结果认为操作向导仍没有满足需求。最终又重写了大部分代码才通过验收。由于系统的反复变更，项目组成员产生了强烈的挫折感，士气低落，成本和工期都超出了原计划40%以上。
【案例剖析】
该项目的结果并不完美，柳工在项目管理中既有闪光点，也有失败的地方。项目管理中的任何差错都会影响项目的结果，而范围管理的失误对项目的影响更为明显。模糊的项目范围定义、错误的工作分解、缺失的范围确认和无力的范围控制都将严重影响项目的结果。
柳工对项目范围有一定的把握。在范围定义中，柳工捕获到电子政务行业对系统运行环境有着特殊的要求。根据国家对电子政务的要求，政务内网与政务外网是该行业一致的标准，这同企业信息化是完全不同的。柳工捕获了该需求，并对这个需求进行了清晰的定义，对设计和实现都进行了严格的控制，因此在系统交付时完全满足了用户对保密性的要求。在这一点上，柳工是成功的。如果在范围定义时忽略了行业标准，项目肯定会招致更大的失败。
但用户界面的风格和操作的便捷性也属于系统范围的一部分。同系统运行环境一样，通常称这类需求为隐性需求。这类需求不一定是由用户直接提出，即使提出也是相当模糊的。对于该系统来说，系统是面向公众开放的，系统的用户来自各行各业，大多不是专业的IT人员，这些人计算机操作能力较低且没有经过正式的系统使用培训。因此，一个界面的友好，操作简单的系统是非常必要的。很明显，对于这些系统的隐性需求柳工没有充分考虑，从而导致一而再，再而三的变更。
对于面向公众开放的系统，范围定义更加的困难。这些系统的最终用户几乎不会参与到项目中来，帮助项目组定义系统范围，他们的需求都是间接的、通过发包方传递到项目组。项目组最终得到的信息往往是混合了用户需求和传递者个人意愿的结果。这时，不但要注意仔细分析得到的信息，去伪存真，更重要的是要把分析的结果在各项目利害关系人中达成一致，让各方面对系统范围有着同样的理解和认识。否则，会出现仅能满足部分人需求的情况。例如，案例中，虽然开始阶段公众用户没有机会提出要求，但最终用户的意见对项目的结果还是会有影响的，这就对范围管理造成了更大的难度。
在案例中，当项目发包方提出异议，要求增加操作向导的功能时，柳工直接委派了一名程序员去了解需求并进行开发。在这个过程中，没有进行变更控制的工作，没有对范围变更请求进行评估与控制，这种做法也是不可取的。缺少正式的变更控制将造成项目时间和成本的超出、变更后的范围模糊等问题。案例中，程序员直接了解到的需求很难得到正式的确认，这也就是再次变更的原因之一。
综上所述，项目经理柳工在这个项目中，在范围定义和范围变更上都犯了一些错误，这些错误最终造成了项目时间和成本的超出。这些错误表现在以下两个方面：
（1）没有清晰地了解到产品的范围，导致项目后期需求的蔓延。
（2）没有进行变更控制，以至于变更的结果不理想，导致反复的变更。
[1] |
|
|
|
| 联系方式 |
|
咨询电话：18701378400 |
|
微信公众号：zpedu_nichuang |
|
问题邮箱：nichuang@zpedu.com |
|
公司地址：北京市丰台区育芳园东里三号楼二三四层 |
| |
|
