2015项目管理师25群范围管理

1、摘要2011 年 4 月，我有幸参加了 XX 公司条形码管理系统项目，担任项目经理职位。该项目投资共 98 万务等过程的产品，工期 8 个月，为解决在生产、物流、销售和售后服管理，并对产品的识别和合法使用进行控制的 XX 公司企业业务管控系统。它以系统业务为基础，结合条形码技术，在产品的计划、生产、质检、入库、仓储、出库、等过程中，通过条码扫描，实时获取产品在每个过程中的处理信息，将产品过程信息进行实时的处理与，实现产品的序列化管理（企业生产序列号、客户管理序列号、MAC 及其他条码信息），完成对产品的生产、仓储、售后全过程的信息管理，形成一个以系统为、条码系统为外延的综合管理系统。本文结合作

2、者的实践，以 XX 公司条形码管理系统为例，项目的范围管理，主要包括范围管理计划的编制、定义范围、项目范围的分解、范围确认、范围控制等内容。正文2011 年 4 月，我参与了 XX 公司条形码管理系统项目的建设，该项目是 XX公司为解决在生产、物流、销售和等过程的产品管理，并对产品的识别和合法使用进行控制、提高产品管理能力的 XX 公司企业业务管控系统。项目建设工期为 8 个月，由 2011 年 4 月开始，到 2011 年 12 年 31日验收结束，项目总投资 98 万元。它以系统的业务管理为基础，通过在产品的计划、生产、质检、入库、仓储、出库、等过程中应用条码技术，对产品在每个过程中的生产

3、信息予以实时处理与的一个实时性系统。它与传统的系统物流与仓储业务的不同点在于：系统的仓储系统是基于产品批次管理的，即完成产品数量管理；条形码管理系统是基于产品的，并对其在生产、仓储、等过程中的信息加以管理，即单个产品的生存期管理。由于缺乏能适应企业自身制造与管理鲜明特点的产品生存期管理的行业内成熟，故本系统为一个全定制。而且，企业也没有相应的系统可供借鉴，开发合作方也缺乏大型企业制造业务应用的相关开发经验，故该项目项目范围管理显得尤为重要，有效地定义项目范围，并与项目干系人达成理解上的一致，可以有效降低项目的风险。因此，如何界定系统范围、有效地提炼系统需求，在成本、资源、时间投入有限的情况下，

4、有效地做好项目管理，是项目成败的关键。当然一个好的项目管理方法，也是提高项目成功率的一个。1、编制项目范围计划有了计划才会有一切。作为一名成功的项目管理者，在做任何事情之前都应事先做好计划，好的计划，是成功实施项目的基础；有的人认为，做范围计划花费了太多的时间与精力，还不如把它用于执行工作，项目将会更快更好地完成。我认为这是一个极错误的想法，通过省略范围计划的制订，虽然在短时间内能节省一些时间，但在较长的时间来看，却会由于缺乏项目范围计划的指导而造成项目范围定义不清、范围蔓延，从而导致项目迟迟不能完工。因此，在该项目中，我非常重视项目范围计划的制订工作。首先，我查找了公司的组织过程资产，找出制

5、订范围计划的相关模板，结合以前做过的其他项目的经验，制订了一份初步的项目范围计划；然后，召集项目团队成员，对该计划进行修改与完善，在全员参与下，最终完成了一份详细的、科学的范围管理计划，用于指导项目定义、分解和控制项目范围。2、定义范围一个成功的项目，它应该做且只能做完成项目所必需的全部工作，为了保证这一点，就需要在项目前期定义一个明确的范围。在此，我和团队，深入生产、质检、仓储、销售、售后等业务处理一线，了解、分析他们的工作流程，了解、抽象他们的需求，并多次组织项目团队与业务管理者之间的。在该调研过程中，客户有时候需求描述的不是十分清楚，造成双方对需求的不一致理解，甚至有时候客户自已都说不清

6、自已的需求，特别是对于业务报表，经常以“满足全方位的业务查询”来说明自已的需求，对此，就要根据客户的业务应用场景、向的纸质报表、向管理部门的报送统计数据等进行分析与综合，以及未来可能的需求，明确相应的查询条件、报表生成规则与数据来源，明确报表数据粒度，形成相应的数据要求说明；在充分挖掘用户需求的基础上，通过基于项目团队的经验与技术水平，对用户的需求进行引导、细化，使用用户模糊的需求明晰化、粗放的需求具体化。基于需求文件，组织项目干系人进行开会，同时邀请了 XX 公司业务管理，对系统功能进行评价，站在用户角度上，去发现和改进系统的功能，最终形成了完整的项目范围说明书。(1)、项目的产品范围描述，

7、包括生产计划定义、生产扫描、质检处理、仓储管理、售后管理等；、项目的主要可交付成果，包括用户文档、应用系统、源代码等；、产品验收标准，如系统运行稳定、功能满足业务需要、相关文档齐全等； (4)、项目约束条件，如本系统仅针对产成品进行管理，如果扩展到原材料，则必须增加经费、延长项目时间；(5)、项目目标、总3、项目范围的分解、资源及主要里程碑等。基于项目范围说明书开始对项目范围进行分解，以形成本项目的 WBS。在分解过程中，主要依据下述原则进行：在各层次上保持项目的完整性。对于该项目涉及的需求调开、系统设计、开发、测试等完整的模块一一列出，避免遗漏主要的部分。一个工作单元只从属于一个上层单元。对

8、于项目的数据库设计，我就只将其归属于系统设计单元，其他单元就不在重复出现，避免交叉从属。工作单元应能分清不同的工作内容与不同的责任者。对于该项目的每个工作包，我都指定不同的和其负责的工作内容。便于项目进行计划和控制的管理需要。对于该项目的每个工作包，我都对期进行，并与组织结构图与成本控制点深度融合，便于项目的后期管理。遵循 880 原则。WBS 最低层次的工作单元就是工作包，对每个工作单元，我参照 8/80 小时的原则，将其细化为具体的工作包，并指定其。同时制作WBS 字典，对工作包进行具体描述。4、确认范围范围确认不是件容易的事。在与客户的沟通上，希望能尽快确认以便尽快开展后续的工作，而客户

9、则认为，我什么东西都没有看到，如何确认？针对这种情况，文档提交相关的干系人后，重点与企业业务，详细介绍系统的设计思路与业务处理流程，然后用他们去影响企业业务管理层；同时与用户时，重点强调，虽然范围确认是正式的，但并不意味着项目的范围就不能修改了，只要走标准的变更流程，且通过，都是可以变更的。这样就消除了客户顾虑，快速、高效地完成了范围确认。5、范围控制控制范围就监督项目的范围状态，管理范围变更的过程。因此，在项目中，我定期组织召开项目状态会议，项目的范围，找出范围偏差，分析偏差，纠正偏差，严格杜绝一切范围蔓延。从事项目管理的我深知，项目范围不是一经定义，就一成不变的。项目干系人出于各看自利益及各种情况考虑，总会有一些需求变更，管理这些变更，就需要在项目规划时，制订好相应的变更控制流程，以及成立一个变更控制CCB。因此，在项目早期就制定了一套标准的变更流程：(1)、提交变更申请；(2)、对变更进行评估；(3)、报 CCB 进行；(4)、实施项目变更；(5)、验证项目变更并调整项目基准；(6)、将变更信息通知相关干系人；(7)、并审核变更的结果。有了这些流程以及 CCB 的控制，项目的需求变更得以良性发展，变更带来的是的项目收益及效率的。经过我和团队的努力 ，该项目于 2011 年 10 月试运行成功，并于同年12 月通过客户组织的验收，得到了用户的好评，了 XX 公司的市