第2章项目范围管理案例
项目的范围管理影响到信息系统项目的成功。在实践中,“需求蔓延”是信息系统失败最常见的原因之一,信息系统项目往往在项目启动、计划、执行、甚至收尾时不断加入新功能,无论是客户的要求还是项目实现人员对新技术的试验,都可能导致信息系统项目范围的失控,从而使得信息系统项目无论在时间、资源和质量上都受到严重影响。
2.1案例一:范围定义
阅读以下关于信息系统项目管理过程中范围管理方面问题的叙述,回答问题1至问题3。
2.1.1案例场景
中培信息技术有限公司(Z公司原本是一家专注于企业信息化的公司,在电子政务如火如茶的时候,开始进军电子政务行业。在电子政务的市场中,接到的第一个项目是开发一套工商审批系统。由于电子政务保密要求,该系统涉及到两个互不联通的子网:政务内网和政务外网。政务内网中储存着全部信息,其中包括部分机密信息;政务外网可以对公众开放,开放的信息必须得到授权。系统要求在这两个子网中的合法用户都可以访问到被授权的信息,访问的信息必须是一致可靠,政务内网的信息可以发布到政务外网,政务外网的信息在经过审批后可以进入政务内网系统。
老王是该项目的项目经理,在捕获到这个需求后认为电子政务建设与企业信息化有很大的不同,有其自身的特殊性,若照搬企业信息化原有的经验和方案必定会遭到惨败。因此采用了严格瀑布模型,并专门招聘了熟悉网络互通互联的技术人员设计了解决方案,在经过严格评审后实施。在项目交付时,虽然系统完全满足了保密性的要求,但用户对系统用户界面提出了较大的异议,认为不符合政务信息系统的风格,操作也不够便捷,要求彻底更换。由于最初设计的缺陷,系统表现层和逻辑层紧密耦合,导致70%的代码重写,而第二版的用户界面仍不能满足最终用户的要求,最终又重写的部分代码才通过验收。由于系统的反复变更,项目组成员产生了强烈的挫折感,士气低落,项目工期也超出原计划的100%。
【问题1】(10分)
请不超过300字,对老王的行为进行点评?
【问题2】(9分)
请从项目范围管理的角度找出该项目实施过程中的主要管理问题?不超过200字回答。
【问题3】(6分)
请结合你本人实际项目经验,指出应如何避免类似问题?不超过200字回答。
2.1.2案例分析
这是一个失败的项目,老王在项目管理中既有闪光点,也有失败的地方。但项目管理中的任何差错都会影响项目的结果,而范围管理的失误对项目的影响更为明显。模糊的项目范围定义、错误的工作分解、缺失的范围确认和无力的范围控制都将严重影响项目的结果。
老王对项目范围有一定的把握。在范围定义中,老王发现了不同行业间具有不同的特点,电子政务行业对系统运行环境有着特殊的要求。根据国家对电子政务的要求,政务内网与政务外网是该行业一致的标准,这与企业信息化是完全不同的。老王捕获到该需求,并对这个需求进行了清晰的定义,根据瀑布模型的要求,对设计和实现都进行了严格的控制,因此在系统交付时完全满足了用户对保密性的要求。在这一点上,老王是成功的。如果在范围定义时忽略了行业标准,项目肯定会招致更大的失败。
但用户界面的风格和操作的便捷性也属于系统范围的一部分。与系统运行环境一样,我们通常称这类需求为隐性需求。这类需求往往不是由用户直接提出,而且受行业特点决定的范围所约束。对于电子政务来说,系统保持一致的风格非常重要。作为政府对公众开放的窗口而言,并不需要很强的个性化,但一致的界面风格可以体现出政务的严肃性。考虑到全体民众层次差异较大,大多数访问系统的用户一般都没有接受过系统使用的培训,操作的便捷性也是政务系统必须实现的功能之一。很明显,对于这些系统的隐性需求老王没有充分考虑,从而导致一而再,再而三的变更。
对于软件项目,所有的需求都必须经过清晰的定义,这些需求都是项目范围的一部分。老王仅仅注意了其中的一部分,而忽略了用户界面,最终导致项目的失败。
对于电子政务信息系统,尤其是面向公众开放的信息系统,范围定义更加困难。这些系统的最终用户几乎不会参加需求开发的工作,他们的需求都是间接的,通过政府部门的负责人传递到项目组。但最终用户的意见对项目的结果会有巨大的影响,这是就对范围管理提出了更高的要求。
除了在范围定义方面的问题外,老王在范围确认和范围控制方面也存在不小的失误。当系统第一次更改时,就应该意识到系统界面风格和操作便捷性的重要性。这时应该清晰地定义系统的界面风格和操作风格,并设法进行确认。如果采取了恰当的措施,第二次的变更是完全可以避免的。
在刚刚进入一个陌生领域的时候,其中充满了各种各样的风险。隐性的行规和行业特点都是项目范围的风险。面对这些风险,即使再细致的调研也无法完全避免,也不能完整定义系统的范围。因此可以考虑采取原型法等方式来提前暴露风险,减少风险带来的损失。因此在案例中,老王也没有进行充分的风险管理,采用严格的瀑布模型增加了风险发生后带来的损失。
对于这个案例,缺乏良好的设计也是很明显的缺陷。用户界面中耦合了大量的业务逻辑,这必然增加变更的代价,从而导致大部分代码重写。若在项目初期意识到界面变更的风险,随之采用良好的设计,将表现层和业务逻辑彻底分开,系统变更的代价也会小得多。
综上所述,项目经理老王在整个案例中,针对范围管理做了一些工作,但不全面,在风险管理和质量管理上也都存在缺陷。
有了上面的分析,这道题就很容易作答。项目的闪光点在于对系统运行环境进行了清晰的定义,并最终满足了用户的要求;但不充分的范围定义和范围 确认招致了项目的失败,而采用了抗风险能力较弱的瀑布模型和低质量的设计又雪上加霜,最终导致项目延期100%.
因此第一题答案的要点就很明确了:
(1)老王注意到了系统运行环境的特殊性,在良好设计和实现的情况下满足了用户的要求。
(2)老王忽略了系统用户的潜在要求,在用户界面和操作的风格上范围定义不清晰,造成系统交付的重大变更。
(3)老王在第一次问题发生后仍没有对范围进行有效的管理,造成了系统第二次的变更。
(4)老王没有对用户界面是否能够满足要求的风险进行有效的管理,而是采用了对风险适应性较差的瀑布模型组织开发。
(5)老王没有对设计质量进行有效的控制,造成表现层中耦合了业务逻辑,增加了修改的代价。
对于第二题,是在第一题的基础上考察对范围管理的理解,因此可以忽略在其他领域的问题。在范围管理中主要包括如下内容:
(1)范围管理计划。
(2)范围定义。
(3)工作分解。
(4)范围确认。
(5)范围控制。
在本案例中,没有专门设计到范围管理计划和工作分解的内容。从表面上看,范围定义存在明显的缺陷。但案例中提到系统又发生了第二次变更,由此可见,老王在范围确认和范围控制上也存在不足。若在问题第一次出现时就进行有效的范围确认和范围控制,则完全可以避免第二次的变更。因此,第二题的答案要点如下:
(1)老王没有挖掘到系统的全部隐性需求,缺乏精确的范围定义。
(2)在发生第一次变更时,老王仍没有有效的范围管理,从而造成系统的二次变更。
(3)重复的系统变更说明老王对系统范围控制不足,导致一而再再而三的反复。
在完成第二题后,第三题就是水到渠成了,第三题的要点见参考答案,此处不再赘述。
项目管理是一个系统工程,没有哪种单一的手段可以有效地改善项目,反之管理中的任何疏忽都可能招致严重的后果,造成项目的失败。而软件项目的复杂性又决定了项目中的工作环环相扣,问题也总是相互关联的。在发现问题后,也需要采取多种手段才能彻底解决问题。这对信息系统的项目经理来说是重大的挑战。
2.1.3参考答案
【问题1】(10分)
(1)老王注意到了系统运行环境的特殊性,在良好设计和实现的情况下满足了用户的要求。(2分)
(2)老王忽略了系统用户的潜在要求,在用户界面和操作的风格上范围定义不清晰,造成系统交付时的重大变更。(2分)
(3)老王在第一次问题发生后仍没有对范围进行有效的管理,造成了系统第二次的变更。(2分)
(4)老王没有对用户界面是否能够满足要求的风险进行有效的管理,而是采用了对风险适应性较差的瀑布模型组织开发。(2分)
(5)老王没有对设计质量进行有效的控制,造成表现层中耦合了业务逻辑,增加了修改的代价。(2分)
【问题2】(9分)
(1)老王没有挖掘到系统的全部隐性需求,缺乏精确的范围定义。(3分)
(2)在发生第一次变更时,老王仍没有有效的范围管理,从而造成系统的二次变更。(3分)
(3)重复的系统变更说明老王对系统范围控制不足,导致一而再再而三的反复。(3分)
【问题3】(6分)
有效的范围管理包括了从范围定义到范围控制等多方面的工作,每一项工作都是重要的。对于本案例,要结合行业特点进行需求分析,挖掘系统潜在的需求,同时通过原型等方法来辅助需求的定义,避免范围定义不清晰的问题。
在发生需求变更时需要进行有效的需求控制,尽量在满足用户需求的前提下缩小需求范围,坚决避免需求的再次变更。