范围管理案例分析
【案例分析】如何确定项目范围并进行WBS分解
【案例分析】如何确定项⽬范围并进⾏WBS分解今天写了⼀篇⽂章。
对于项⽬范围管理有了⼀些新的想法，特别是针对⽬前我们遇到的⼀些问题，我觉得有必要写出来跟⼤家⼀起分享，共同讨论讨论。
我想通过⼀个通俗的案例，来阐述我要说明的内容。
前⼏天，镇江的⼀个朋友给我打电话，让我帮他买台电脑，事成之后请我吃饭。
分析：分析：买台电脑，是客户合同中要求我去完成的最终⽬标。
请我吃饭，是给我的激励，有了这个激励才会驱动我去做这件事情。
我当时是相当兴奋啊，呵呵有⼈请我吃饭了，兴奋得过了头，什么都没有问，就把电话挂了。
分析：在实际⼯作中，我们经常会犯这种错误，⼀看到客户肯签单了。
就什么都不管，先把合同签了，实施⼈员甚⾄上来就分析：开始去实施了。
后来⼀想不对啊，他就说要电脑，到底要什么样的啊，什么牌⼦的？内存多⼤？硬盘多⼤?显⽰器多⼤？我都不知道啊，怎么给他买。
我赶紧问他，但是我问这些他不懂啊。
他是个电脑盲，只知道玩QQ，偷偷菜，不懂这些配置啊！分析：我们到这⼀步虽然已经意识到要去跟客户确认需求了，但是还不知道怎么去挖掘客户的需求。
分析：后来⼀想，算了这样问：你为什么买这台电脑啊？就是想上⽹偷偷菜，聊聊天吗？还是想看看电影，玩玩⽹游？（好像都是不务正业哦，呵呵）。
还有你想花多少钱啊？分析：我们要学会将⼀些专业的问题，转变成⽐较通俗易懂的问题去问客户。
还有就是在问客户问题时，要学会之前TRAR讲分析：的挖坑。
就是如果我们不能提供的产品或者服务，就千万不要去问他。
不然会死的很惨。
他很快对我上⾯的问题都做了⼀⼀回答，最终我知道，他买电脑其实就是为了上⽹聊聊天，看看⽹页，⽽且要求价格不能⾼于3000元。
我根据他的回答给出了这样的电脑配置：CPU：Intel E5400，kingstone 2GDDR800，WD 500G等等，报价：2980元。
我将这样的配置发MAIL给他确认，他回复我可以这样去做。
分析：到这⼀步，我们基本上已经确定了项⽬的范围。
案例分析：(定义+举例)制定项目范围管理
项目的范围管理作为一个合格的项目经理，切记要准确控制好项目范围。
孙子兵法中提到“知己知彼，百战不殆”，在一个项目中我们应该知道对方需要什么，自己要做什么，这是项目成功的基础所在。
做过项目的人可能都会有这样的经历：一个项目做了很久，感觉总是做不完，就像一个“无底洞”。
用户总是有新的需求要项目开发方来做,就像用户在“漫天要价”，而开发方在“就地还钱”。
实际上，这里涉及到一个“范围管理”的概念。
项目中哪些该做，哪些不该做，做到什么程度，都是由“范围管理”来决定的。
那么，到底什么是“范围管理”，请跟我们一块来揭开谜底。
几年前，我和一位同事在外地共同参与一个软件项目的开发。
项目本身并不算很大，开始的需求调研进行了很长时间，期间不但几乎拜访了所有部门，还与用户反复讨论，征求意见，需求文档几易其稿。
即便这样仍然有许多不确定因素，搞得人心烦意乱。
当时我牢骚很多，总觉得又花时间似乎还没真正做事。
我的同事经验比较丰富，他给我说了一个他自己的亲身经历。
那时候他在深圳参与一个证券项目，当时软件开发管理非常不规范，基本上是了解需求后就编程序，根本没有太多的交流，需求文档就更没有了。
系统开发出以后，用户不断提出新需求。
每天追着开发人员解决问题，项目实际是一个无底洞，没完没了地往下做，按他的说法是项目成员“肥的拖瘦，瘦的拖死”，实在做不下去只能跑了。
这个故事刚听起来感觉非常可笑，当我自己真正做项目负责人时才体会到这其实是一个项目范围管理的问题。
上面提到我所参与的项目中花费大量时间用于需求调研也是为了确定项目范围。
那么，首先要明确的是项目范围管理中的范围是如何定义的?1、什么是范围?我们知道项目是为完成产品或服务所做的一次性努力。
因此在这里，范围的概念包含两方面，一个是产品范围，即产品或服务所包含的特征或功能，另一个是项目范围，即为交付具有规定特征和功能的产品或服务所必须完成的工作。
在确定范围时首先要确定最终产生的是什么，它具有哪些可清晰界定的特性。
系统集成中级5道经典案例题
1.范围管理：小李是国内某知名IT公司的项目经理，负责西南某省的一个企业信息系统项目建设的管理。
在该项目合同中，简单列出了项目承建方应该完成的工作，据此小李自己制定了项目的范围说明书，甲方的有关工作由其信息中心组织和领导，信息中心主任兼任该项目的甲方经理。
可是在项目实施过程中，有时是甲方的财务部直接向小李提出变更需求，有时是甲方的销售部直接向小李提出变更需求，而且又是这些需求又是矛盾的，面对这些变更需求，小李试图用范围说明书来说服甲方，甲方却动辄用合同的响应条款作为依据，而这些条款要么太粗，不够明确，要么小李与他们理解不同，因此小李对这些变更需求不能简单的接受或拒绝而左右为难，他感到很沮丧，如果不改变这种状况，项目看来是遥遥无期。
问题一、针对上述情况，请分析问题产生的原因问题二、如果你是小李，你怎样在合同谈判、计划和执行阶段分别进行范围管理问题三、说明合同的作用，详细范围说明书的作用，以及两者之间的关系答：问题一：问题产生的原因：1、合同没有制定好，没有对具体完成的工作行程明确清晰的条款2、甲方没有对各部门的需求及其变更进行统一的组织和管理3、缺乏变更/拒绝的准则4、由于乙方对项目的干系人及其关系分析不到位，缺乏足够的信息来源，范围定义不全面，不准确5、甲乙双方对项目的只认可和承诺6、缺乏项目全生命周期的范围控制7、缺乏客户/用户参与问题二、在合同谈判、计划和执行阶段应该：合同谈判阶段1、确定明确的工作说明书或更细化的合同条款2、在合同中明确双方的权利和义务，尤其是关于变更问题3、采取措施，确保合同签约双方对合同的条款理解是一致的计划阶段1、编制项目范围说明书2、创建工作的分解结构3、制定项目的范围管理计划执行阶段1、在项目执行过程中加强对易分解的各项任务的跟踪和记录2、建立与项目干系人进行沟通的统一渠道3、建立整体变更控制的规程并执行4、加强对项目阶段性成果的审核确认项目全生命周期变更管理1、在项目管理体系中应该统一有一套严格、适用、高效、的变更程序2、规定对用户的范围申请变更请求、应正式提出变更申请，并经双方项目经理审核后，作出相应的处理问题三、合同的作用，详细范围说明书的作用，以及两者之间的关系合同法规定，合同是平等主体的自然人、法人、其他组织之间设立、变更、终止民事权利义务关系的协议。
项目范围管理案例
项目范围管理案例项目范围管理是项目管理中至关重要的一环，它确定了项目的边界和内容，确保项目在规定的范围内完成。
在实际项目中，范围管理的重要性不言而喻。
下面我们以一个实际案例来说明项目范围管理的重要性以及如何有效地进行范围管理。
案例背景：某公司决定开发一款新的移动应用程序，以满足市场对移动支付的需求。
该项目的目标是在一年内完成应用程序的开发，并在市场上推出。
项目团队包括开发人员、设计人员、市场营销人员等。
范围管理的重要性：在项目启动阶段，项目团队需要明确项目的范围，即确定应用程序的功能、特性和所覆盖的市场范围。
如果范围没有清晰界定，项目可能会面临需求不清晰、进度延误、成本超支等问题。
因此，范围管理对于项目的成功至关重要。
范围管理的实施：为了有效地进行范围管理，项目团队首先召开了范围定义会议，与利益相关者一起明确应用程序的功能和特性。
在会议上，团队与利益相关者充分沟通，确保所有需求都被纳入范围内，并且明确了哪些需求是不在范围内的。
接下来，项目团队制定了范围说明书，详细描述了应用程序的功能和特性，以及不在范围内的需求。
范围说明书被提交给利益相关者进行确认，确保所有人对项目的范围有清晰的认识。
在项目执行阶段，项目团队不断与利益相关者进行沟通，及时处理变更请求。
通过严格的变更控制程序，确保任何变更都是经过充分讨论和评估的，避免范围蔓延和项目目标的不清晰。
范围管理的成果：通过有效的范围管理，项目团队成功地完成了应用程序的开发，并在预定的时间内推出市场。
应用程序的功能和特性得到了充分满足，而且没有出现额外的需求蔓延。
项目的进度得到了有效控制，成本也得到了有效管理。
结论：范围管理是项目管理中至关重要的一环，它直接影响项目的成功与否。
通过本案例的分析，我们可以看到，有效的范围管理可以帮助项目团队明确项目目标，避免范围蔓延和需求不清晰的问题，最终实现项目的成功。
在实际项目中，我们应该充分重视范围管理，与利益相关者充分沟通，明确项目的范围，制定范围说明书，并严格控制变更。
软件项目管理案例分析之范围管理(课堂PPT)
2020/4/23
解决方案一
与用户高层的沟通，加强对用户领导及业务骨干的培 训，使其了解ERP系统开发的要求和流程，使相关人 员重视、参与、支持这项工作；
完善组织机构，由用户的业务骨干以适当形式参加项 目工作，明确其职权，使其在范围界定、需求确认方 面有一定的权威性，与项目团队共同弥补前期工作的 不足;
5. 根据三方会议甲方定下来的最迟上线时间，估算项目本期最多能够完成哪些需求。
评估剩余需求是否可以有足够的费用来采用加班加人完成。若不能完成，则需要再
次真诚的与甲方主管领导沟通，希望能够采用二期方式，或者上线之后（验收之前）
增加投资的方式来完成项目。
4
2020/4/23
案例二
陈嘉恒为某系统集成公司项目经理，负责某国有企业信息化项目的 建设。
3. 找甲方主管领导沟通，明确自己本次来的目的是为了改善项目实施，简要的汇报 当前问题，希望得到支持。找甲方领导申请召开三方会议。明确甲方、乙方和监理 方的相关人员，主管领导要到场。
4. 三方会议，明确以下几个内容： 4.1 建立变更控制委员会，制定变更控制流程； 4.2 建立沟通机制，尤其是重要的项目干系人。例如，每周除项目组例会之外，邮件 抄送项目进展情况给各位重要项目干系人，定期给甲方领导汇报； 4.3 明确项目范围； 4.4 展示项目组前期成果，给出项目组整理好的带有工时估算的需求清单。明确原则 上不再接受新增需求，有重要新增需求走项目变更流程。现有存在疑问的需求，由 项目组组织专题调研会议，形成统一的思想，定下来之后，若又有不同的声音，则 走项目变更流程； 4.4 甲方需明确能承受的上线时间点； 4.5 会后出会议纪要，发送给各位与会人员。
信息系统项目管理师案例分析考点：范围管理实施过程中存在的问题
信息系统项目管理师案例分析考点：范围管理实施过程中存在的问题1. 没有制定范围管理计划并按照计划管理，或领导的部署不能代替范围管理计划。
2. 需求阶段结束后未对需求进行正式评审或项目的范围未得到客户的确认，或领导的批准不能代替范围确认。
3. 范围的定义和分解时未包含分包出去的工作，或分包出去的工作未纳入范围管理计划进行管理。
4. 对领导提出的变更要求未形成书面记录。
5. 领导提出变更要求后，未对变更产生的影响进行充分的评估便实施了变更。
6. 变更请求应由变更控制委员会审批，不应由项目经理独自决定。
7. 项目经理缺乏和领导以外的公司其他用户的沟通。
8、没有区分(混淆)项目产品范围和项目工作范围。
9、WBS制定应该由所有干系人共同完成和一数确认，而非项目经理一人完成。
10、没有进行范围核实;在核实之前没有进行质量控制工作(测试、评审等)。
11、项目范围基准未经评审和审批/缺少正式的确认范围工作。
12、项目范围说明书不应由项目经理一人编写，需要相关人员参与。
相关试题：结合案例，请从项目范围管理的角度指出该项目实施过程中存在的问题。
试题来源：2020年下半年信息系统项目管理师案例分析真题第一大题问题1。
阅读下列说明，回答问题1至问题4,将解答填入答题纸的对应栏内。
[说明]信管网集成公司和某地区的燃气公司签订了系统升级合同，将原有的终端抄表系统升级改造，实现远程自动抄表且提供APP终端应用服务。
公司指定原系统的项目经理张工来负责该项目，目前张工已经升任新产品研发部经理。
张工调派了原项目团队的核心骨干刘工和李工分别负责新项目的需求调研和开发工作。
刘工和李工带领团队根据以往经验完成了需求调研和范围说明书。
但由于该项目甲方负责人负责多个项目，时间紧张，导致需求评审会无法召开。
张工考虑到双方已经有合作基础，李工和刘工对原系统非常熟悉，为了不影响进度，张工让项目组采用敏捷开发模式，直接进入了设计和编码阶段。
在客户验收测试时，甲方负责人提出APP的UI设计不符合公司风格、不兼容新燃气表的数据接口、数据传输加密算法不符合要求等多项问题，要求必须全部实现这些需求后才能验收。
项目范围管理案例
案例1：小李是国内某知名IT企业的项目经理，负责西南某省的一个企业管理信息系统建设项目的管理。
在该项目合同中，简单地列出了几条项目承建方应完成的工作，据此小李自己制订了项目的范围说明书。
甲方的有关工作由其信息中心组织和领导，信息中心主任兼任该项目的甲方经理。
可是在项目实施过程中，有时是甲方的财务部直接向小李提出变更要求，有时是甲方的销售部直接向小李提出变更要求，而且有时这些要求是相互矛盾的。
面对这些变更要求，小李试图用范围说明书来说服甲方，甲方却动辄引用合同的相应条款作为依据，而这些条款要么太粗、不够明确，要么小李跟他们有不同的理解。
因此小李对这些变更要求不能简单地接受或拒绝而左右为难，他感到很沮丧。
如果不改变这种状况，项目完成看来要遥遥无期。
问题：1、该问题产生的原因是什么？如何解决？2、如果你是小李，你怎样在合同谈判、计划和执行阶段分别进行范围管理？产生问题的原因：1．是因为项目的范围确定，一定要关键用户的参与，并且达成一致才可以的，这样才能避免许多无意义的需求提出。
2．项目团队的建立，一定要把关键部门的领导纳入团队，这样才能在前期明确需求，减少后期的需求变更。
3．项目经理最好是业务经理，信息中心主任无法对具体的业务进行整体分析。
4．变更是一定会产生的，但是变更的流程一定要确定下来，组成专门的变更评估小组，对各个变更进行整体的分析，就会避免前后矛盾的变更了。
5．变更发生分歧的时候，要注意沟通，不能简单的认为范围中没有，就不在工作范围之内，这样只会造成客户的逆反心理！一定要和客户详细说明，如果变更会造成那些问题，投入要多少，需要多少时间等等。
这样客户才会接受不变更的理由。
解决方法：合同谈判1．在谈合同的时候，对合同的目标，预算，时间，范围，组织有明确的说明。
2．有明确的绩效标准，明确的交付物规定。
3．在项目计划和项目执行的阶段，不断完善合同的条款。
项目计划1．组建项目团队，选择企业的实权人物，作为项目经理，把关键用户的领导纳入团队。
3项目范围管理60页PPT
深圳海王集团从中获得灵感，他们经过一番策划，
在全国范围推出了“拥有一片故土”大型旅游工程。
合肥工业大学管理学院
Management School Hefei University of Technology
3
项目管理一知识、案例：苦涩的“故土工程”
2. 项目论证与启动
“故土工程”是一项具有重要世界影响的集社会、经济、 文化、旅游等要素为一体的大型综合工程，可行性如下：
项目范围与产品范围的关系
–项目范围的定义以其组成的所有产品范围定义为基
础，但又不限于产品范围，还包括为实现这些产品
范围内的工作必须要做的管理工作（进度管理等）。
–衡量标准：产品范围的完成对照产品要求；项目范
围的完成对照项目计划
–可能一个产品的范围很大，我们只是将其中的一小
部分作为项目，这时，项目范围与产品范围就是交
由国家有关职能部门联合主办，具有很高的权威性， 给营销活动增加了可信度，容易吸引海内外人士参加。
购买证书的目的动机有：怀乡寄情、馈赠礼品、收藏
纪念、谋取优惠、千古留名、增值保值、地位炫耀、
不动产业、追求猎奇、炒卖获利等。 合肥工业大学管理学院
Management School Hefei University of Technology
项目管理知识
项目范围管理
蒋翠清 二零零七年
合肥工业大学管理学院
Management School Hefei University of Technology
1
项目管理知识
内容提纲
1. 一个案例 2. 项目范围管理相关概念 3. 项目范围管理
2.1 启动 2.2 范围计划 2.3 范围定义 2.4 范围核实 2.5 范围变更控制
项目管理案例系列-关于范围管理方面的案例及分析
项目管理案例系列-关于范围管理方面的案例及分析1．如何正确接手并完成一个“半截”的项目2．这样可以索赔吗？3．如何控制好客户的变更需求4．产品性能达不到用户期望，项目是否应继续？5．项目达到了质量目标，但用户的质量调查结果却很差6．如何控制项目的范围？7．客户需求不清楚引来的麻烦1．如何正确接手并完成一个“半截”的项目案例正文：A是一个新任命不久的IT公司项目经理，被给部门经理B派去接手一个已经接近完成的项目，原来的项目经理C于公司安排已经调到其他项目中了，部门经理B表明，目前项目状况是大部分功能已经开发完成，单元测试和集成测试已经完成，尚有少部分模块因为用户新提出的需求需要进行重新开发。
A按照部门经理的介绍，重点针对需要修改的模块制定了一个较为明确的项目计划，在不修改其它模块的基础上只需要30天就可以完成项目，并提交给了部门经理B。
但是接手不久后，A发现事实远不像项目经理B说的那样，除了明确要修改的模块以外，由于原来的测试人员水平和负责态度很差，其他模块其实存在大量的问题，整个项目模块都需要修改，而且由于原来的项目经理水平有限，没有留下什么文档，A 和项目组其他成员只能按照销售经理的口头需求和以前的程序来一点点的修改所有的程序，项目的范围变大了很多，A找部门经理B说明了情况，B才发现他也被原来的项目经理C欺骗了，相应的给A增加了一些资源，但是A认为现有的资源还是不足以按时完成项目，而且目前和当时部门经理B的许诺差距太大，所以产生了一定的情绪。
项目由于范围扩大，而且期间又有客户的新需求，所以延期了一个月的时间才完成。
事后A被公司的CEO找去，批评他缺乏预见风险的能力以及项目延期的事情，A认为部门经理B当初没有了解清楚项目状况并相应的误导了他，而且项目的范围扩大了很多，延期一个月完成已经是不错了。
A是部门经理B的替罪羊。
这个案例中的A遇到的问题在IT界非常典型，接手半截的项目是普遍的谈虎色变的事情，请问几个人都犯了什么错误，A应该如何做才能做好一个“半截”的项目并得到领导的承认呢?分析一：如何正确接手并完成一个“半截”的项目 (ming0066316@) 所有人都认为计划是一个项目的灵魂，可很少有人在项目开始或执行过程中认真的制定一个象样的计划。
《项目范围管理》工作分解结构案例 2
河北省企W业B创S新职图业资格培训中心
练习：分析项目WBS
假定你要准备一次隆重的生日晚宴，招待重要的客人，筹备家宴的主要活 动步骤有：
准备 邀请来宾、采购物品 晚宴 生日蛋糕、饮料、清洗、食品、餐具 做菜 凉菜、熟菜、蔬菜类、海鲜类、其它类 娱乐
音响、灯光布置、室内布置、CD/VCD光碟 晚餐清理 送客、打扫卫生、洗碗 请分析这一生日晚宴项目按产品导向和活动导向的WBS。 （细节可以按个人的生活常识进行补充）
3.3室内布置
3.4CD/VCD光碟
河北省企业创新职业资格培训中心
生日晚会
生日宴会WBS 10000
准备 11000
晚宴 12000
娱乐 13000
邀请来宾 采购食品 生日蛋糕 饮料 11100 11200 12100 12200
清洗 12300
做菜
音响 灯光布置 室内布置 VCD光碟
12400 13100 13200 13300 13400
成立婚礼筹备组 115
与婚礼所有干系人沟通 121 结婚物品采购 122 新郎新娘形象准备 123 拍婚纱照 124 布置新房 125 确定婚礼主持人 126 婚宴预约 127 婚礼化装预约 128 婚庆车辆预约 129 婚庆摄像预约 12A
其他 12B
再次与婚礼所有项 目干系人沟通 131
确认婚礼当天发言 人准备情况 132
隧道开挖 121
隧道开挖 131
大桥工程 141
土方工程1 151
工程收尾 161
工料机进场 112
隧道砼工程 122
隧道砼工程 132
中桥工程1 142
土方工程2 152
工程验收 162
技术准备 113
第4章 项目范围管理
4.1 项目范围管理概述
4.1.1 项目范围的含义 项目范围是指为了成功达到项目的目标， 所必须完成的工作，是关于项目工作内容和 期望产出的所有信息。 “范围”既可以指项目的“产品范围”， 即项目业主/客户对于项目最终产品或服务所 要求达到的特色和功能，也可以指项目“工 作范围”，即项目团队或承包商为提交项目 业主/客户指定的服务和作业所需完成的所有 工作。
4.2.1 项目范围说明书
1. 项目范围说明书的内容 （1）项目合理性说明 （2）项目目标 （3）项目可交付成果 2. 项目范围说明书的作用 （1）形成项目的基本框架 （2）产生项目有关文件格式的注释 （3）形成项目结果核对清单 （4）作为项目整个寿命周期中监督和评价项 目实施情况的背景文件
4.2.1 项目范围说明书
案例分析 面对客户的需求变更
项目一直没有结项，项目中出现以下问题： (1)频繁的需求变更。 (2)客户的工作效率低。在项目实施过程中， 严重单方面拖延实施进度，使项目不能按计划 结项，造成项目延期。 (3)客户同A公司关系特别密切，不能完全 按照合同进展，对合同规定的阶段验收不予回 应，这些问题需要公司老总出面才能协调，项 目经理控制协调明显乏力。
案例分析 面对客户的需求变更
A信息技术有限公司是某市一家大型股份制软 件企业，公司研发人员达到200人，主要从事电子 政务应用系统和金融信息系统等方面的研发。 A 公司具有较强的政府背景，公司副总经理兼技术 总监张工原为该市政府信息中心总工程师。目前 A 公司正在进行该市某政府机关的办公自动化系 统研发，系统主要由公文管理、档案管理、公共 信息、会议管理、领导办公、电子邮件、个人办 公、业务管理、事务预警系统管理等子系统组成。 由于 A 公司具有较好的技术和产品积累，整个系 统于 3 个月前按进度计划开发完成，所用工期 5个 月，目前系统处于工单位通过投标方式获得了该项工 程施工任务，并与建设单位签订了固定总 价合同。然而，施工单位在开挖基坑时发 现，相当一部分基础开挖深度虽已达到设 计标高，但仍未见老土，且在基坑和场地 范围内仍有一部分深层的耕植土和池塘淤 泥等必须清除。
【推荐下载】关于范围确认的分析案例
[键入文字]关于范围确认的分析案例下面是一篇范围确认的分析案例，希赛信息技术有限公司(CSAI )刚刚和M签订了一份新的合同，合同的主要内容是处理公司以前为M公司开发的信息系统的升级工作。
关于范围确认的分析案例 希赛信息技术有限公司(CSAI )刚刚和M签订了一份新的合同，合同的主要内容是处理公司以前为M公司开发的信息系统的升级工作。
升级后的系统可以满足M公司新的业务流程和范围。
由于是一个现有系统的升级，项目经理张工特意请来了原系统的需求调研人员李工担任该项目的需求调研负责人。
在李工的帮助下，很快地完成了需求开发的工作并进入设计与编码。
由于M公司的业务非常繁忙，M公司的业务代表没有足够的时间投入到项目中，确认需求的工作一拖再拖。
张工认为，双方已经建立了密切的合作关系，李工也参加了原系统的需求开发，对业务的系统比较熟悉，因此定义的需求是清晰的。
故张工并没有催促业务代表在需求说明书中签字。
进入编码阶段后，李工因故移民加拿大，需要离开项目组。
张工考虑到系统需求已经定义，项目已经进入编码期，李工的离职虽然会对项目造成一定的影响，但影响较小，因此很快办理好了李工的离职手续。
在系统交付的时候，M公司的业务代表认为已经提出的需求很多没有实现，实现的需求也有很多不能满足业务的要求，必须全部实现这些需求后才能验收。
此时李工已经不在项目组，没有人能够清晰地解释需求说明书。
最终系统需求发生重大变更，项目延期超过50%, M的业务代表也因为系统的延期表示了强烈的不满。
【问题1】(8分) 请以400字对张工在项目管理工作中的行为进行点评。
【问题2】(9分)1。
第三章 项目范围管理
最前端的过程。它是联接市场和企业的一个桥梁。
了解市场需求
使产品（项目）成功的一种高层次的投资。
市场大小
取决于特定需要的顾客的总量。
1.识别需求
需求的产生
公共需求与公共项目 个体需求与个体项目
识别需求或需求识别
起始于需求、问题或机会的产生 结束于需求建议书 的发布 清晰的需求是承约商规划与实施项目的基础
第三章 项目范围 管理
ABC项目管理与控制案例
尽管李在ABC项目构思之时，就以一助理项目经理的 身份参加了项目，并在公司接受该项目时被任命为项目经 理，但李的日子一直不好过，因为ABC项目一直处于失控 状态。从实施第1天开始就超出计划日程，费用也超支。 李发现职能部门经理把应分给他项目的资源用在她们自己 “喜爱”的其他项目上。李因此而抱怨职能部门，但得到 的是不要干预职能部门经理分配资源和预算的警告。大约 6个月后，李被要求向公司经理和职能部门经理做一进度 报告。 李利用这次机会大发牢骚。李在报告中用大量的事实 数据，分析和预测ABC项目将比计划进度滞后整整1年时 间方能完成项目。李不满职能经理派来的工作下属，认为 他们工作节奏太慢，不合适该项目的快节奏要求。李报告 2 项目目前实际开支已超出预算20%。
由于李对项目的充分认识和坦率评价，使对ABC项目 不信任者看到了一线希望，职能部门经理也意识到他们在 完成ABC项目上要起作用。由于大多数问题已经清楚，可 以通过提供足够的人员和资源来解决问题。公司决定立即 采取补救行动来支持李拯救ABC项目。 而事情的进行远不像李所想象的那样。之后，李不再 向项目办公室报告，而是直接向经营经理报告。公司对该 项目的兴趣变得非常强烈，要求他每星期一早上7：00召 开会议检查项目的情况和追赶进度。李发现自己花了更多 时间在文字处理、报告和为每星期一早上的会议准备工作 而不是在ABC项目的决策与控制上。对于ABC项目，公司 关心的是使计划回到原日程安排表上。李花了许多时间在 复苏计划和建立人力资源上。 为了能紧密的跟踪ABC项目的进展状态，项目安排了1 3 名程序经理助理。该助理认定ABC项目要想恢复原计划，
第四章 项目范围管理
4 项目工作的分解
工作分解结构步骤
确定项目 确定任务 确定活动 确定子活动 修改完善
1、我们来干什么 2、都需要我们做什么 3、每项任务如何做 4、怎样才能完成 5、分解是否正确和完善
4 项目工作的分解
工作分割原则
• 可以将项目生命周期的各个阶段做为第一层，将每个阶段的交付物 做为第二层。如果有的交付物组成复杂，则将交付物的组成元素放 在第三层 • 分解时要考虑项目管理本身也是工作范围的一部分，可以单独做为 一个细目 • 确保能把完成每个底层工作包的职责明确地赋予一个成员、一组成 员或者一个组织单元，同时考虑尽量使一个工作细目容易让具有相 同技能的一类人承担 • 确保能够进行进度和成本估算 • 根据80小时的原则，工作包的时间跨度不要超过80个小时，否则会 给项目控制带来一些困难；同时控制的粒度不能太细，否则往往会 影响项目成员的积极性 • 工作分割应时时考虑到客户的需求，避免超出项目范围 • 切记于工作分割 之过程中，需考虑每一个项目的目标皆已被涵盖， 切勿遗漏
项 目 群
项 目 任 务 活 动
工 作 包
工作包（work package）是WBS的最底层 元素，一般的工作包是最小的“可交付成 果”，这些可交付成果很容易识别出完成 它的活动、成本和组织以及资源信息。
4 项目工作的分解
新款轿车开发 项目群
发动机设计
车身设计
底盘设计
项目
缸体设计
润滑系统设计
冷却系统设计
如果教师授课、同学 考研以及婚礼活动等 缺乏范围管理，后果 会如何？
1 项目范围管理的概述
项目范围管理的含义
项目范围管理是为确保项目成功而开展的对于 项目起始、项目目标、项目产出物范围和项目 工作范围的项目专项管理工作。
项目范围管理案例
第3章项目范围管理案例案例1：面对项目范围管理上出现的混乱局面，刘工应该如何处理？某软件公司承担了A公司的一个ERP系统开发项目，在项目的实施过程中，系统需求似乎永远无法确定，用户说不清楚自己的需求，怎么做他们都不满意，功能不断增加，用户上周说要这个功能，今天说要这个功能，李部长认为这个功能该这样做，而王经理认为这样不行，结果让软件开发人员无所适从。
该项目已经进行了两年多，项目何时结束还是处于不明确的状态，因为用户不断有新的需求提出来，项目组也就要根据用户的新需求不断去开发新的功能。
大家对这样的项目完全丧失了信心。
公司针对目前出现的局面，派出项目管理专家刘工负责ERP项目组的管理工作。
刘工通过对项目文档分析和A公司相关人员的沟通认识到，这个项目一开始就没有明确界定整个项目的范围，在范围没有明确的情况下，又没有一套完善的变更控制管理流程，任由用户怎么说就怎么做，也就是说，一开始游戏规则就没有定好，从而导致整个项目成了一个烂摊子。
面对项目在范围管理上出现的混乱局面，刘工应该如何处理呢?案例2：如何控制项目的范围？某公司与某省厅签定了该省十几个县的应用软件与相关系统集成的的合同。
合同规定以招标技术说明书的最佳方案验收。
而招标技术说明书是从另一公司的模式抄写的，详细到实现某些功能的方式。
该公司系统能实现其绝大部分功能，但部分方法与技术说明书有区别。
该公司投标书基本照抄招标技术说明书。
且某些功能合同设备清单中没有实现该功能的设备。
假如该公司请你做该项目的项目经理，你将用什么方法控制项目的范围才能成功实施该项目呢？案例3：公司A是拥有较好政府背景的股份制企业，机制比较灵活，该公司运作的项目是政府机关的一个MIS系统。
现在整个开发全部完成，系统已经试运行2个月左右，运行情况比较顺利，但是，目前有几个比较大的问题如下：1. 客户同该公司关系特别密切(毕竟客户是机关)，不能完全按照合同进展。
2. 政府的工作节奏比较慢，在项目实施进程中，严重单方面拖延实施进度，造成项目延期。
项目范围管理案例
项目范围管理案例在项目管理中，范围管理是至关重要的一环。
它涉及确定项目的目标、任务和可交付成果，以及确保这些目标得到满足。
范围管理的不善会导致项目目标不明确，任务范围不清晰，最终导致项目延期、超支或者无法交付符合客户需求的成果。
因此，范围管理在项目管理中具有极其重要的地位。
下面，我们以某公司开发一个新的软件系统为例，来说明项目范围管理的重要性。
首先，项目范围管理需要明确定义项目的目标和可交付成果。
在这个案例中，公司决定开发一个新的软件系统，以提高内部员工的工作效率。
在项目启动阶段，项目团队与相关部门进行了充分沟通，明确了软件系统需要实现的功能和特性，以及最终要达到的目标。
这些明确定义的目标和可交付成果为项目后续的实施和监控提供了清晰的方向。
其次，范围管理需要有效地进行范围规划和范围定义。
在软件系统开发项目中，项目团队需要对系统的功能模块进行详细的规划和定义，确定哪些功能是必须实现的，哪些是可选的，以及哪些是不在项目范围内的。
这样的范围规划和定义能够帮助项目团队避免范围蔓延和功能膨胀，确保项目能够按时交付符合客户需求的软件系统。
再次，范围管理需要进行范围确认和控制。
在软件系统开发项目中，项目团队需要与客户和最终用户进行频繁的沟通和确认，确保他们对系统功能和特性的理解是一致的，避免出现需求偏差和误解。
同时，项目团队还需要对项目范围进行有效的控制，及时处理变更请求和范围蔓延的情况，确保项目能够按时交付，并且交付的软件系统符合客户的期望。
最后，范围管理需要进行范围的总结和验收。
在软件系统开发项目中，项目团队需要对项目的可交付成果进行全面的验收，确保系统的功能和特性都得到了满足。
同时，项目团队还需要对项目的过程进行总结，分析项目范围管理的优缺点，为后续的项目提供经验教训和借鉴。
综上所述，项目范围管理在项目管理中具有非常重要的地位。
它能够帮助项目团队明确项目目标和可交付成果，规划和定义项目范围，确认和控制项目范围，以及最终对项目范围进行总结和验收。
范围管理计划案例
范围管理计划案例范围管理计划是项目管理中的重要组成部分，旨在确保项目范围的定义、确认和控制。
下面是一个范围管理计划案例，展示了如何制定一个有效的范围管理计划。
一、引言范围管理计划是项目管理中的一个关键计划，它旨在确保项目在预定的范围内完成，并避免范围蔓延和项目目标的失控。
本计划将详细说明项目的范围管理过程，包括范围定义、范围确认和范围控制。
二、项目范围定义1. 建立项目范围说明书：明确项目的目标、可交付成果和排除范围，以及相关的约束和假设条件。
2. 确定项目的关键利益相关方：识别并明确各利益相关方的需求和期望，以便在范围定义过程中进行合理的权衡和决策。
3. 制定工作分解结构（WBS）：将项目的工作任务分解为可管理的小部分，以便更好地管理和控制项目范围。
三、项目范围确认1. 编制需求文档：根据项目目标和利益相关方的需求，详细描述项目的功能和特性。
2. 进行需求确认会议：与利益相关方共同参与，验证和确认需求文档中的内容，确保项目的范围与利益相关方的期望一致。
四、项目范围控制1. 设立变更控制机制：建立一个变更控制委员会，负责评估和批准范围变更请求，确保范围变更的合理性和可行性。
2. 进行范围变更评估：对范围变更请求进行评估，包括对其影响、成本和风险进行分析，以便做出明智的决策。
3. 更新范围基准：根据批准的范围变更，在范围基准中记录并跟踪项目的实际范围，确保项目围绕最新的范围目标进行。
五、项目范围验收1. 制定验收标准：根据项目的可交付成果和需求文档，明确项目的验收标准和验收过程，以便在项目完成后进行有效的验收。
2. 进行项目验收会议：与利益相关方一起进行项目的最终验收，确保项目的成果符合预期，并达到客户的要求和期望。
六、风险管理1. 识别范围风险：对可能影响项目范围的风险进行识别和评估，制定相应的风险应对策略，以减轻风险对项目范围的影响。
2. 监控范围风险：持续监控项目范围的风险，并根据需要采取相应的措施，确保项目范围的稳定和可控。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1范围定义
1.1 案例场景
希赛信息技术有限公司(CSAI原本是一家专注于企业信息化的公司，在电子政务如火如茶的时候，开始进军电子政务行业。
在电子政务的市场中，接到的第一个项目是开发一套工商审批系统。
由于电子政务保密要求，该系统涉及到两个互不联通的子网：政务内网和政务外网。
政务内网中储存着全部信息，其中包括部分机密信息；政务外网可以对公众开放，开放的信息必须得到授权。
系统要求在这两个子网中的合法用户都可以访问到被授权的信息，访问的信息必须是一致可靠，政务内网的信息可以发布到政务外网，政务外网的信息在经过审批后可以进入政务内网系统。
张工是该项目的项目经理，在捕获到这个需求后认为电子政务建设与企业信息化有很大的不同，有其自身的特殊性，若照搬企业信息化原有的经验和方案必定会遭到惨败。
因此采用了严格瀑布模型，并专门招聘了熟悉网络互通互联的技术人员设计了解决方案，在经过严格评审后实施。
在项目交付时，虽然系统完全满足了保密性的要求，但用户对系统用户界面提出了较大的异议，认为不符合政务信息系统的风格，操作也不够便捷，要求彻底更换。
由于最初设计的缺陷，系统表现层和逻辑层紧密耦合，导致70％的代码重写，而第二版的用户界面仍不能满足最终用户的要求，最终又重写的部分代码才通过验
收。
由于系统的反复变更，项目组成员产生了强烈的挫折感，士气低落，项目工期也超出原计划的100％。
1.2 问题
问题1：请大家对张工的行为进行点评。
问题2：从项目范围管理的角度找出该项目实施过程中的主要管理问题。
问题3：如何避免类似的问题
1.3 参考答案
【问题1】
(1)张工注意到了系统运行环境的特殊性，在良好设计和实现的情况下满足了用户的要求。
(2)张工忽略了系统用户的潜在要求，在用户界面和操作的风格上范围定义不清晰，造成系统交付时的重大变更。
(3)张工在第一次问题发生后仍没有对范围进行有效的管理，造成了系统第二次的变更。
(4)张工没有对用户界面是否能够满足要求的风险进行有效的管理，而是采用了对风险适应性较差的瀑布模型组织开发。
(5)张工没有对设计质量进行有效的控制，造成表现层中耦合了业务逻辑，增加了修改的代价。
【问题2】
(1)张工没有挖掘到系统的全部隐性需求，缺乏精确的范围定义。
(2)在发生第一次变更时，张工仍没有有效的范围管理，从而造成系统的二次变更。
(3)重复的系统变更说明张工对系统范围控制不足，导致一而再再而三的反复。
【问题3】
有效的范围管理包括了从范围定义到范围控制等多方面的工作，每一项工作都是重要的。
对于本案例，要结合行业特点进行需求分析，挖掘系统潜在的需求，同时通过原型等方法来辅助需求的定义，避免范围定义不清晰的问题。
在发生需求变更时需要进行有效的需求控制，尽量在满足用户需求的前提下缩小需求范围，坚决避免需求的再次变更。
2工作要点
2.1 案例场景
M集团是希赛信息技术有限公司(CSAI )多年的客户，CSAI已经为其开发了多个信息系统。
最近，M又和CSAI签订了新的开发合同，以扩充整个企业的信息化应用范围，张工担任该项目的项目经理。
张工组织相关人员对该项目的工作进行了分解，并参考了公司同M曾经合作的项目，评估得到项目，总工作量60人月，计划工期6个月。
项目刚刚开始不久，张工的高层经理S找到张工。
S表示，由于公司运作的问题，需要在4个月内完成项目，考虑到压缩工期的现实，可以为该项目在增派两名开发人员。
张工认为，整个项目的工作量是经过仔细分解后评估得到的，评估过程中也参考了历史上与K企业合作的项目度量数据，该工作量是客观真实的。
目前项目已经开始，增派的人手还需要一定的时间熟悉项目情况，因此即使增派两人也很难在四个月内完成。
如果强行要求项目组成员通过加班等方式追逐4个月完成的目标，肯定会降低项目的质量，造成用户不满意。
因此，张工提出将整个项目分为两部分实现，第一部分使用三个半月的时间，第二部分使用三个月的时间，分别制定出两部分的验收标准，这样不增派开发人员也可以完成。
高层经理认为该方案可以满足公司的运作要求，用户也同意按照这种方案进行实施。
六个月以后，项目在没有增加人员的前提下顺利地完成，虽然比最初计划延长了半个月的工期，但既达到了公司的要求，客户对最终交付的系统也非常满意，
项目组的成员也没有感受到很大的压力。
2.2 问题
【问题1】
指出张工是如何保证项目成功的？
【问题2】(15分)
试结合案例指出项目范围管理的工作要点？
2.3 参考答案
问题1
(1)张工首先对最初的项目范围进行了清晰的定义，并根据定义对工作进行了分解，制定了WBS。
(2)张工对项目进行了估算，且估算结果真实可信，对项目工作量有量化的把握。
(3)在出现新的项目目标后，张工对项目进行了范围控制，缩小了第一阶段实现的范围。
(4)张工对重新定义的项目范围进行了确认，与高层经理和客户达成一致。
(5)张工对项目进行了沟通管理，协调了多个项目干系人之间的矛盾。
问题2
项目范围管理的要点：
(1)范围管理计划。
(2)范围定义。
(3)工作分解。
(4)范围确认。
(5)范围控制。
在本案例中，张工首先进行了范围定义和工作分解，得到了清晰的项目范围；在出现新的项目目标后，张工进行了范围控制，重新定义了两个阶段的项目范围；最后，张工将重新定义的范围与项目干系人进行了确认。
3范围确认
3.1 案例场景
希赛信息技术有限公司(CSAI )刚刚和M签订了一份新的合同，合同的主要内容是处理公司以前为M公司开发的信息系统的升级工作。
升级后的系统可以满足M公司新的业务流程和范围。
由于是一个现有系统的升级，项目经理张工特意请来了原系统的需求调研人员李工担任
该项目的需求调研负责人。
在李工的帮助下，很快地完成了需求开发的工作并进入设计与编码。
由于M公司的业务非常繁忙，M公司的业务代表没有足够的时间投入到项目中，确认需求的工作一拖再拖。
张工认为，双方已经建立了密切的合作关系，李工也参加了原系统的需求开发，对业务的系统比较熟悉，因此定义的需求是清晰的。
故张工并没有催促业务代表在需求说明书中签字。
进入编码阶段后，李工因故移民加拿大，需要离开项目组。
张工考虑到系统需求已经定义，项目已经进入编码期，李工的离职虽然会对项目造成一定的影响，但影响较小，因此很快办理好了李工的离职手续。
在系统交付的时候，M公司的业务代表认为已经提出的需求很多没有实现，实现的需求也有很多不能满足业务的要求，必须全部实现这些需求后才能验收。
此时李工已经不在项目组，没有人能够清晰地解释需求说明书。
最终系统需求发生重大变更，项目延期超过50%, M 的业务代表也因为系统的延期表示了强烈的不满。
3.2 问题
【问题1】
对张工在项目管理工作中的行为进行点评。
【问题2】
请从项目范围管理的角度找出该项目实施过程中的问题。
【问题3】(8分)
谈谈应如何避免类似的问题。
3.3 参考答案
【问题1】
(1)张工为了更明确地把握系统需求，聘请了原系统的需求调研人员李工，提高了需求定义的效率和质量。
(2)张工没有对李工开发的系统需求进行评审和复查，从而使得需求的缺陷没有被及时发现。
(3)张工没有要求用户对已经定义的需求进行确认，从而导致需求理解的偏差。
(4)张工对需求的不能进行缺乏有效控制，最终造成项目延期50%.
【问题2】
该项目实施过程中的主要问题包括：
(1)在范围定义中，张工没有对李工定义的需求进行评审，造成需求中的质量缺陷没有被及时发现。
(2)在范围确认中，张工没有主动地要求用户对需求进行确认。
(3)在范围控制中，张工无法进行有效的范围控制，最终造成了重大的需求变更。
【问题3】
对于本案例，项目经理需要对需求定义的结果进行质量控制，采取评审等方式减少需求中的问题。
对已经定义的需求需要与用户进行确认，保证双方理解的一致。
在发生需求变更时，也应该采取灵活的手段，在满足用户需求的前提下，尽量减少需求变更的范围。
（注：文件素材和资料部分来自网络，供参考。
请预览后才下载，期待你的好评与关注。
）。