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

案例分析之范围管理 案例一 某软件公司承担了A公司的一个ERP系统开发项目，在项目的实施过程中，系统需求似乎永远无法确定，用户说不清楚自己的需求，怎么做他们都不满意，功能不断增加，用户上周说要这个功能，今天说要这个功能，李部长认为这个功能该这样做，而王经理认为这样不行，结果让软件开发人员无所适从。 该项目已经进行了两年多，项目何时结束还是处于不明确的状态，因为用户不断有新的需求提出来，项目组也就要根据用户的新需求不断去开发新的功能。大家对这样的项目完全丧失了信心。 公司针对目前出现的局面，派出项目管理专家刘工负责ERP项目组的管理工作。刘工通过对项目文档分析和A公司相关人员的沟通认识到，这个项目一开始就没有明确界定整个项目的范围，在范围没有明确的情况下，又没有一套完善的变更控制管理流程，任由用户怎么说就怎么做，也就是说，一开始游戏规则就没有定好，从而导致整个项目成了一个烂摊子。 面对项目在范围管理上出现的混乱局面，刘工应该如何处理呢？ 解决方案一 与用户高层的沟通，加强对用户领导及业务骨干的培训，使其了解ERP系统开发的要求和流程，使相关人员重视、参与、支持这项工作； 完善组织机构，由用户的业务骨干以适当形式参加项目工作，明确其职权，使其在范围界定、需求确认方面有一定的权威性，与项目团队共同弥补前期工作的不足; 明确界定整个项目的范围； 完善范围变更控制管理流程，经用户确认后严格执行； 制定完善的计划，明确进度、质量标准、费用等事宜。 解决方案二 1. 找当前项目经理沟通，听取他对项目的问题分析和建议。找项目组其他成员谈话，听取他们对项目的看法； 2. 召开项目组内部会议，梳理当前需求，按照难易程度整理成清单，估算完成每个需求的工时，同时做项目风险分析。建立项目组内部沟通渠道和培训机制。制定团队建设计划，提高团队士气。 3. 找甲方主管领导沟通，明确自己本次来的目的是为了改善项目实施，简要的汇报当前问题，希望得到支持。找甲方领导申请召开三方会议。明确甲方、乙方和监理方的相关人员，主管领导要到场。 4. 三方会议，明确以下几个内容：4.1 建立变更控制委员会，制定变更控制流程；4.2 建立沟通机制，尤其是重要的项目干系人。例如，每周除项目组例会之外，邮件抄送项目进展情况给各位重要项目干系人，定期给甲方领导汇报；4.3 明确项目范围；4.4 展示项目组前期成果，给出项目组整理好的带有工时估算的需求清单。明确原则上不再接受新增需求，有重要新增需求走项目变更流程。现有存在疑问的需求，由项目组组织专题调研会议，形成统一的思想，定下来之后，若又有不同的声音，则走项目变更流程；4.4 甲方需明确能承受的上线时间点；4.5 会后出会议纪要，发送给各位与会人员。 5. 根据三方会议甲方定下来的最迟上线时间，估算项目本期最多能够完成哪些需求。评估剩余需求是否可以有足够的费用来采用加班加人完成。若不能完成，则需要再次真诚的与甲方主管领导沟通，希望能够采用二期方式，或者上线之后（验收之前）增加投资的方式来完成项目。 案例二 陈嘉恒为某系统集成公司项目经理，负责某国有企业信息化项目的建设。 陈嘉恒在带领项目成员进行业务需求调研期间，发现客户的某些部门对于需求调研不太配合，时常上级推下级，下级在陈述业务时经常因为工作原因在关键时候被要求离开去完成其他工作，而某些部门对于需求调研只是提供一些日常票据让其进行资料收集，为此陈某非常苦恼。勉强完成了需求调研后，项目组进入了软件开发阶段，在软件开发过程中，客户经常要求增加某个功能或对某个表进行修改，这些持续不断的变更给软件开发小组带来了巨大的修改压力，软件开发成员甚至提到该项目就感觉没动力。项目期间由于客户需求变更频繁，陈嘉恒采取了锁定需求的办法，即在双方都确认变更后，把变更内容一一列出，双方盖上公司印章生效，然而这样做还是避免不了需求变更，客户的变更列表要求对方遵守承诺，客户却认为这些功能是他们要求的，如果需要新的变更列表，他们可以重新制作并加盖印章。 陈嘉恒对此很无奈。最终在多次反复修改后，项目勉强通过验收。而陈嘉恒对于该项目的后期维护仍然感到担忧。 解决方案一 1.规则和授权：项目经理应在项目实施前制定和发布项目章程，组建包含各业务部门相关干系人参与的PMO及变更管理委员会，争取公司高层的认可和授权。 2.变更需委员会批准，和经济挂钩，将需求做到下一期升级。 3.合同上落实需求范围。 4.管理好项目文档，将来也是依据 5.首次变更申请时候，公司技术强人的帮助下，和能做主的干系人做一次正式沟通，将需求再次明确，坚决避免第2次变更。 解决方案二 资讯化系统的需求收集是系统分析的基础，首先要明确最终用户，了解相关利益者，特别是要争取到领导的支持，其次要确定好需求调研的方法策略，准备好调研的工具，尽