项目范围管理论文.doc

项目范围管理论文项目范围的管理也就是对项目应该包括什么和不应该包括什么进行相应的定义和控制。它包括用以保证项目能按要求的范围完成所涉及的所有过程，包括：确定项目的需求、定义规划项目的范围、范围管理的实施、范围的变更控制管理以及范围核实等。烽火猎头专家亦认为项目范围是指产生项目产品所包括的所以工作及产生这些产品所用的过程。项目干系人必须在项目要产生什么样的产品方面达成共识，也要在如何生产这些产品方面达成一定的共识。制约一个项目的条件是项目“三约束条件”范围时间成本。在一个项目中这三个条件是相互影响、相互制约的，而且往往是由于范围影响了时间和成本。然而在项目进行到一定阶段之后往往会变得让人感觉到不知道项目什么时候才能真正结束，要使项目结束到底还需要投入多少人力和物力，整个项目就好象一个无底洞，对项目的最后结束谁的心里也没有底。这种情况的出现对于公司的高层来说，他们是最不希望看到的，然而这样的情况出现并不罕见。造成这样的结果就是由于没有控制和管理好项目的范围。可见项目的三个约束条件中最主要还是范围的影响。 既然项目范围界定不清是一种很常见的现象，而这种现象又是大家所不想见到的。那么，我们必须分析出现这种现象的原因。我认为造成这种现象的出现有以下三方面的原因：第一，是企业一级的责任没有完善的项目管理体系来指导项目的管理。这种情况是最糟糕的，如果是这种原因，那么项目的成败往往需要靠项目经理个人的管理、领导能力。这种情况项目成功的可能性非常小，大部分项目都是以失败而告终； 第二，是企业及项目组共同的责任对项目没能制定出清晰规范的变更控制，企业有管理体系，但不够完善和规范，对项目组的变更过程的制定没能起到有效的指导作用。变更是不可避免的，只要有效地加以管理、控制，同样可以达到各方满意的结果；第三，是对范围的定义不够明确，做不到可量化、可验证程度。很多时候都是一些定性的要求、而不是定量的，例如“界面友好，可操作性强，提高用户满意度”等。类似这些模糊的需求就是导致后续项目扯皮的根源。项目范围的明确定义，有经验的项目经理及系统分析员将起到至关重要的作用。由以上的论述，我们可以得出结论：完善的项目范围管理是整个项目最终成败的关键。那么，怎样才能做好项目范围管理呢？下面大量篇幅将对这一问题进行详细的论述。 计划明确了，然而该做哪些事情似乎还是一把抓，因为完成项目本身是一个复杂的过程，必须采取分解的手段把主要的可交付成果分成更容易管理的单元才能一目了然，最终得出项目的工作分解结构（WBS）。恰当的范围定义对项目成功十分关键，当范围定义不明确时，变更就不可避免地出现，很可能造成返工、延长工期、降低团队士气等一系列不利的后果。比较常用的方式是以项目进度为依据划分WBS，第一层是大的项目成果框架，每层下面再把工作分解，这种方式的优点是结合进度划分直观，时间感强，评审中容易发现遗漏或多出的部分，也更容易被大多数人理解。Microsoft的项目管理工具Project就可以自动为各个层次的任务编码。 范围说明在项目参与人之间确认或建立了一个项目范围的共识，作为未来项目决策的文档基准。范围说明中至少要说明项目论证、项目产品、项目可交付成果和项目目标。项目论证是商家的既定目标，要为估算未来的得失提供基础；项目产品是产品说明的简要概况；项目可交付成果一般要列一个子产品级别概括表，如：为一个软件开发项目设置的主要可交付成果可能包括程序代码、工作手册、人机交互学习程序等。任何没有明确要求的结果，都意味着它在项目可交付成果之外；项目目标是要考虑到项目的成功性，至少要包括成本、进度表和质量检测。项目目标应该有标志（如：成本、单位）和绝对的或相对的价值（如：少于150万美元等）。不可量化的目标（如：“客户的满意程度”）要承担很高的风险。 范围管理计划是描述项目范围如何进行管理，项目范围怎样变化才能与项目要求相一致等问题的。它也应该包括一个对项目范围预期的稳定而进行的评估（比如：怎样变化、变化频率如何及变化了多少）。范围管理计划也应该包括对变化范围怎样确定，变化应归为哪一类（当产品特征仍在被详细描述的时候，做到这点特别困难，但绝对必要）等问题的清楚描述。 一个项目的范围计划可能制订的非常好，但是想不出现任何改变几乎是不可能的。因此对变更的管理是项目经理必备的素质之一。变并不糟糕，糟糕的是缺乏规范的变更管理过程。范围变更的原因是多方面的，比如用户要求增加产品功能、环保问题导致设计方案修改而增加施工内容。项目经理在管理过程中必须通过监督绩效报告、当前进展情况等来分析和预测可能出现的范围变更，在发生变更时遵循规范的变更程序来管理变更。我们强烈建议企业的项目管理体系中包含一套严格、高效、实用的变更程序，它对管好项目至关重要。项目范围管理计划是一种规划工具，说明项目团队如何确定项目范围，制定详细的项目范围说明书，确定与制作工作分解结构，核实项目范围，以及控制项目范围。制定项目范围管理计划与确定项目范围的细节从分析项目章程、项目初步范围说明书与项目管理计划最近批准的版本提供的信息，组织过程资产中的历史信息，以及任何有关的事业环境因素开始。项目范围管理计划是“制定范围计划”过程的主要成果。 项目范围管理计划是项目管理团队确定、记载、核实、管理和控制项目范围的指南。项目范围管理计划的内容有：项目范围管理计划包含在项目管理计划之内，也可作为其中一项分计划。项目范围管理计划可以是正式或非正式的，极为详细或相当概括的，具体视项目的需要而定。具体而言，项目范围管理计划包括：范围进程，范围，程序将包括定义，就如何范围，为发展项目，将记录在案。它将处理的性质，功能和技术要求和区/个人负责制定这些规定。 它也将包括详细说明如何以及何时范围可能还会修改之前和之后，项目基准确定。这个过程包括信息时，范围应baselined当某些类型的文件（例如，变化控制原木，功能和技术要求单据）应予更新。职责范围，责任应当体现谁负责的范围定义（功能和技术） ，更新和实时信息采集项目和任务绩效。 这也可以包括由谁负责的范围，文件和谁进行数据输入。范围声明，无论是参照或全部范围的声明，应纳入本文件。变更控制，再次，无论是由参考或在整体上，变更控制过程应包含在范围管理计划。 制定项目范围计划的依据有：事业环境因素、组织过程资产、项目章程、项目初步范围说明书和项目管理计划。事业环境因素的例子有组织文化、基础设施、工具、人力资源、人事方针，以及市场状况，所有这些都会影响项目范围的管理方式。组织过程资产是能够影响项目范围管理方式的正式和非正式的方针、程序和指导原则。随着我国经济社会的快速发展，企业规模越来越大，企业业务联系越来越紧密，原有的分散独立的企业资源分配方式已无法适应企业集团化的需要，为此如何整合企业资源优化，统一调配，提高企业资源的利用率，降低生产成本，提高经济效益，已成为摆在企业面前迫在眉睫的问题。因此，开发一个erp企业资源信息系统平台就应运而生。2012年8月，我有幸参加了某市某集团erp企业资源信息系统平台的建设工作，并出任项目经理，该系统实现集团公司旗下的几个分公司的资源整合，统一分配，达到合理配置企业资源的功能。该信息系统项目分为6个子系统，它们分别是：原料采集加工处理信息系统，半成品生产制造信息系统，成品生产制造信息系统，物流运输管理系统，市场销售业务信息系统，企业业务资源调配和决策系统。该系统计划投资500万元，建设工期为12个月。该系统采用c/s架构，后台数据库采用sel service 2012,中间件技术采用corba，用java语言开发。由于系统建设项目牵扯的单位多，业务大，是对集团公司的整个生产链进行统一管理，项目能否实现预期的产品目标，直接影响到企业的经营状况和广大员业务效率，基于这些原因，我把项目的范围管理管理作为本系统项目建设的重点之一。我从制定项目范围管理计划，进行范围定义，创建工作分解结构（wbs）,范围确认，范围的变更控制这几个方面加强了范围管理工作。 制定切实可行的项目范围管理计划，保证范围管理工作的顺利实施。 项目范围管理计划就是对范围管理所采用的方法，步骤，技术，根据本项目的特点进行优选，以获得最佳的行动方案。为此，我依照项目管理计划，项目章程，以及初步的项目范围说明书，邀请客户代表，与项目组成员一起，采用头脑风暴法，研究制定初步的范围管理计划方案，为保障该计划的确实可操作性，实现预期的范围管理目标，我又邀请行业内专家，在初步的范围管理计划方案的基础上，采用德尔菲法，制定出精确的项目范围管理计划书。最后确定出本次项目范围管理的实施步骤和方案如下：1.用咨询重要客户的方式替代过去召开会议获取范围定义的模式，2，根据本项目的业务特点，利用分解技术创建树形的工作分解结构，3，利用阶段性评审，对阶段性可交付物进行审查，获得用户的范围确认。4，严格执行范围变更的流程，对范围变更进行有效控制。 范围定义就是确定做什么，不做什么，确定项目包含什么，不包含什么，确定项目的约束条件，即时间，成本，质量要求等。这是实现项目目标和达到干系人满意的基础性工作。为此我有意加强了这部分工作。我在理解了初步项目范围说明书，项目章程的基础上，充分对客户的需求进行调研，我查询了组织过程资产，摒弃了以往以召开会议的方式获取用户需求的模式，改为以向用户咨询的方式，该方式的好处是，用户可以在轻松的氛围环境中表达需求，咨询表达就选在业务现场，这样需求具有很强的现场操作性和模拟性，用户更能明确，完整的表达需求。然而，在项目实践中，项目需求是一个不断细化，明确的一个过程，一次性地让用户把需求表达完全，是不可能的。因此，在需求定义的工作中，我利用滚动波次技术，把近期的项目需求定义的详细些，把远期的项目需求定义的概括，抽象些。这是一个逐步细化，明确的一个过程。对于用户表达不清，概念模糊的需求，我采用原型法，利用收集来的数据，做成模型提供给客户参考，比对，已消除需求定义的不确定性和二义性。 需求文件完成以后，我组织项目组成员，邀请用户代表，以及行业内专家，召开需求分析大会，形成了详细的范围管理说明书。具体内容如下：1.产品目标范围，包括功能性需求范围，和非功能性需求范围，即6个子系统功能的范围界定，都包含哪些功能，功能的内容是什么,以及6个子系统之间的数据交互接口的范围定义。2.项目目标的限制，即工期要求，投资成本要求。本项目的工期要求为1年，预计投资成本是500万元。当然，这些要求限制在项目的具体执行过程中可能会发生变化，但变化不大，这一点在客户代表大会上进行了说明。3.提交阶段性可交付物。我决定在项目的前期产生需求说明书和系统结构设计书，在项目中期完成6个子系统的单独运行，在项目后期完成集成测试和初步试运行。4.免责范围的确定。依据合同文件，排除有牵连的无效工作，包括强电系统的改造，原有信息系统的升级利用。5执行规范的确定，本项目中采用iso 9000系列的质量标准为最低要求，不能低于这个标准，把计算机软件质量保证计划规范作为此项目开展，执行过程中的标准。 二，对已识别定义的项目范围的可交付物，进行工作分解结构分解。 wbs的创建就是把项目的工作进一步划分为更小，更易管理的工作单元，它可以使项目工作组成明确，清晰，利于工作任务的落实和责任划分。为此，我依照详细的范围说明书，项目管理计划，采用分解技术，自顶向下，逐层进行了分解。wbs采用树形结构，把项目的可交付物作为第一层，即：原料采集加工处理信息系统，半成品生产制造信息系统，成品生产制造信息系统，物流运输管理系统，市场销售业务信息系统，企业业务资源调配，6个子系统作为第一层，然后，把各个子系统的概要设计作为第二层，软件详细设计作为第三层，依次分别是编码，测试，试运行。分解到最后的分解结构时，我采用8/80原则，我把这最小的工作包分配给具体的人负责。工作分解结构完成之后，是对wbs进行编码，即进行工作包的属性描述，包括工作编号，工作名称，负责人，资源描述等。这样就形成了范围基线，它是一个范围标准的可参考基准。通过它可以进行度量，判断是否有超越或缩小项目范围的情况发生。 三范围确认。 有效的范围确认，是对阶段性可交付物的检查和认定，是项目干系人对项目范围的认可。这是保障项目工作顺利进行基础。在本项目中，我依据详细的项目范围说明书，项目管理计划，wbs字典，对项目的阶段性陈果（可交付物）进行验收，在需求分析阶段，我把行成的需求规格说明书呈报给用户，检查核实需求范围是否有遗漏，是否有范围蔓延，关键是获得用户项目范围的认可肯定。在软件结构设计阶段完成时，我提交软件结构图给用，并充分讲解此软件结构的特点，并说明此结构有利于功能模块的扩展，有利于版本的升级，这样用户就会对我们的结构图产生信任感，并最终在软件概要设计阶段范围确认上签字。当然，在现实的项目范围确认实施过程中，用户对我们范围确认表示不理解，认为范围确认签了字了，就不能更改了，通过我有效的沟通，很快排除了用户的疑虑。保证了项目范围确认工作的顺利展开。 四范围变更控制 项范目围管理计划制定的再好，在实际项目执行过程中，范围也可能会发生变化，变化可能来自内部，也可能来自外部。那么，如何控制项目范围的变更，如何让范围变更在可控的范围内，是范围管理工作必须要做的工作。为此，在项目成立之初，我就成立了变更控制小组（ccb）,项目范围的任何变更必须严格遵照变更控制流程执行。1.提请变更申请。2评估范围变更对项目带来的影响。3.执行变更4.对变更结果进行跟踪审核并把结果通知项目干系人。在本项目建设中，甲方要求把强电系统改造也作为项目建设的一部分，但在合同文件和项目范围说明书中并没有此项的内容，如果增加此项内容，必将对项目的工期，投资产生影响，我把这些影响与甲方进行有效的沟通，经过商讨，此项工作可以作为下期项目的工作内容。在项目组成员开发内部，也可能造成项目范围变更，新毕业的硕士生小王，在开发子系统原料采集加工处理信息系统时发现，并没有客户身份认证的设计，对于这个变更申请，我查阅了范围说明书，需求说明书，项目管理计划，发现在项目建设初期就没有把此项内容列入需求之中，为此，我权衡利弊，邀请客户代表进行此项内容磋商，最终客户同意了此项变更。我把此项变更以书面的形式报控制变更委员会审批，并在书面材料中阐明了此项申请的利和弊。ccb经过审核，认为我的变更申请是必要的，给予了批复。得到变更申请通过后，我就组织项目组成员进行变更执行，并更新了项目管理计划，项目最终圆满完成。项目的最大风险是项目范围的不确定性，最大的管理难度也正是对项目范围的管理和控制。下面以某集团公司外网门户及内网办公平台建设项目为例加以论述。细化过的工作范围部分。项目范围的“圈定”，并不能代表项目范围就是可控制的。因此要进一步对项目范围定义，实际就是对项目工作范围进一步细化的过程，使项目范围个体化、层次化、结构化，从而达到可管理、可控制、可实施的目的，减少项目风险。在软件开发项目中，项目范围的“圈定”，就是对用户需求的定义。需求的定义，是需求开发中的重要环节。在需求开发中，包括了需求获取、需求分析、需求定义和需求验证。1. 需求获取在制定了项目管理计划后，我们把主要的精力投入到了项目范围的定义中。首先，我们和用户的项目主管理部门，即用户的信息部制定了需求调研计划，在信息部的协调和组织下，对集团的二十多个职能部门进行了为期十天的需求调研工作。我们事先根据项目的建设目标，对调研内容做了充分的准备，拟定了详实的调研内容，包括二套调研表，第一套主要针对内部办公平台，有“部门基本情况表”、“公文信息情况表”、“公文流程调研表”、“数据采集情况表”和“知识管理情况表”等，第二套表是针对门户应用的，涵盖“外网门户”、“内网门户”、“部门子门户”、“下属企业子门户”和“企业文化子门户”等。在调研工作中，我们了解到，对于本次项目的项目目标，集团高层项目负责人和信息主管部门有比较清晰的理解，但其它各职能部门在项目的前期参与的不够，对这次项目到底要做什么不是很清楚，而各自对集团信息工作的理解差异也很大，从而对项目的需求难免是发散性的思维，这些都增加了沟通的难度。处于对用户的尊重，我们除了耐心地试图通过沟通尽力与用户对项目目标达成一致的理解外，还是把用户的一些其他需求细心地记录下来。也就是说，把用户对信息工作的真实需求和想法都完整地记录下来。完成了需求调研后，我们对调研表的内容首先进行了汇总，再进行认真细致的归纳和分类，把用户的需求分为了“项目范围内需求”和“其他信息化建设需求”两大部分，并对此与用户方进行了多次的沟通和交流，逐步缩小了对项目范围界定上理解的差异，经过一些调整和补充，最终达成了一致的分类。根据“项目范围内需求”，我们编制了用户需求说明书。2. 需求分析根据用户需求说明书，我们开始对用户的各种需求信息进行了分析。信息门户部分，我们规划了外网首页的导航、栏目设置以及二级页和内容页。对于内网的多级门户，我们更是认真细致地分析规划，规划各级门户的架构，根据用户需求，确定各级门户的内容，分析各级门户之间的相互关系，规划信息的交流与共享，以满足协同办公的总体目标。3. 需求定义在需求分析的基础上，对整体软件系统的需求项和功能项进行了准确的定义，编制了软件需求说明书。对于门户部分，我们也做了整套的界面初步设计，以达到对各级门户的栏目、内容、功能的准确定义。二、项目范围确认项目范围的确认实际上是贯穿整个项目生命期全过程的。从前期的对软件需求说明书的确认，到项目各个阶段的交付物的检验，直到最后项目收尾文档的验收，甚至是最后项目评价的总结。但是，最为重要的环节还是在对前期的对软件需求说明书的确认。这一环节在需求开发中，属于需求验证。这也是一项艰苦的历程。从用户的最初需求说明，到真正落实到一个个软件的需求项，再细化到功能项，必定融入了我们对用户需求的进一步理解、加工和规划。当这些成果呈现给用户时，用户也有一个再次理解和认识的过程，双方的理解又会再次出现偏差。当然，这些偏差既有正向偏差，也有负向偏差。对于正向偏差，使通过我们的努力，以我们的专业知识和信息化项目经验的积累为依托，为用户创造的价值体现。对此，也是用户选择我们的理由所在，用户是满意的。但同时，负向偏差也是不可避免和不可回避的事实，我们也做好了充分的思想准备，能够正确地去面对。负向偏差包括两类，一类是用户对结果的过高期待，这是我们要和用户开诚布公地去沟通的。因为项目毕竟受成本、工期和质量整体控制和制约，也就形成了项目范围，过高的要求应该不属于项目范围内的需求。对于第二类的具体细节的理解偏差，是可以通过沟通和交流消除的。第二类负向偏差的消除也是一项艰苦的工作，门户部分的规划、定义更是仁者见仁、智者见智，尤为难以确定。最有效的方式就是通过充分的沟通与交流，及时调整定义，最终达成共识，双方签字确认。在项目实施的各个阶段，我们和用户对交付物都进行了认真的验证，也都采用了签字确认的方式，以规范项目管理的过程。三、项目范围控制因为项目规模比较大，内容也比较多，在项目的实施阶段，我们采用了分步实施，分段交付的方式。在分段交付中，对真实的系统运行的呈现，与之前对系统的文档定义毕竟是一种完全不同的体验，同样需要用户的再次理解、认识和体验的过程，这一过程中必定会存在对系统需求理解的偏差，由此也会产生用户对系统需求变更的愿望。对于这一需求变更的管理，属于项目范围控制的范畴。由