论文-范围管理

论项目的范围管理1

摘要：

通常大型信息系统开发项目都具有相当的难度和复杂性，含糊的需求和频繁变更的范围让经常会使项目进度多拖延、成本超支、偏离既定目标，严重时会导致项目的失败，因此，加强项目范围管理尤为重要。2010年4月至10月，我有幸参与了某集团企业协同办公管理系统项目的建设，并担任项目应用系统包承建方的项目经理，负责项目管理工作。项目的总体目标是建立一个兼具企业门户、公文管理、工作流、知识管理、移动办公的办公平台，共分为10个子系统，分别为：企业门户、个人办公、信息发布、收发文管理、规章制度、日常事务、工作流管理、文档管理、移动办公和基础平台。本文以该项目为例，结合作者实践，探讨了信息系统项目中的范围管理问题，分别论述了范围计划编制、范围定义、范围确认、范围变更控制等过程作为风险管理手段的应用，列举了一些有效的工具和技术的使用；最后，谈一些自己的体会和经验总结。

正文：

通常大型信息系统开发项目都具有相当的难度和复杂性，含糊的需求和频繁变更的范围让经常会使项目进度多拖延、成本超支、偏离既定目标，严重时会导致项目的失败。一个项目的成功得益于有效的项目范围管理机制,这在本人所主持的某集团企业协同办公管理系统项目实施过程中得到了充分验证。

2010年4月至10月，我参加了某集团企业协同办公管理系统项目的开发，并担任的该项目的项目经理。项目目标是建立一个兼具企业门户、公文管理、工作流管理、知识管理、移动办公的协同办公平台，整体提升企业办公服务水平和工作效率。系统采用B\S架构，核心技术框架根据微软的.NET分层体系结构实现，共分为10个子系统，分别为：办公门户、工作助手、信息发布、收发文管理、规章制度、日常事务、工作流管理、文档管理、移动办公和基础平台。

该项目是一个综合性的系统工程项目，该集团企业包括总部、6个大区公司及其下属的地方公司，在管理模式上存在较大差异，信息化程度参差不齐，各个地区工作流程也不一致，业务需求很难统一;协同办公是公司新的业务领域，我方领导也希望将本项目作为公司业务延伸拓展的一个新的窗口；从技术角度将，涉及移动办公、电子签章、工作流、全文检索、备份归档、无线通信等相关技术；人力资源方面，需要不同专业技术的开员，可能会存在多部门之间的协作。由此可见，该项目组织构成复杂、干系人面广人多、业务需求很难统一，而且涉及新的业务领域，公司在协同办公方面也缺乏积累，工作面临很大挑战。因此，在该项目中，我充分重视了项目范围管理，通过制定合理的范围管理计划，做好项目范围的定义、分解、确认和控制，提高领导和项目干系人的参与热情等方法，有条不紊地完成了该项目。具体来说：

首先，制定合理的范围管理计划。范围管理计划就是项目管理团队为如何管理项目范围提供的指导，我们参考了CMMI和组织过程资产的基本内容，并结合项目的各方面实际情况，确定了范围定义、WBS分解的方法、工具和时间，如何进行范围验证和变更控制，以及范围变更计划及规程。例如，采用微软的团队资源管理器（TFS）实现对文档和代码的管理，并在需求、需求分析、设计、代码等各个阶段打基线，通过TFS实现对各种变更的管理，做到有效可控；规定在打每个基线之前召开评审会，邀请所有项目干系人代表参与评审，做到每个阶段的成果都能符合项目干系人的要求。

其次，做好项目范围的定义、分解工作。详细的WBS是范围管理的基础，因此，我们采用了MS Project作为项目管理工具，通过Project，我们建立了项目的WBS，对WBS的每个任务明确了其可交付物，对每一个任务我们都细化到每个人在一周内可以完成，确保每一项任务都是可控的。Project是列表的表现形式，可以方便的反映出项目的的所有工作要素，但是直观性较差，所以我们在局部活动单元讨论时，通常采用MindManager工具绘制成分级的树形结构，更为清晰直观。

由于该集团企业下属部门众多而且分布各地，业务需求有一些差异，业务领域一般比较广泛和复杂，在范围定义的方法上，我们采用了专家法。邀请专家时要尽量能够代表各个地区、部门、组织机构以及各个业务技术领域，这样既可以帮助我们短期内熟悉相关业务，也便于收集和统一来自各个方面的需求，为日后需求的确认铺平道路。

再次，项目评审是确保项目范围能得到很好确认和控制的有效措施。在项目进度计划中我们确定了需求分析、系统设计、系统测试、系统上线等几个重要里程碑。在这些里程碑结束后，我们将邀请相关项目干系人参与项目的评审工作。目的是为了防止需求偏差、遗漏，和收集新的需求，使范围确认工作贯穿于项目的始终，以确保项目范

围的正确性和可接受性。每一次的项目评审都给我们带来了很多很好的建议，让我们充分发现了我们系统的不足之处，发现了许多业务上的偏差。当然也有许多项目干系人提出了系统易用性上的建议。会后，我们按照项目范围变更计划和客户方、业务专家一起对这些建议作了逐一评估，将那些有益的建议包含进项目范围管理计划中。

再好的计划也不可能做到一成不变，因此变更是不要避免的，关键问题是如何对变更如何进行有效的控制。本项目的复杂程度高、涉及面较广、实施周期长，在实施过程中，由于用户方需求的变更，或由于各方交流的失误等，曾经导致了部分项目内容的变更。当有变更要求提出的时候，作为项目经理，我都会召集项目团队相关人员，进行协商讨论和工作安排，对变更因素进行分析、快速决策。由于本项目需求变化不断调整，我们建立了良好的变更流程：填制申请单、团队相关人员讨论、提交CCB给出最终确认、实施和验证变更、通知干系人。

最后，领导的重视和项目干系人的参与是这次项目成功的关键。项目正式启动之初，在双方领导的通力配合下，我们召集了全行主要干系人参与的项目启动会，并邀请客户高层在会议上讲话，提升大家对这个项目重要性的认识。在这次会议上，我作为项目经理向各项目干系人，就项目的主要目标、范围、范围管理计划、进度计划安排、沟通方式作了详细介绍。希望各项目干系人能够积极配合我们的工作，同时我们也将尽量满足他们的要求。在项目进行过程中许多干系人都给我提出了很多很好的建议，同时我们也采取了电话、E-mail、QQ 群等多种沟通方式收集他们的建议。这个项目的成功是全体项目干系人的成功，是全体项目干系人共同努力的结果。

由于我们在项目进行的最初期阶段就引入了项目范围管理理念和方法，项目顺利完成，客户很满意，也为今后公司类似项目积累了经验，得到了公司管理层的高度评价，这归功于整个团队的配合。但是回顾起来，也有一些不足的地方：第一、项目可行性研究做的不够充分，没有充分考虑到各个地区信息化程度的差异，造成到目前为止，少数单位由于网络方面的原因，只能通过拨号来使用本系统，使用效果打了一些折扣。我们也采取了一些补救的措施，如尽量减小页面大小，优化系统响应时间原因等，一定程度上改善使用效果，通过和用户的悉心沟通，最终得到了用户的认可。

总之，项目的管理方式多种多样，因人而异、因项目规模而异，管理方式不是一成不变的。适合自己的管理模式才是最好的模式，这些都有待于我们进一步研究、探索、实践和总结。

总结:摘要可以成为模板,拿来就套用.描述论点的重要性,介绍项目的基本情况,并且简单的说明项目过程中的解决办法.最后用一两句话总结.另外,应该在合适的时候加入风险管理储备的知识.