信息系统项目管理师——范围管理论文

本人参加了2019年上半年信息系统项目管理师考试，目前已经通过。论文我压了2篇，但是都没有压中，考场看到题目差点吐血，还好后面按照自己的思路也顺利过关。这里和大家分享一下我的论文资料，大家可以参考。

摘要
20xx年x月，我作为项目经理参与了深圳市某上市公司的生产管理系统项目。该项目总投资300万人民币，建设工期为10个月，通过项目的建设，实现了该公司物料管理、库存管理、生产工单、生产计划、生产派工、领料管理、账务管理。该项目是属于ERP系统下的生产管理模块，支持与公司ERP系统模块对接，满足公司个性、特殊的生产流程需求，并提高生产管理效率。在我和我的团队的努力下，该项目于20xx年x月通过了业主方的验收，赢得了用户的好评。本文将结合我的实际经验，讨论信息系统项目建设过程中范围管理的重要性，我主要从以下几个方面进行阐述：规划范围管理，收集需求，定义范围，创建WBS，确认范围和控制范围。

正文
xx市某上市公司的生产管理系统项目是该公司ERP系统的重要组成部分，目前公司ERP系统已经实现了营销、采购、人力资源、办公、财务等模块。生产管理系统项目旨在规范公司生产设备管理流程，提高生产管理效率，让生产车间取消传统线下信息（纸质或电子文档）传递，数据统一归集于ERP系统，最终使生产成本对接公司财务模块。目标是使公司生产流程无纸化、智能化、做到实时监控与管理。该项目总投资300万人民币，建设工期10个月，项目涉及跨多个职能部门包括公司业务平台部门、信息系统部门、生产管理部门、财务部门。该项目干系人包括各部门接口人员、部门领导以及我的项目组成员12人，由信息系统部门牵头对接项目的实施工作。
项目实施过程中，因生产流程定制化、复杂程度高、跨多个职能部门，根据以往我的项目经验，项目范围管理、项目成本管理、项目时间管理是项目成功的三大要素，如果调整三个要素其中一个，另外两个必定受到影响。其中项目范围管理是我们首先需要分析面对的，其中项目的各个干系人都需要明白并确认项目包括什么、不包括什么，在项目的定义与控制方面达成共识，这样有利于项目的推进，并有利于项目的成功。下面我主要对我作为项目经理在项目范围管理的六个方面对该项目进行管理的论述。
一、规划范围管理
好的开始是成功的一半。项目启动后，我先仔细阅读了项目章程，制定一份大致的项目管理计划，用于指导接下来的项目工作。然后我召集各部门相关干系人进行会议沟通，会上大家提出各自的意见和看法，我在会议上听取大家的意见并做好相关记录。会后我根据项目管理计划和记录笔记，结合对项目范围的情况了解，制定了《项目范围管理计划》和《需求管理计划》。《项目范围管理计划》主要是针对范围的定义、确认、控制和如何进行WBS分解等进行描述，而《需求管理计划》主要是针对需求的定义、确认、控制进行需求的跟踪和管理。这两份管理计划会在项目后续过程中提供类似“指南”的行动指引，确保项目的正确进行。我也同时召集小组组员，进行整个项目情况的讲解，让大家心中有数，每个人知道自己位于项目的什么位置，有一个方向感，然后大家一起朝着这个方向努力。
二、收集需求
在收集需求阶段，我先明确收集需求要做什么，收集需求旨在定义和管理用户期望，也是WBS基础。我把需求分为业务需求、干系人需求、解决方案需求等，按照访谈、观察、焦点小组的方式进行收集，并要求每个流程环节需要调研至少一周的时间，需要充分了解到一线员工的工作过程、操作习惯和可能存在的问题，并形成调研报告。我根据这些调研报告让项目组成员初步进行系统原型设计，并结合《范围管理计划》进行制定初步《需求文件》。
三、定义范围
收集需求结束后，我拿准备好的初步《需求文件》和初步的系统原型，邀请主要的项目干系人一起进行引导式研讨会。因为有系统原型，大家对系统有了比较直观的了解，自然而然的想法就多了许多，大家在会上大家互动交流，指出原型中的不足，并提出了一些新的看法观点，我根据《范围管理计划》，让大家在基本的需求上达成一致意见后，最终明确所收集的需求哪些包含在项目范围内，哪些排除在项目范围外。会后，我继续完善更新项目文件《需求文件》，并整合信息制定出《项目范围说明书》。
四、创建 WBS
我通过写邮件抄送的方式，让主要职能部门领导过目《项目范围说明书》，在得到信息系统部领导肯定回复后，我拉上小组成员进行创建WBS。创建WBS主要作用是对所要交付的内容或产品提供一个结构化的视图，让大家有一个清晰明确的工作任务。首先我们确定WBS的划分层次依据为子系统模式，各个子系统进一步按功能划分为多个工作包，工作包遵循8/80原则，即至少需要8小时完成，但是总时间又不大于80小时。分解过程中我们利用工具比如MS Project采用至上而下的方式逐层细化。比如第一层生产管理系统下面划分物料档案管理、物料库存管理、工单计划安排、生产排期、领退料管理、账务管理。第二层的物料档案管理又划分物料档案规则、物料档案基础数据、物料解析。第三层的物料档案规格又划分为数据库定义、界面设计、功能实现、接口实现、单元测试、集成测试。相同层次的工作包应有相同性质。对于 WBS中工作包的细节信息，我们在 WBS字典中加以描述，并进行编码标识。创建WBS分解有助于我们系统的分析项目层次，这是一项很重要的工作，在这一过程中我们也发现《项目范围说明书》中存在一些不明确的方面，通过创建WBS而得到明确。创建WBS工作完成后，项目范围基准就确定了。
五、确认范围
项目进行到一定阶段，在可交付成果、子功能被开发完成后，即达到了“里程碑”。我们项目先在内部对其进行评审和测试，然后再把这些成果交付给用户，这样有助于项目质量的提高。接下来和用户一起按范围基准、质量标准等要求进行审查，果然获得用户的好评，并最终正式验收。确认范围并不是那么容易的，因为项目一方面想要尽快确认范围释放资源，一方面用户觉得自己并没有看到什么可交付成果。所以验收前需要做好与用户的充分沟通，让用户明白确认范围虽然是正式的，但是并不意味着不能更改，只是更改会影响相关的进度、资源、成本上的变化。在确认范围时，对于一些局部的确认范围，我们采取邀请用户，部门领导进行评审、走查，对于里程碑式的确认范围，我们会举行比较正式的会议，相关关系人进行签字确认可交付成果。
六、控制范围
控制范围就是监督项目的范围状态，管理范围变更的过程。由于项目用户范围广、业务流程复杂、功能点多，在开发过程中避免不了范围的多次变更，如果不做好范围的控制，该项目很难在合同规定的时间内完成，预算也必然超支。按照我以往的项目经验，我在开始就重视范围的控制工作。我先是与项目主要干系人(信息部接口人)沟通在合同上明确范围变更的审批权限和变更进行的流程，并把《项目范围说明书》作为合同的附件。在项目进行过程中，如果有人提出范围变更，则需要让他们提交书面申请抄送相关干系人，并按照变更流程进行审批后才能实施。不按变更流程来的，通常比如口头和电话的变更需求，我们都需要对变更内容进行充分沟通分析，对明确在《项目范围说明书》之外的功能点进行委婉的拒绝，如果碰到项目干系人领导等提出的要求，我们也要耐心的对齐解释原因，比如人手不足，成本提高，质量下降等，避免范围的蔓延。对于变更的范围做好控制，记录变更请求，及时更新项目文件，并监管好防止出现范围镀金的情况。按照这样的控制范围的管理方式，很多变更需求得以控制，减少了项目风险，保证项目质量。用户熟悉变更流程，也懂得了我们的难处，彼此协作更加信任。
经过我们团队10个月的努力，生产管理系统项目在20xx年x月正式上线，并通过了业主方的组织的验收。项目已运行一年有余，公司生产流程运转良好，工作效率明显提升，由于打通了公司ERP系统从采购到生产再到销售的一体化资源管理，得到了公司高层的一致好评。本项目的成功得益于范围管理，但项目管理中也存在许多不足，比如人员的结婚请假，离职等原因，导致项目的进度控制上出现了一些小问题。不过由于从一开始有设置AB角，所以并没有造成特别严重的后果。经过后期的修正与快速跟进，并没有对项目产生影响。在以后的学习和工作中，我还需要不断的努力，在项目管理的道路上任重而道远，希望自己能多和同行进行交流，提升自己的业务和管理水平，争取更上一层楼。