论信息系统项目范围管理
摘要
2015 年 6 月，本人作为项目经理开始参与某医院的电子病历项目的开发，担任项目经理，承担了项目管理工作，该系统具有严格的安全，稳定，和可靠性能要求，该系统由医生站，质控，护理，临床路径以及医嘱组成，医生站护理站主要实现病历的书写功能，质控主要对病历的书写质量进行控制。医生站是整个系统的核心，采用了主流的三层架构，支持三层部署，可以方便系统的维护升级。
项目的成功很大程度上归功于本人在项目过程中对范围的管理和控制，本文结合作者的经验通过范围规划、范围定义、创建 WBS、范围确认和范围控制等过程的翔实论述，并就项目过程中采取的措施、方法作了介绍。最后，列举了该项目范围管理的一些不足之处。
正文
2012 年 6 月，本人作为项目经理开始某医院的电子病历项目的开发，主要负责项目管理，当然还做一些设计工作，主要是公用基础代码和核心代码的编写与维护。电子病历系统是按照电子病历功能规范以及建立以电子病历为核心的信息系统的方针进行的设计，主要包括病历书写，医嘱和临床路径核心功能，实现临床业务的整合，具体包括医生站，护士站，质控站，病案，护士站，查询工作站，科研工作站，临床路径工作站。通过与 HIS,LIS,PACS 等系统的集成，从而满足医护人员的临床工作。本次开发中除了临床路径是新的系统模块外，其它系统是都已经存在的，所以这次开放的重点是临床路径系统，其它系统通过客户化开放满足医院的需求。系统分三层实现，中间业务层通过 WEBSERVICE 实现，数据库采用高性能的 ORACLE 数据库，客户端采用 WINFORM 的实现技术。范围管理是项目管理的基础，也是项目管理工作的重点和难点。含糊的需求和频繁变更的范围让项目的甲乙双方吃尽了苦头。如何做好项目的需求管理与范围管理常常是项目经理最头疼的问题。电子病历项目的成功，笔者一直认为得益于有效的项目范围管理机制。在此笔者就就业网项目采取的项目范围管理的一些方法做简略介绍，望各位读者批评指正
该信息化建设系统投资规模较大，技术复杂，需求难以定义，质量要求高，而且该项目涉及的干系人面广人多。因此作为项目经理我认为应该将主要精力放在项目范围管理上，科学地运用相关理论知识并结合我司 CMMI3 项目管理过程域的具体要求，做好项目范围管理的工作，才能满足项目各方干系人对项目成功的渴求，从而带领整个项目团队走向成功。下面分别从范围规划、范围定义、创建工作分解、范围确认和范围控制等方面对项目范围管理过程和相关问题加以简要论述。
2 2 需求开发编制范围计划：
由于该项目技术复杂，最终用户繁多的特点，为了使项目顺利实施，我认为清晰分析项目的具体范围和具体工作内容至关重要，同时也为提高项目成本，时间和资源估算的准确打好基础。前期我通过的需求调研，挖掘可用需求，进而对项目的背景有了初步的了解。同时也为后期 B/S 系统的开发提供参照的作用。为了能全面识别干系人期望，我进行了需求的开发，充分识别用户提出需求，并在一定的基础上平衡干系人期望，为了实现项目目标并记录干系人需求，我们邀请了主要的跨职能干系人一起参加会议，对产品的需求集中讨论和定义.。
项目范围管理的一个非常重要的环节，规定了如何对项目范围进行定义、确认，如何创建工作分解结构，以及如何控制范围，是进行范围管理后续工作的依据和指南，需要在充分分析项目的特点基础上编制。首先我们翻阅了公司的组织过程资产库，将公司既有的范围管理计划模板拿出来，结合本项目的特点，制定出适合本项目的范围管理计划，包括制定范围定义、创建工作分解结构的方法，对各 XXX 子项目验收过程、确认内容，以及如何做到有效的范围控制。我公司近五年来对 XXX 系统集成项目建立了比较完善的档案，档案中不仅包括各大项目的范围管理实例，还包括一系列标准的模板，以及授权程序等文件，这对我们帮助很大，在此基础上结合项目章程和项目范围管理的理论我制定了项目范围计划，它规定了如何对项目的范围进行定义、确认、以及如何制定工作分解的过程
3 3 定义范围: :
项目范围管理包括项目的最终产品或服务以及实现这些产品或服务所需的各项具体工作。软件项目范围直接与需求相关，在范围过程中，“需求蔓延”是信息系统建设失败最常见的原因之一，范围管理不仅应该让项目管理和实施人员知道为，为了达到预期目标需要完成哪些具体工作，还要确认清楚项目相关各方在每项工作中清晰的分工界面和责任，详细清晰的分工界面和责任，不但有利于项目实施中的变更管理和对推进项目的发展，减少责任不清的事情发生，也便于项目结束时项目范围清晰的确认。
在对项目进行需求分析之后，了解到涉及项目干系人，用户要求界面友好、操作简便的，同时要求对全市水资源有可控性和可视性的特点，我们同水资源管理公司项目负责人、系统应用管理人员、客户和业务代表协商一致并结合项目章程，制定了初步的范围说明书和总体技术解决方案，据此在项目干系人之间建立了一个对项目范围的共识，清晰了项目的主要目标，从而项目团队能制定更详细的范围和需求计划，这对指导团队在项目实施期间的工作具有重大意义，同时也为项目团队提供一个范围基线或边界。
4 4 创建工作分解：
创建工作分解是指将项目主要的可交付成果细分成较小的、更易管理的组分。这个过程中，项目组要建立一个工作分解结构（WBS）。WBS 的建立对项目来说意义非常重大，它使得原来看起来非常笼统、非常模糊的项目目标一下子清晰下来，使得项目管理有依据，项目团队的工作目标清楚明了。如果没有一个完善的 WBS 或者范围定义不明确时，变更就不可避免地出现，很可能造成返工、延长工期、降低团队士气等一系列不利的后果。制定好一个 WBS 的指导思想是逐层深入。我先将项目成果框架确定下来，然后每层下面再把工作分解，用滚动式规划法将所有涉及到活动都进行了排序，近期要完成的工作分布在工作分解结构的最下层，远期要完成的工作分布在工作分解结构的高层，随着项目工作的不断进展，项目工作分解结构逐步清晰、明确。这种方式的优点是结合进度划分直观，时间感强，评审中容易发现遗漏或多出的部分，也更容易被大多数人理解。（根据项目的特点，我同团队成员进行充分讨论之后确定以项目生命周期作为第一层。即需求分析、系统设计、编码、测试、验收和项目管理作为第一层，将各个系统/子系统作为分解结构的第二层） 5 范围确认：项目范围管理不仅是让项目管理和实施人员知道为达到预期目标需要完成那些具体工作，还要确认清楚项目相关各方在每项工作中清晰的分工界面和责任，不但有利于项目实施中的变更管理和对推进项目的发展，减少责任不清的事情发生，也便于项目结束时项目范围清晰的确认。项目范围确认项目干系人（发起人、客户、用户）正式接受已完成的项目范围的过程，范围确认需要审查可交互物和工作成果，以保证项目中所有工作都能准确满意地完成。由于项目的范围确认贯穿于项目的始终，从 WBS 的确认到项目验收时的检验，为了保证做好各个阶段范围确认的工作，我在项目实施中，在完成计划中各重点里程碑之后，与项目干系人共同完成里程碑的检查与评审，目的是防止范围需求的偏差、遗漏，已达到在项目范围内干系人对阶段工作完成情况的正式验收。
例如在早期我们同客户确认了以下重要里程碑：概要设计、数据库设计、界面原型、接口设计、详细设计、B/S 部分编码、集成测试设计、集成测试、系统部署、系统上线、系统调整，在以上每个重点里程碑完成之后，我邀请了相关干系人，共同参加项目评审大会，我们通过项目评审发现偏差并及时记录，之后对评审问题给予跟踪解决，同时我们将最终的评审结果和偏差解决方案，以评审报告的形式上报到公司高层负责人及客户方的项目经理，并签字确认，最后将评审结果发给其他与会人员，使阶段的范围确认留下正式的书面记录。
6 6 范围控制：
是监督项目和产品的范围状态，管理范围基准变更的过程。对项目管理者来说如果范围控制不好，直接关系到项目需求的蔓延，有可能造成项目成本的提高，进度的延迟，甚至影响到项目的质量。例如项目早期需求分析过程中，我们进行需求调研之后，发现甲方并没有严格定义现在系统的新功能，造成项目在项目初期项目范围没有明确界定，为了防止范围蔓延而影响项目的进度。我在项目初期制定了变更控制流程，在需求调研基本结束开展后续工作后，所有需要进行的变更，都要严格提交变更申请单，由我和其他相关干系人组成的变更控制委员会分析对现有进度和其他因素的影响，审核是否进行变更，确定后进入项目内部使用的变更信息库，作为后续修改、跟踪、查询的依据。需求变更不可避免，但也不能一味的全盘接受，一定要在项目实施前建立好双方达成共识的游戏规则，避免项目范围失控。我在项目启动初期，就组织了省公司数据部认证支付室室经理、客户方项目经理，我方业务部门总监、项目经理、产品经理、架构师等组成 CCB 变更控制委员会，形成项目管理过程中相关变更事项的变更决策管理机制。包括项目范围在内的所有项目变更活动，都需要经过变更申请、变更评估、变更批准、变更实施、变更验证和信息同步等变更控制流程，保证包括范围变更在内的项目变更在 CCB 的控制和变更控制流程的约束下统一进行。制定常态化会议机制，定期由 CCB 成员共同讨论阶段性的变更需求，根据优先级及对项目整体的影响程度综合评估，来决定接受还是拒绝，通过严格的项目范围变更控制流程，在不排斥需求变更的前提下，实现项目范围的有序和控制，达到既及时响应客户需求，满足系统的实际需要，又是项目范围始终在可控的范围内，接受需求变更也要按照流程调整对项目进度、质量、资源、风险等方面的计划调整。
经过 11 个月的努力，水资源实时监控与管理系统终于在 2016 年 4 月 5 日完成推广培训应用，系统全面上线启用和验收，并获得用户的高度评价。总结整个项目的实施过程中，仍然存在一些不足的地方，一是需求跟踪没有仔细去做，导致经常会为了并不特别需要的功能浪费很多精力，甚至有些功能根本用不到，二是团队成员的协作程度还不高，没能最大限度的发挥团队的战斗力，在沟通管理方面还存在一些缺陷等。三是在项目范围管理计划是还应该安排更多的预留资源，以应对项目范围变更方面风险。总之项目的范围管理是整个项目管理过程的重要环节，它与项目的质量、成本、进度密切相关，对一个项目而言，只有按照项目生命周期的要求，做好各阶段的工作，才能满足项目各方干系人对项目成功的渴求。在今后的项目管理过程中，我会积极总结经验和教训，做好项目管理工作。
论信息系统项目的进度管理
[摘要]
2013年10月，我参加了某某省中国移动综合分析系统项目的建设，担任了项目经理的角色。该项目面向移动网络的各级管理、规划、维护、优化及网络分析人员，利用现有业务系统产生的海量数据资源，进行加工分析挖掘，为企业运营决策和维护优化提供信息支撑。该项目作为移动集团的战略性项目，执行一省研发多省部属的开发模式，受到了移动集团和本公司的高度重视。本人也在项目的范围管理中，结合公司要求和项目实际情况，科学的运用信息系统项目进度管理的理论知识。本文结合笔者的实践，探讨了在项目的进度管理中遇到的问题及解决方法。以活动定义、工作量及技术难度估算、识别项目关键任务、随时了解项目进度，必要时调整进度表等方面讨论了该项目进度管理的基本活动与方法。项目历时1年并于2014年11月顺利验收，系统运行稳定并具有良好的行业示范作用，在文章结束之处总结了项目管理的一些经验与不足。
[正文]
一、项目概述。
随着移动通信用户、业务种类的不断增多，移动通信网络规模不断扩大，网络资源种类、数量不断增加，终端客户对网络质量要求不断提高，网络运维面临前所未有的挑战和压力。为适应日趋激烈的市场竞争环境，全面增强网管运维支撑水平和网络服务能力，全面提高客户满意度，由此提出了建设综合分析系统，在2013年10月该项目作为重点项目启动了。
综合分析系统总投资2000万，要求在2014年10月1日前投入使用。系统采用B/S构架，研发平台采用Windows Server 2008 R2，数据库平台采用SQL Server 2008 R2，集成平台采用SharePoint Server 2013 ，数据服务器、ETL服务器、前置应用服务器均采用IBM x3755m3，存储采用IBM DS3512。该综合分析系统的主要功能包括：领导试图专题、端到端分析专题、价值小区专题、四网协同专题、数据质量专题、元数据专题、功能导航、自动化分析周报、节假日预测以及指标查找模型搜索以及小区GIS呈现（WebGIS）等通用功能。该项目的干系人涉及到客户方项目领导，客户方顾问，客户方项目负责人，我方项目领导，项目顾问，项目经理，分析设计人员，开发人员，测试人员，美工等。由此可见，该项目周期长、投资大、干系人多，有效的管理是项目成功的关键。
通过公司的项目经理竞争上岗机制，我有幸获得了公司领导与业主的信任，成为该项目的项目经理，全面主持项目的管理工作。项目历时1年并于2014年11月顺利验收，系统运行稳定并具有良好的行业示范作用。下面结合项目，分别从活动定义、工作量及技术难度估算、识别项目关键任务、随时了解项目进度，必要时调整进度表几个方面来论述。
二、 进度管理是项目管理的灵魂。
进度管理是项目控制的首要内容，是项目管理的灵魂，项目超过完成期限，其它的做的再怎么完美，也不算是一个成功的项目，同时由于信息系统项目不确定性，项目的进度控制是项目管理中最大的难点。项目进度管理与项目的质量、成本管理密切相关，其基本过程包括了以下活动：
项目活动定义：确定为完成项目必须进行的各项目具体活动和工作内容；
活动排序：根据业务逻辑，找出活动之间的依赖关系；
活动资源估算：确定在实施项目活动时要使用何种资源以及每一种资源使用的数量；
活动历时估算：资源持续时间的估算；
制定进度计划：通过对以上几点的研究和分析，进而制项目的进度计划；
进度控制：跟踪项目进度计划表，对于出现的偏差进行分析，并采取相应措施。
本人在参与该项目之前，有多个中小型企业管理信息系统的项目管理经验。做过项目经理的人都知道，项目范围边界不明确、需求定义不准确是导致项进度失控的主要原因之一，有效的项目进度管理是项目在规定工期内完成的重要保障。本人非常清楚项目管理金三角在项目管理中的重要地位，工期上的延误，往往会带来一系列的问题。如项目成本增加，质量难以保证，甚至引起合同争端，造成严重的后果。
以下是结合本人在该项目中的实际工作情况，从项目进度管理几个方面的工作进行简要论述。
三 项目进度管理工作方法
首先、定义活动并估算其工作量和技术难度
我们在定义活动并估算其工作量和技术难度上采用面向对象技术和类比法原则，先将每个子系统进行逐步分解，直到分解成基本模块（当然，分解的工作在WBS中基本完成），借鉴项目历史经验，估算出实现基本模块的技术难度和所需要的工作量，因为和以往项目相同或者相似之处我们认为没有太大技术难度，资源和时间估算上不会有太大误差。对于以往项目中没有用到的技术，我们作为重点考虑对象。一方面靠项目内部核心技术人员提前试验，另外一方面向行业内专家进行咨询并向公司申请相关的培训。比如我们在该项目中用到了数据仓库技术（ETL）和商务智能技术(BI)，在进行工作量估算之前特别邀请产品供应商过来对产品和技术进行相关介绍和培训，为工作量估算、技术难度分析提供重要依据。项目工作估算完成后，召集子系统负责人对项目进度进行讨论，获得大家对估算结果的认可。当然，在资源安排上，对于技术难度相对较大的工作，一般会安排给经验丰富的程序员，这样不至于在某个技术细节上而影响项目的整体进度。
由于本公司之前曾有多个大型管理信息系统开发经验，因此有不少的案例可供参考。如系统框架部分的组织机构、功能授权、系统登录等，甚至包括数据库设计我们都是复用以前的案例，在此基础上做一些修改。这对工作量的估算也是一个重要的参考。另外，前台的常用操作，如增加、删除、修改、查询等一系列活动各模块大体上也是相同的，我们就编写统一的类，通过传递参数的方式实现对不同的表的增、删、改、查等常用操作业务。这样我们就可以在需求分析和软件测试上多花点时间。
其次、识别关键任务。
领导试图专题是客户领导首要关注的，应优先保证开发，我们把他设为重要的里程碑。由于国庆即将来临，客户也很希望能使用节假日预测专题进行预测，我们把此专题设为优先级高的专题。同样根据重要性和优先级，比较重要的任务还有还有四网协同专题，价值小区专题、系统的原型。在进度控制时我们将其作为重点对象进行控制。
再次、随时了解项目进度。
第一、制定详细的工作进度表
在确定项目开发计划时，我们制定了详细的进度表。我们在确定每一项任务时都确定该任务的工作量、开始时间、持续时间、结束时间。同时让每个小组成员知道自己所承担任务的时间表，小组成员根据自己的任务制定自己的详细工作计划。
第二、执行严格的工作日志制度
工作日志是了解每个小组成员工作情况的很好的方式，我们要求每个小组成员对自己的工作都要做工作日志，对自己每天的工作做详细记录。每周对自己的工作进展做出结论，向项目组汇报。在做结论时，不得使用“差不多”、“大概”、“完成了90%”…等模糊字眼。而是采用某项任务“已经全部完成”、或者“90%的工作全部完成”或者“再过1天全部完成，等方式。每个小组成员对自己做出的结论负责，这样可以做到随时了解项目进度，为调整项目计划提供客观基础。
第三、设定合理的里程碑计划
同时我们在项目进度计划中根据项目设计定义了相关的里程碑，在每个里程碑我们都采取小组会议形式对本阶段的工作进行确认、总结，对本阶段的进展情况做出结论，并决定是否调整下一阶段的进度计划。
各个网管的数据抽取到本系统的数据库中定义完成为一个里程碑，抽取过来的数据经过转换放到本系统的事实表中又为一个里程碑，领导试图专题的完成也是一个里程碑等等。每个里程碑的标准在系统设计时已经定义好。
基于该项目在项目初期范围界定不明，需求难以定义和项目工期紧的原因，为了避免多次返工情况，我们选择迭代模式进行开发，设计与编码同时进行，尽量保证项目人力资源没有闲置的情况。除此之外，鼓励员工适当加班也，要手段，我们给予愿意加班和主动承担项目任务的员工多发奖金和公开表扬进行激励。
当然，在项目实施过程中，还成立变更控制委员会，来合理的控制各种变更。变更控制委员会成员包括，各小组组长、系统分析人员、系统架构师、项目经理、客户负责人。其变更控制流程具体为：当变更需求时，由项目经理提出书面的变更申请；申请提出后，由变更控制委员会来针对紧急度必要性优先级等来进行影响分析，评估是否有必要执行变更。通过审核的变更需要对相关联的工作进行重新计划，然后实施变更行。变更实施后，需要对实施结果进行确认，及时的通知干系人，并做好相关的文档归档。未通过审核的变更，也需要做好相应的归档工作，以避免以后有类似的变更提出。
经过努力，综合分析系统在原定的2014年9月底试运行成功并在11月初通过了验收。
回顾整个项目过程，虽然该项目工期长，业务复杂，干系人多等各种难题，但是通过有效的进度管理，还是多次受到公司和移动集团的表扬，并按时上线验收。但在这期间也有很多问题存在，现将主要经验教训总结如下：
1、有效的沟通和确认能事半功倍。
2、进度计划不能走过场，一定要严格执行。
3、资源紧缺时可以适当的引入外包人员。
4、建立奖惩制度，激发员工的工作热情。
5、除此之外还有很多不足，不在此一一列举。
在以后的工作中，我将继续努力学习、总结经验，更好地完成项目。