您的位置:首页 > 其它

项目范围项目管理----项目范围管理

2013-05-20 20:07 260 查看
PS:今天上午,非常郁闷,有很多简单基本的问题搞得我有些迷茫,哎,代码几天不写就忘。目前又不当COO,还是得用心记代码哦!

一、项目范围管理基本知识

项目范围的管理也就是对项目应当包含什么和不应当包含什么进行定义和控制,以确保项目管理者和项目相干人对作为项目结果的项目产品和服务以及生产这些产品和服务所经历的过程有一个独特的懂得。也就是说,项目范围管理主要关心的是确定与控制哪些应当与不应当包含在项目之内的过程。

我们知道项目是为实现产品或服务所做的一次性尽力。因此在这里,范围的观点包含两方面,一个是产品范围,即产品或服务所包含的特征或功能,另一个是项目范围,即为交付拥有划定特征和功能的产品或服务所必须实现的任务。在确定范围时首先要确定终究产生的是什么,它拥有哪些可清晰界定的特性。要注意的是特性必需要清晰,以承认的形式表达出来,比如文字、图表或某种标准,能被项目介入人懂得,绝不能含含糊糊、模棱两可,在此基本之上才能进一步明白需要做什么任务才能产生所需要的产品。也就是说产品范围决定项目范围。

项目范围管理过程

范围规划(范围计划体例)——制定项目范围管理计划,记录如何确定、核实与控制项目范围,以及如何制定与定义任务分解结构(WBS)

范围定义——制定具体的项目范围说明书,作为未来项目决策的根据。

制造(创立)任务分解结构——将项目大的可交付结果与项目任务划分为较小和更易管理的组成部份。

范围核实(确认)——正式验收已实现的项目可交付结果。

范围控制——控制项目范围的变革。

上述过程不仅彼此之间互相作用,而且还与其他知识领域过程交互作用。根据项目需要,每个过程可能涉及一个或多个个人或集体所付出的尽力。每个过程在每个项目或在多阶段项目中的每一阶段至少涌现一次。



二、项目范围管理相关案例分析

项目标范围管理影响到信息系统项目标胜利。在实践中,“需求伸张”是信息系统失败最常见的原因之一,信息系统项目往往在项目启动、计划、执行、甚至扫尾时一直参加新功能,无论是客户的要求还是项目实现人员对新技术的实验,都可能致使信息系统项目范围的失控,从而使得信息系统项目无论在时间、资源和质量上都受到严峻影响。
案例类型:范围定义
阅读以下关于信息系统项目管理过程当中范围管理方面问题的叙说,回答问题1至问题3。
案例场景:
信管信息技术有限公司(CNITPM原本是一家专注于企业信息化的公司,在电子政务如火如茶的时候,开始进军电子政务行业。在电子政务的市场中,接到的第一个项目是开辟一套工商审批系统。由于电子政务保密要求,该系统涉及到两个互不联通的子网:政务内网和政务外网。政务内网中储存着全部信息,其中包含部份机密信息;政务外网可以对大众开放,开放的信息必须失掉授权。系统要求在这两个子网中的合法用户都可以访问到被授权的信息,访问的信息必须是分歧牢靠,政务内网的信息可以发布到政务外网,政务外网的信息在经过审批后可以进入政务内网系统。
张工是该项目标项目经理,在捕获到这个需求后认为电子政务建立与企业信息化有很大的不同,有其自身的特别性,若照搬企业信息化原有的经验和方案必定会遭到惨败。因此采用了严格瀑布模型,并专门招聘了熟悉网络互通互联的技术人员设计了解决方案,在经过严格评审后实行。在项目交付时,虽然系统完全满足了保密性的要求,但用户对系统用户界面提出了较大的异议,认为不符合政务信息系统的风格,操纵也不够便捷,要求完全更换。由于最初设计的缺陷,系统表示层和逻辑层严密耦合,致使70%的代码重写,而第二版的用户界面仍不能满足终究用户的要求,终究又重写的部份代码才通过验收。由于系统的反复变革,项目组成员产生了激烈的挫折感,士气低落,项目工期也超出原计划的100%。

【问题1】(10分)
请不超越300字,对张工的行为进行点评?
【问题2】(9分)
请从项目范围管理的角度找出该项目实行过程当中的主要管理问题?不超越200字回答。
【问题3】(6分)
请结合你本人现实项目经验,指出应如何防止类似问题?不超越200字回答。
案例分析:
这是一个失败的项目,张工在项目管理中既有闪光点,也有失败的地方。但项目管理中的任何差错都会影响项目标结果,而范围管理的失误对项目标影响更为显著。模糊的项目范围定义、错误的任务分解、缺失的范围确认和无力的范围控制都将严峻影响项目标结果。
张工对项目范围有必定的把握。在范围定义中,张工发现了不同行业间拥有不同的特色,电子政务行业对系统运行环境有着特别的要求。根据国度对电子政务的要求,政务内网与政务外网是该行业分歧的标准,这与企业信息化是完全不同的。张工捕获到该需求,并对这个需求进行了清晰的定义,根据瀑布模型的要求,对设计和实现都进行了严格的控制,因此在系统交付时完全满足了用户对保密性的要求。在这一点上,张工是胜利的。如果在范围定义时忽视了行业标准,项目肯定会导致更大的失败。
但用户界面的风格和操纵的便捷性也属于系统范围的一部份。与系统运行环境一样,我们平日称这类需求为隐性需求。这类需求往往不是由用户直接提出,而且受行业特色决定的范围所约束。对于电子政务来讲,系统保持分歧的风格非常重要。作为政府对大众开放的窗口而言,并不需要很强的个性化,但分歧的界面风格可以体现出政务的严肃性。斟酌到全体民众层次差异较大,大多数访问系统的用户一般都没有接受过系统应用的培训,操纵的便捷性也是政务系统必须实现的功能之一。很显著,对于这些系统的隐性需求张工没有充分斟酌,从而致使一而再,再而三的变革。
对于软件项目,所有的需求都必须经过清晰的定义,这些需求都是项目范围的一部份。张工仅仅注意了其中的一部份,而忽视了用户界面,终究致使项目标失败。
对于电子政务信息系统,尤其是面向大众开放的信息系统,范围定义更加困难。这些系统的终究用户几乎不会参加需求开辟的任务,他们的需求都是间接的,通过政府部门的负责人传递到项目组。但终究用户的意见对项目标结果会有巨大的影响,这是就对范围管理提出了更高的要求。
除了在范围定义方面的问题外,张工在范围确认和范围控制方面也存在不小的失误。当系统第一次更改时,就应当意想到系统界面风格和操纵便捷性的重要性。这时应当清晰地定义系统的界面风格和操纵风格,并想法进行确认。如果采用了适当的措施,第二次的变革是完全可以防止的。
在刚进入一个生疏领域的时候,其中充满了林林总总的风险。隐性的行规和行业特色都是项目范围的风险。面对这些风险,即使再过细的调研也没法完全防止,也不能完整定义系统的范围。因此可以斟酌采用原型法等方式来提前暴露风险,增加风险带来的损失。因此在案例中,张工也没有进行充分的风险管理,采用严格的瀑布模型增长了风险产生后带来的损失。
对于这个案例,缺乏良好的设计也是很显著的缺陷。用户界面中耦合了大量的业务逻辑,这必然增长变革的代价,从而致使大部份代码重写。若在项目初期意想到界面变革的风险,随之采用良好的设计,将表示层和业务逻辑完全离开,系统变革的代价也会小得多。
综上所述,项目经理张工在整个案例中,针对范围管理做了一些任务,但不全面,在风险管理和质量管理上也都存在缺陷。
有了下面的分析,这道题就很容易作答。项目标闪光点在于对系统运行环境进行了清晰的定义,并终究满足了用户的要求;但不充分的范围定义和范围 确认导致了项目标失败,而采用了抗风险能力较弱的瀑布模型和低质量的设计又雪上加霜,终究致使项目延期100%.
因此第一题答案的要点就很明白了:
(1)张工注意到了系统运行环境的特别性,在良好设计和实现的情况下满足了用户的要求。
(2)张工忽视了系统用户的潜在要求,在用户界面和操纵的风格上范围定义不清晰,构成系统交付的严峻变革。
(3)张工在第一次问题产生后仍没有对范围进行有效的管理,构成了系统第二次的变革。
(4)张工没有对用户界面是否能够满足要求的风险进行有效的管理,而是采用了对风险适应性较差的瀑布模型组织开辟。
(5)张工没有对设计质量进行有效的控制,构成表示层中耦合了业务逻辑,增长了修改的代价。
对于第二题,是在第一题的基本上考核对范围管理的懂得,因此可以忽视在其他领域的问题。在范围管理中主要包含如下内容:
(1)范围管理计划。
(2)范围定义。
(3)任务分解。
(4)范围确认。
(5)范围控制。
在本案例中,没有专门设计到范围管理计划和任务分解的内容。从表面上看,范围定义存在显著的缺陷。但案例中提到系统又产生了第二次变革,由此可见,张工在范围确认和范围控制上也存在缺乏。若在问题第一次涌现时就进行有效的范围确认和范围控制,则完全可以防止第二次的变革。因此,第二题的答案要点如下:
(1)张工没有挖掘到系统的全部隐性需求,缺乏精确的范围定义。
(2)在产生第一次变革时,张工仍没有有效的范围管理,从而构成系统的二次变革。
(3)重复的系统变革说明张工对系统范围控制缺乏,致使一而再再而三的反复。
在实现第二题后,第三题就是水到渠成了,第三题的要点见参考答案,此处不再赘述。
项目管理是一个系统工程,没有哪种单一的手段可以有效地改善项目,反之管理中的任何忽视都可能导致严峻的后果,构成项目标失败。而软件项目标庞杂性又决定了项目中的任务环环相扣,问题也总是互相关联的。在发现问题后,也需要采用多种手段才能完全解决问题。这对信息系统的项目经理来讲是严峻的挑战。
参考答案:
【问题1】(10分)
(1)张工注意到了系统运行环境的特别性,在良好设计和实现的情况下满足了用户的要求。(2分)
(2)张工忽视了系统用户的潜在要求,在用户界面和操纵的风格上范围定义不清晰,构成系统交付时的严峻变革。(2分)
(3)张工在第一次问题产生后仍没有对范围进行有效的管理,构成了系统第二次的变革。(2分)
(4)张工没有对用户界面是否能够满足要求的风险进行有效的管理,而是采用了对风险适应性较差的瀑布模型组织开辟。(2分)
(5)张工没有对设计质量进行有效的控制,构成表示层中耦合了业务逻辑,增长了修改的代价。(2分)

【问题2】(9分)
(1)张工没有挖掘到系统的全部隐性需求,缺乏精确的范围定义。(3分)
(2)在产生第一次变革时,张工仍没有有效的范围管理,从而构成系统的二次变革。(3分)
(3)重复的系统变革说明张工对系统范围控制缺乏,致使一而再再而三的反复。(3分)

【问题3】(6分)
有效的范围管理包含了从范围定义到范围控制等多方面的任务,每一项任务都是重要的。对于本案例,要结合行业特色进行需求分析,挖掘系统潜在的需求,同时通过原型等方法来帮助需求的定义,防止范围定义不清晰的问题。
在产生需求变革时需要进行有效的需求控制,尽量在满足用户需求的前提下缩小需求范围,坚定防止需求的再次变革。


每日一道理

翻开早已发黄的页张,试着寻找过去所留下的点点滴滴的足迹。多年前的好友似乎现在看来已变得生疏,匆忙之间,让这维持了多年的友谊变淡,找不出什么亲热感,只是偶尔遇上,淡淡地微笑,如今也只能在这发黄的页张中找寻过去的那些让人难忘的,至少我可以握住这仅剩下一段的“丝线头”……

三、项目范围管理论文

论信息系统项目范围管理

【择要】

2008年3月,我介入了“某某市行政权力网上公开透明运行”项目标建立,在项目中我非常幸运担负项目经理一职,该项目作为全省首批试点都会,受到省市相关领导的高度重视。该系统将政府的行政权力和服务类项目全部在网上公开透明运行,办事人员坐在家里通过互联网就可以方便地办结相关事项、查询收费标准、法律根据等,打造真正的“阳光政府、透明政府”。
本文结合作者的经验就项目管理进行详确的论述,以该项目为例分析项目标需求,范围定义以及范围管理实行过程当中采用的措施、方法,包含项目动员会、评审大会等等,最后列举了项目范围管理中存在的缺乏之处。

【正文】

为了提高政府任务的透明度和公信力,推动党风廉政建立和反腐败任务的展开,在省市领导的高度重视和支持下,“某某市行政权力网上公开透明运行”项目作为全省首初试点都会。该系统不仅涵盖了政府职能部门的行政权力事项,而且还根据需要增长了行政审批中心网上办事大厅的功能,依托电子政务内网和政府门户网站,对全市65个部门1300多条行政许可、行政征收、行政处罚、行政强制等行政权力和1800多条服务类项目通过外网受理、内网处置,外网反馈的形式进行全部在网上透明运行,取消本来纸质文件的流转,黑箱操纵的可能,坚定杜绝政府任务人员“吃拿卡要”现象,提高政府办事效率。该项目2008年3月启动,总投资380万元,要求2008年12月1日前全面完工并投入应用。
整个项目由行政权力阳光平台、电子监察平台、法制监视平台和网上办事大厅组成,以行政权力库为基本数据构成一库五平台。其中行政权力阳光平台、电子监控平台、法制监视平台和办事大厅部份功能基于Windows Server 2003操纵系统+SQL Server 2005数据库,采用.NET的开辟工具,B/S模式,业务任务流采用公司定制的任务流。外网受理反馈模块采用基于Linux操纵系统+Apache平台(客户为了节约资金),Linux平台最大优点就是投入少、安全性高。
由于涉及到的部门多,业务面广,时间紧,事项权力庞杂,一些症结职能部门领导的抵触情绪等原因,我们在省市政府的亲热关怀下,业主的通力配合与支持下,我与项目组全体同仁一起并肩作战,通过近9个月的尽力,终于在2009年11月20日前全面通过验收,比计划提前了10天。在此笔者就该项目采用的一些方法做简单的分析,望各位读者赐与批评指正。

一、 提前与销售经理介入项目,充分做好需求分析调研任务。

业务需求分析是准确确定范围的基本,为了保障业主需求分析的全面、准确,在向业主进行需求分析调研时,首先制定了需求制定计划,明白需求调研时间,业主参加人员,调研内容,实行人员;同时根据项目背景资料做好需求调研准备,当真做体例需求分析询问表,具体列出调研问题提要,防止在调研过程当中遗漏相关内容;在调研过程当中对业主人员进行启发和诱导,使业主有条理、系统地描述需求,在调研过程当中具体记录调研问题的答案。为何与销售经理提前介入,原因有二:1、防止销售经理对业主许诺过多的功能,增长项目标范围和难度;2、由于在业务调研阶段就已接触了业主的相关相干人,便于以后项目实行过程的相同任务。

二、 增强组织领导,召开全市行政权力网上公开透明运行项目动员大会

斟酌到项目涉及到的部门多,业务面广,事项权力庞杂,一些症结职能部门领导的抵触情绪等原因。在项目启动之初,通过与业主的主要负责人坦诚相同后,业主方面成立以常务副市长为首的某某市行政权力网上公开透明运行领导小组,在项目动员大会上,业主要求各单位安排主要负责同志和办公室联络人到会签约“项目义务状”。在这次会议上,我作为项目经理向各项目相干人,就项目标主要项目目标、项目范围、范围管理计划、进度计划安排、相同方式作了具体的分析,希望各项目相干人能够积极配合我们的任务,我们将尽量满足他们的要求,方便大家以后的应用。

三、 定义规划好项目范围,充分做好项目标范围管理任务

在实现项目需求分析设计后,我们通过与项目相干人多次相同后就项目所要达到的目标、项目需求、项目边界、项目标可交付物、产品接受标准、项目标约束条件、假设条件、项目组织结构、进度里程碑等一系列描述达成分歧意见,并构成书面的项目范围说明书。
另外我们还采用MS Project 2003作为项目管理工具。通过Project,我们建立了项目标WBS,对WBS的每个任务明白了其可交付物,对每一个任务我们都要求细化到每个人在一周内实现,保障每一项目都是可控的,可管理的。同时我们还制定了完善了项目范围管理计划、WBS字典、范围变革计划及规程,并交由业主、项目监理单位审核后,经业主具名确认保存构成项目范围基线。

四、 展开项目评审会,做好范围变革控制任务

我们在项目范围定义时确定好重要项目标里程碑。在每个里程碑结束后,我们邀请相关项目相干人介入项目标评审任务,目标是为了防止需求偏差、遗漏,以及搜集新的需求,每次评审都给我们带来不少好的建议,让我们充分发现系统中的缺乏之处,发现了诸多业务上的偏差。会后我们按照项目范围变革计划,与业主、监理单位一起对这些建议进行逐一评估,将那些有益于项目建立的归入范围管理中来,对有益于项目建立的建议分离处置对待:1、该建议实行起来比拟简单,投入成本比拟昂贵的、对项目实行进度影响不大的按照范围变革的程序进行实行,同时对实行的结果进行跟踪;2、对花费成本较高,对项目实行进度影响较大的建议则记录在案,留于下一版本开辟或作为附加项目开辟。

五、 落实项目小组义务,分离对待相干人的变革请求

在项目实行过程当中,由于项目小组成员和业主很多部门很多人有联系,他们是最经常会遇到范围更改请求的人,因此我们强调统一口径,不是任何人提出的请求都必须响应,必须经过项目发起人赞成的变革才可以响应,同时项目小组成员不得随便对项目标进行“镀金”变革。
另外我们还增强项目小组外部的相同和交流,提高项目开辟团队的开辟效率,增强质量措施的落实,对成员的职责和绩效进行考核,杜绝由于项目质量问题或技术问题引发的不必要的范围变革。

六、项目存在的缺乏与瞻望

项目实行胜利后,通过了省相关部门组织的验收,同时作为先进典型模式向
周边市区推广,该系统至今运行良好。但是回顾过去,系统实行过程当中也存在很多缺乏之处。
1、 后期调研虽然做了当真过细的部署但是还不够充分,如没有斟酌到
垂直系统部门的权力事项,没有斟酌到并联审批的情况等。在系统现实运行过程,没有斟酌到乡镇现实困难,很多多少部门的信息化普及远远跟不上,相关的任务人员应用起来比拟不熟练。
2、 测试的时间太短,没有专门的测试人员,没有全面而系统的测试,
所以系统交付之后,发现了不少问题,虽然没有威胁到系统的运行,但是作为项目经理,我觉得如果多给一些时间和人员,我做得更好。
在以后的任务中,我将继承尽力学习,总结经验和教育,为电子政务建立和企业信息化作出更多的贡献。

xn4545945搜集整理,部份资料来源于信管网。

文章结束给大家分享下程序员的一些笑话语录:

马云喜欢把自己包装成教主,张朝阳喜欢把自己包装成明星,李彦宏喜欢把自己包装成的很知性,丁磊喜欢把自己包装的有创意,李开复总摆出一副叫兽的样子。看来的。其实我想说,缺啥补啥,人之常情。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: