软件项目管理案例分析之范围管理.ppt

《软件项目管理案例分析之范围管理.ppt》由会员分享，可在线阅读，更多相关《软件项目管理案例分析之范围管理.ppt（21页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、案例分析之范围管理案例分析之范围管理案例一某软件公司承担了A公司的一个ERP系统开发项目，在项目的实施过程中，系统需求似乎永远无法确定，用户说不清楚自己的需求，怎么做他们都不满意，功能不断增加，用户上周说要这个功能，今天说要这个功能，李部长认为这个功能该这样做，而王经理认为这样不行，结果让软件开发人员无所适从。该项目已经进行了两年多，项目何时结束还是处于不明确的状态，因为用户不断有新的需求提出来，项目组也就要根据用户的新需求不断去开发新的功能。大家对这样的项目完全丧失了信心。公司针对目前出现的局面，派出项目管理专家刘工负责ERP项目组的管理工作。刘工通过对项目文档分析和A公司相关人员的沟通认识

2、到，这个项目一开始就没有明确界定整个项目的范围，在范围没有明确的情况下，又没有一套完善的变更控制管理流程，任由用户怎么说就怎么做，也就是说，一开始游戏规则就没有定好，从而导致整个项目成了一个烂摊子。面对项目在范围管理上出现的混乱局面，刘工应该如何处理呢？解决方案一与用户高层的沟通，加强对用户领导及业务骨干的培训，使其了解ERP系统开发的要求和流程，使相关人员重视、参与、支持这项工作；完善组织机构，由用户的业务骨干以适当形式参加项目工作，明确其职权，使其在范围界定、需求确认方面有一定的权威性，与项目团队共同弥补前期工作的不足;明确界定整个项目的范围；完善范围变更控制管理流程，经用户确认后严格执行

3、；制定完善的计划，明确进度、质量标准、费用等事宜。解决方案二1.找当前项目经理沟通，听取他对项目的问题分析和建议。找项目组其他成员谈话，听取他们对项目的看法；2.召开项目组内部会议，梳理当前需求，按照难易程度整理成清单，估算完成每个需求的工时，同时做项目风险分析。建立项目组内部沟通渠道和培训机制。制定团队建设计划，提高团队士气。3.找甲方主管领导沟通，明确自己本次来的目的是为了改善项目实施，简要的汇报当前问题，希望得到支持。找甲方领导申请召开三方会议。明确甲方、乙方和监理方的相关人员，主管领导要到场。4.三方会议，明确以下几个内容：4.1 建立变更控制委员会，制定变更控制流程；4.2 建立沟通

4、机制，尤其是重要的项目干系人。例如，每周除项目组例会之外，邮件抄送项目进展情况给各位重要项目干系人，定期给甲方领导汇报；4.3 明确项目范围；4.4 展示项目组前期成果，给出项目组整理好的带有工时估算的需求清单。明确原则上不再接受新增需求，有重要新增需求走项目变更流程。现有存在疑问的需求，由项目组组织专题调研会议，形成统一的思想，定下来之后，若又有不同的声音，则走项目变更流程；4.4 甲方需明确能承受的上线时间点；4.5 会后出会议纪要，发送给各位与会人员。5.根据三方会议甲方定下来的最迟上线时间，估算项目本期最多能够完成哪些需求。评估剩余需求是否可以有足够的费用来采用加班加人完成。若不能完成

5、，则需要再次真诚的与甲方主管领导沟通，希望能够采用二期方式，或者上线之后（验收之前）增加投资的方式来完成项目。案例二陈嘉恒为某系统集成公司项目经理，负责某国有企业信息化项目的建设。陈嘉恒在带领项目成员进行业务需求调研期间，发现客户的某些部门对于需求调研不太配合，时常上级推下级，下级在陈述业务时经常因为工作原因在关键时候被要求离开去完成其他工作，而某些部门对于需求调研只是提供一些日常票据让其进行资料收集，为此陈某非常苦恼。勉强完成了需求调研后，项目组进入了软件开发阶段，在软件开发过程中，客户经常要求增加某个功能或对某个表进行修改，这些持续不断的变更给软件开发小组带来了巨大的修改压力，软件开发成员

6、甚至提到该项目就感觉没动力。项目期间由于客户需求变更频繁，陈嘉恒采取了锁定需求的办法，即在双方都确认变更后，把变更内容一一列出，双方盖上公司印章生效，然而这样做还是避免不了需求变更，客户的变更列表要求对方遵守承诺，客户却认为这些功能是他们要求的，如果需要新的变更列表，他们可以重新制作并加盖印章。陈嘉恒对此很无奈。最终在多次反复修改后，项目勉强通过验收。而陈嘉恒对于该项目的后期维护仍然感到担忧。解决方案一1.规则和授权：项目经理应在项目实施前制定和发布项目章程，组建包含各业务部门相关干系人参与的PMO及变更管理委员会，争取公司高层的认可和授权。2.变更需委员会批准，和经济挂钩，将需求做到下一期升

7、级。3.合同上落实需求范围。4.管理好项目文档，将来也是依据5.首次变更申请时候，公司技术强人的帮助下，和能做主的干系人做一次正式沟通，将需求再次明确，坚决避免第2次变更。解决方案二资讯化系统的需求收集是系统分析的基础，首先要明确最终用户，了解相关利益者，特别是要争取到领导的支持，其次要确定好需求调研的方法策略，准备好调研的工具，尽可能在调研过程中相信了解用户需求，站在用户的角度抓住利基点，然后整理需求，做好需求分析，将用户需求完整的进行规划，需求文件需要得到用户的认可。在软件开发过程中，如果用户提出新的需求或改善点，则需要对新的需求进行分析评估，必要的变更则依照变更管理程序执行，非必要的则与

8、用户沟通在后续进行改善。案例三某金融信息化项目，乙方项目经理为A。甲方为B银行，行长为Z。项目进行到一半，因各种原因，项目面临延期的风险。项目经理A与银行的Z行长进行了沟通，希望能通过消减范围或者延长实施周期，但Z行长不让步，要么加班，要么加人，总之必须保证项目按期完成，面对一个强势得不可理喻的客户，项目经理应该怎么办?解决方案一客户就是上帝，沟通则是桥梁，首先在谈及该问题时第一出发点要站在客户的立场考虑，赶工会让成本增加不少，在谈时把赶工的部分的成本预算工作分析列出一个表出来，综合各方面因素之后尽可能地降低损失，任何一个工程都有失利或得利之处，综合分析至关重要。解决方案二1、充分协调项目组成

9、员及公司资源，在最短时间内了解Z对乙方现场施工所提出的苛刻要求到底处于何种目的，是关系不到位还是项目未能达到预期目标，等等，之后对症下药；2、项目组自我检讨，召开项目内部会议，总结问题，提出解决办法后，再与用户高层进行项目会议沟通，并讨论确定双方都可以接受的结果，形成会议纪要，通发；3、以上都不行的话，只能按合同要求处理，原则是：合情、合规、最后是合法。（中国人的项目情为先，法为后）。案例四营销部门签署了一个合同，但是合同中只描述了大概的范围框架。谈合同期间，让用户对范围框架进行一下具体的描述，用户也无法给出一个详细的描述。合同签署之后，就着手根据项目的开发工作，开发出雏形之后，A用户就开始有

10、了他们的想法，考虑到项目的后续验收都要经过A用户的签字。所以项目组还是按照需求变更流程的做法让A签字，避免后续工作影响，A用户也配合该工作随着工作的深入开展，用户A的想法也越来越多，也逐渐超出了合同谈判期间的大概范围(站在用户的角度来说，他认为这些需求就是本次合同里面大概范围)。该项目已经进展了2个月了，能够进行正常使用，离用户的要求也越来越近，就由于前期合同谈判期间范围未定义好，导致了变更不变。针对这样的案例，对于项目经理该如何更好的进行处理呢?解决方案一范围控制的第一步是识别需求，需要化项目组相当的精力来做，包括了解、挖掘和确认，特别是案例中合同草签的情况，更应该在项目启动的前期做好充分的

11、沟通。鉴于需求的明确还涉及到进度的完成，在识别过程中协商明确一个时间节点，在节点提出的范围变化，采用整体变更来控制，让用户重视范围。高层的参与在识别过程中也很重要。解决方案二一切都以签订的合同最终交付成果为导向。在客户不接受的情况下，做出以下动作：一、召集项目所有干系人，提交A用户所提出的变更，对WBS中未明确的范围进行审查。项目团队针对用户所提交的新需求做出分析，把影响项目的因素（包括执行新需求带来的成本估算、进度报告等）发布给所有关系人。由高层对最终完善的范围做出审批。审批通过，开展新工作。二、就这次变更做经验总结，更新组织过程资产。如果新需求导致项目完全失控，就签订的合同范围完成项目，以

12、新需求签订二期合同。案例四高先生在一个大型集团企业中任部门经理，同时担任与本岗位工作质量提升相关的管理类项目。令他困惑的是，高层领导经常针对项目，提出项目范围之外但又在岗位职责之内的要求，从而导致项目变更。如此下去，很可能使项目陷入滚雪球一项无休止的境地，但是对高层领导的要求又不能置之不理，高先生应该怎么做？解决方案一分析：1、高先生虽为部门经理，但又同时担任了项目管理的工作,从根本上增加了高先生的工作量；2、高先生担任的项目管理工作是针对部门工作质量，客观的讲，高先生的客户就是公司高层领导；解答：1、高先生应该记录好高层提出的需求以文字记录存档；2、组织内部工作人员分析高层提出的需求对整个质

13、量项目管理产生的影响（范围、工作量、进度及人员调配等）；3、将分析得出来的结果，以基本项目范围为基本而确定将会新的需求会带来的风险（成本的增加、进度的延后、部门之间的冲突）以文字书面列出；4、将风险向上级领导汇报，请示高层领导群，就本项目管理的工作进行新的需求整合；5、当得到确认后，高先生即可将工作的内容以的不断增大为理由将部分工作量分配给其他的部门经理一起管理；如果得不到确认，还可以申请调离原先的部门经理一职总管部门工作质量进度的管理工作。解决方案二高层提出项目的新需求，一般是站在公司战略和产品营销角度考虑的，此时不妨与高层沟通下其真正目标，有些只是老总随口提提，并未得到充分系统思考的，有些

14、合理的需求则应继续得以充分分析，甚至加以实施。当然，其中实现新需求的厉害关系也好做好向高层汇报的工作，这就使得项目负责人的责任转移了。这样，即尊重了高层，又把问题解决了，大家共赢。解决方案三1、设立一个长期的变更控制小组（担当CCB的功能），包含公司的高层领导、行业专家、项目负责人等；2、对于高层领导提出的新要求，首先自己得与提出问题的高层领导进行有效的沟通，确认其问题所在，然后分析一下是否有必要变更，如果确认变更对项目有好处，那么可以向变更控制小组提出变更申请，之后就是走一系列的变更流程了。当然，考虑到高层领导一般不会只有一个人，其提出的修改要求，有时候还是会发生冲突的，因此，高先生的作用主

15、要就在这块了，协调各高层领导，在对同一问题的处理上达成一致。3、既然会发生较多的变更，那么项目在做计划和成本预估的时候，必须做个提前量，或者提前准备好所需的人员，以备不时之需。案例五公司A是市政府背景很强的股份制企业，机制比较灵活（shanghai），目前该公司的正在进行的一个项目是政府机关的一个Mis系统，现在整个开发全部完成，系统已经试运行2个月左右，目前运行情况比较顺利，但是，目前有几个比较大的问题如下：1.客户同公司关系特别密切（毕竟客户是机关），不能完全按照合同进展。2.政府的工作节奏比较慢，在项目实施进程中，严重单方面拖延实施进度，造成项目延期。（他们很小的项目决定需要开会讨论）3

16、.不可预测的项目变更风险（机关领导一句话，项目经理就要处理变更需求；可称其为领导人风险）。4.客户没有项目周期（软件项目）等认识，对合同规定的验收不予回应。这个需要该公司老总才能协调。（项目经理没有这方面的权利）项目经理在项目组中本来负责软件开发设计，开发后期被部门经理任命为项目主管，对于客户主关需求变更，项目管理目前沟通的比较好。但对于一些政策性的变更，则非常的难处理（需要必须改动），没办法，只有进行变更处理。该公司应该怎么才能结束该项目呢。解决方案一电子政务系统开发的关键在于“制定阶段目标”，公司要先将电子政务系统的特性与客户在理念上进行沟通，双方达成共识：理想、完善的系统是不存在的，改革

17、在深入，认识在提高，技术在发展，一味追求完善，不但是公司要出问题，系统也会不断的调整下去，得不到应用，而系统的完善正是在应用中才能得以完善，工作人员也正是在应用中，认识和水平才有所提高，转而提出更切合实际的需求，公司才能开发出更好的软件。项目才会在二期、三期中，随着机构，制度和技术的变革不断完善。掌握了电子政务“阶段目标”的制定方法和操作技巧，与客户达成共识，用户需求变更的情况就产生了两种方法接受变更，立即执行；接受变更，后期项目统一执行。这样既保持了客户的良好关系，又避免了当期目标的拖延实施，造成项目延误。如果市场人员定好了合同目标和工期，技术人员把握好了前期需求和后期需求变更，文档、记录清

18、楚，再加上公司高层领导和甲方领导的密切沟通，我认为大部分问题是会友好解决的，项目也会顺利验收的。操作中的关键环节：合同的目标和工期，要明确阶段；需求调查和需求变更要有清楚的文档和会议纪要；双方高层要经常及时地沟通；阶段验收前，文档要齐全，阶段目标要保证实现，后期目标调整要有承诺。把握好项目的变更和不断提出新的阶段目标会使双方的合作得到更紧密的加强，从而各得其所。解决方案二政府部门是一个强势部门，他有他自己的工作方式和工作习惯，对于一个企业来说，绝对不可能因为一个项目而要求政府部门对一些习惯、工作环境做一改变，而只能去适应。从另外一方面来说，和政府部门有关系的企业，他所得到的项目是比较多的，不应该因为一个项目的得失而斤斤计较，再说一个项目一般也不可能亏损，最坏也就不赢利罢了，所以投入资源相对多一点也不是没有可能的。这一点我想公司老总应该非常清楚，了解。对于怎样结束项目，我认为可以从以下几个方面考虑：1、加强双方领导的协调2、增加开发资源（人力、设备、资金），加快项目进度，尽可能地接受客户的合理要求3、反复和客户沟通，确认项目的边界4、超出项目边界的需求，记录需求，和客户沟通，商定增加在下一期的开发任务中。5、对于任何变更要有详尽的风险分析，告诉客户变更可能对在运行系统的影响，让客户接受这样的风险，让客户来决定要不要变更，还是增加到下一期的开发任务中。