而在信息化项目的建设中,范围管理尤为重要,它主要的研究内容是信息系统中项目范围的变化以及控制。下面是小编为大家推荐的it项目范围管理论文，供大家参考。

it项目范围管理论文范文一：论项目范围管理

摘要：2011年我作为项目经理参与了某省级报社《报业全媒体信息采集、发布和监控系统》的开发和管理工作。近年来，受网络媒体的冲击，报纸的读者、影响力和广告都呈现下滑态势。该报社希望通过打造全媒体信息采集和发布平台，运用数字化设备和系统，采用文字、图片、音视频等多种形式进行新闻采集和制作，然后通过报纸网站、手机APP、微博、微信、手机报和报纸进行全媒体报道，实现报业从传统媒体向全媒体的转型，同时该系统还设计了报业大数据存储、数据挖掘和数据监控的多项功能。整个项目开发历时1年，涉及报社本部及17个地方分社几十个部门1000余人，总投入1000万元。该项目于2012年正式上线，至今运行正常。

该项目的成功得益于我们在项目管理中始终重视范围管理是分不开的。我们通过编制范围管理计划、范围定义、范围确认、范围控制等管理过程，实现了对该项目范围的成功管理，同时我们也总结了在项目范围管理中的不足，以便在今后的工作中加以改进。

正文：整个项目历时1年，投入1000万元，涉及报社本部及17个分社几十个部门1000余人，项目组人员40余人，有系统分析人员、系统架构师、开发编码人员、美工、质量管理员、配置管理员、测试人员等等，是本公司所承接项目中规模比较大的一个。该项目于2012年1月正式上线，目前运行正常。规模大、范围广、新技术应用多、没有范例可循、涉及人员多等是该项目的主要特点。在项目开发过程中项目需求不清楚、范围变更繁多、范围控制工作艰巨是项目管理的最大问题。我们通过运用项目范围的管理方法和理论，在项目前期采用编制范围管理计划、进行范围定义、然后创建工作分解结构、实施范围验证和范围控制完成项目管理。

项目范围管理不仅是让项目管理人员和实施人员知道为实现项目目标需要完成哪些工作，还要确认相关各方在每项工作中清晰的分工界面和责任。

编制范围管理规划

编制范围管理计划是对整个项目的范围管理进行规划，确认范围定义、创建工作分解结构、范围确认、范围控制采用的规则、流程、标准和方法。我们把整个项目分为数据采集、数据存储、数据加工和发布、数据监控等四个模块，让每个模块负责人员以项目工作说明书为依据去分析相关模块的项目范围，按照公司的相关文档作为模板去分析，创建项目管理计划。主要包括详细的范围说明、创建工作分解结构的初步计划和验收确认的标准。 项目范围定义

范围定义是获得客户真正需求，编制详细的项目范围说明书，确定项目该做什么，不该做什么，为以后的项目验收打好基础。建设全媒体数字平台是报社进行流程再造的一项重要工作，对报社工作人员来说是从未接触过的新事物，因此有许多需求客户并不明确，需要项目组人员想办法去挖掘、获取、总结客户真实的需求。在这个过程中，我们采用了“头脑风暴法”和“专家判断”等方法获取项目的需求，尤其是我们对项目干系人进行了较为全面的分析，根据干系人对项目的影响力、兴趣进行识别，获得他们的需求和期望，然后对其分析、筛选、排序、量化，从而建立需求，确定项目的最终交付产品、项目验收标准、约束假设条件、项目进度里程碑等内容。

创建工作分解结构

创建工作分解结构是将项目的主要可交付成果和项目工作细分为更小的更易管理的部分。针对该项目特点，经过项目组成员商讨后，应用分解技术，我们决定以项目生命周期的各个阶段作为工作分解结构的第一层，即需求分析、系统设计、系统实施、设备检验、系统集成、调试、测试、验收为作为第一层。把第一层中的各项内容在下一层中继续进行分解，以系统设计为例，分解为网站设计、手机APP设计、微信接口设计、微博接口设计、采编系统设计、数据库接口设计等等。通过全面的工作分解结构，把复杂的项目范围分解开来，使项目人员对项目一目了然，使项目的概况和组成清楚、明晰、透明、具体。我们把工作包作为分解的最底层，规定工作包的规格不大于80小时的人工。同时编制工作字典，对工作分解结构过程进行说明。批准的项目范围说明书、工作分解结构及工作分解结构字典共同构成项目范围的基准。

范围确认

范围确认是项目干系人正式接受已完成范围的过程。包括了移动编审设计确认、网站发布系统确认、手机APP发布系统确认、网络设备验收确认等环节，对系统的总体检验作为最终交付的确认。同时规定了各阶段的交付文档。

范围控制

范围控制是控制项目范围变更的过程。项目团队以范围基准为依据，结合项目绩效信息，采用项目变更控制系统执行项目范围变更管理。报业的全媒体转型没有成熟的经验可循，在项目进行过程中客户不断提出许多的新的需求和变化，而范围变化一旦失控就会造成范围蔓延，会给项目的进度、成本、质量等方面带来很大的影响和风险。针对这些范围基准以外的需求，我们制定了严格范围变更的规范和流程。所有的变更一定要填写书面请求，填写项目申请变更单，经过变更初审、然后由项目变更控制办公室进行审批，审批通过后，告知相关干系人，执行变更，并对变更进行跟踪，对变更进行评估，以确认达到效果，同时进行配置管理，修改范围基线。

在项目进行过程中，客户提出修改移动采编客户端开发需求，提出增加安卓系统手机移动采编客户端的开发，原来的需求只需满足苹果手机客户端的开发，经过与客户的沟通以及对开发成本、进度的分析，报经项目变更控制办公室批准，在客户同意增加开发费用和延长工期的情况下，我们组织人员进行了相关模块的开发，并进行了测试和评估。

经过1年的辛勤工作，项目终于取得成功。回顾项目的管理过程，坚持正确、严格的项目范围管理是项目取得成功重要保证。总结项目工作，我们也清醒的认识到存在的不足：1.虽然有较严格的范围控制管理，但由于项目过程中新需求不断的提出，而且大都是合情、合理的需求，造成变更审批频繁，成本和工期不断追加。事后总结，应该对范围变更的审批更加严格一些，可以把一些新的需求放倒项目第二期的开发过程中。2.范围定义过程中“镀金”的现象。

论项目范围管理

【摘要】

2010年4月，我所在的单位承担了某市安全生产综合信息化管理平台的建设工作。我有幸参与了该项目并担任了项目经理，主要负责系统整体规划、组织实施和管理控制工作。 本文结合作者的实践经验就项目管理工作中的需求管理和项目范围管理进行翔实的论述，首先讨论了需求开发、需求管理和范围管理的区别与联系。以该项目为例，介绍了在项目需求管理和范围管理中所采取的措施和手段，包括制定符合项目实际情况的项目范围管理计划、定义清晰的项目需求和范围、创建WBS和WBS清单、进行项目范围确认、项目范围控制五个方面的内容。最后总结了在这个项目中，需求管理和范围管理所收到的效果和不足 之处。

【正文】 项目概述

2010年4月，我所在的单位受某市安全生产监督管理部分的委托为其开发一套安全生 产综合信息化管理平台，该平台包括安全生产监测监控系统、应急救援抢险系统、安全生产监督信息管理系统和门户网站四个系统21个子系统组成。安全生产监测监控系统实现将全市煤矿瓦斯监测数据、井下人员定位数据、重大危险源监测监控数据通过接入到应急指挥中心，实现对全市煤矿、重大危险源全天候24小时监控，将安全生产事故消灭在萌芽状态。安全生产监督信息管理系统实现将全市被监管企业信息全方位、动态化管理，为安全执法检查提供信息支持。应急救援抢险系统以地理信息平台为基础实现可视化的指挥调度、有序调度救援物资、救援力量，综合分析各种因素科学准确决策;门户网站实现各类监管信息、工作动态等发布，实现监管部门与公众互动。经过项目团队的努力工作和建设方的大力支持项目于2010年10份顺利通过验收。

需求开发、需求管理和范围管理的区别与联系

需求开发是通过调查与分析，获取用户需求并定义最终产品需求;需求管理是确保各方对需求的一致理解，管理和控制需求的变更，实现从需求到最终产品的双向跟踪;项目范围管理是确保项目包含且包含所必须完成的工作。需求管理贯穿于信息系统项目的整个生命周期，只有经过需求分析才能确定项目范围。需求的变更会引起项目范围的变更。需求管理和范围管理是项目管理工作的重点和难点。含糊的需求和频繁变动的项目范围让建设方和承建方吃尽了苦头。

1. 制定合理的范围管理计划

凡事预则立不预则废。项目范围管理计划是对如何进行项目范围控制、项目范围管理中使用工具和技术、变更决策依据等内容做出详细的规定。符合项目实际情况的范围管理计划是有效进行项目范围管理工作的前提和依据。针对该项目技术复杂、建设方信息化程度低、涉及面广等客观现实。项目启动后项目小组根据该项目的技术协议、合同、技术方案、项目管理计划为依据，利用公司其他类似项目范围计划编制的成果，编制项目范围管理计划。主要包括：包括详细的范围说明，就是实现安全生产事故提前预警、事故发生后快速响应，提高执法效率。同时包含创建工作分解结构的初步计划及验收确认等内容。项目范围管理计划编制完成后，组织公司有关方面的专家及具备类似经验的人员，经过反复讨论、审查、修改，最后形成定稿。将项目范围管理计划作为指导项目范围管理的纲领性文件，在后期执行过程中对照范围管理计划展开项目范围管理工作。

2. 定义清晰的项目需求和范围据调查显示在众多失败的信息系统项目中，由于项目范围导致的原因占了很大一部分，由于需求不明确、范围蔓延导致项目的失控。明确的、清晰表达的、切实可行的需求是需求管理和项目范围管理的基础，也是需求变更控制的基线。由于建设方信息化水平不高，最终用户对信息技术知识了解深。鉴于需求对项目范围的重要性，与该项目的销售代表对项目的背景知识进行详细了解，主要了解建设方决策层对项目的战略目标与整体要求、管理层对项目期望与支持度，项目的发起原因、发起人等。通过和销售代表的沟通对项目背景有了初步的了解，然后和建设决策层主要领导进行多次沟通后确定了项目整体目标、要实现的战略构想、总体范围。根据决策层的总体目标和战略要求，我组织团队成员对管理层人员和最终系统的使用者进行初步调研，根据初步调研的结果建立系统原型。利用原型和客户进行交流，征求使用意见，根据反馈结果对原型进行改进，优化后再次交给用户新的原型，经过多次交流和反馈，使项目团队对需求理解更加透彻，客户看到原型后，对系统有了一个直观认识，提升了客户满意度和信心。最后召开了由建设方主要项目干系人、其他相关人员、销售代表和项目团队成员需求确认会，将需求说明书提前发给参会人员，结合系统原型对需求进行讨论，形成对需求理解一致，双方对需求说明书签字确认最为后期需求变更控制的基线。

3. 创建WBS和WBS清单创建工作分解结构是将项目的主要可交付成果和项目工作细分为更小的、更易于管理的部分。根据项目特点，同项目团队成员进行充分讨论后确定以项目生命周期的各个阶段作为工作分解结构的第一层，即需求分析、系统设计、编码、测试、验收和项目管理作为第一层。将各个系统/子系统作为分解结构的第二层，然后各系统/子系统按模块组再次分解，直到最底层的工作包工作时间不大于80小时。在各个分解层次上保持项目的完整性便于管理需要，工作单元的细节信息在分解结构的字典中加以描述。在项目工作包的分解过程中我们邀请建设方代表一起参与工作任务的分解，是双方对工作任务达成一致的理解避免理解上的差异。建设方代表参与分解过程，使建设方对项目范围有了更深刻的理解，在项目后期实施中能够理解项目的进展、面临的问题。

4. 项目范围确认项目范围确认就是与建设方对项目所交付的成果和所开展的项目活动达成一致理解。很多信息系统项目由于忽视了项目范围确认工作或认为项目范围确认是走过场，最终导致执行过程中项目范围蔓延项目延期交付。范围去人是项目范围管理中非常重要的一项活动。项目的WBS分解完成后，我们组织由建设方代表、销售经理和项目团队成员组成的项目范围确认小组，依据技术协议文件、投标技术方案和项目合同对项目需求和WBS进行讨论确认。我们事先将会议资料发给参会人员，会议以原型讲解和讨论的方式进行，保证所有项目参会人员对项目交付成果的功能、目标机项目所开展的各项活动达成一致理解。最后所有参会人员对讨论修改后的项目需求和WBS进行签字确认，将确认后的项目需求和WBS作为执行过程中变更控制的基准。 5. 项目范围控制

在项目的实施过程中为了防止项目范围的蔓延保证项目顺利进行，要求建设方所有变更以书面形式提出。对于建设方提出的变更请求我们首先分析是否在既定的项目范围内，如果在项目范围内，组织相关技术骨干对造成的影响从技术、成本、进度和质量方面进行评估，根据评估结果制定应对措施。如果变更请求在项目范围外，组成有建设方代表、销售经理和相关人员进行评估决定是否变更，由建设方代表、销售经理和项目经理共同签字后方可实施变更。在项目实施过程中我们建立了周工作例会制度对项目的范围、成果和进度及时通报，对重要问题及时做出决策。邀请建设方代表参加周例会，使建设方能够不断对项目范围及已经取得的成果进行确认，避免了在项目实施后期范围变更的巨大风险。同时保证在项目过程中对重要问题及时做出决策。对关键事项我们邀请建设方代表一起参与讨论决策，增加双方沟通交流机会，使建设方代表充分了解项目的范围、实施进展、面临的问题及其解决方法，并对项目的实施形成共识，避免项目范围及进展理解上的差异，有利于项目的顺利实施。此外，根据工作任务分解阶段形成的里程碑在阶段性工作结束后对阶段工作进行评审和确认。

【总结】

项目自去年10月份至今已经1年多，在实际的应用中安全生产事故得到了有效的控制、执法水平有了明显的提升，得到了客户和公司领导的一致好评。软件项目的需求管理和范围管理是一个复杂的课题，我作为项目负责人还有很多方面需要学习。例如：在项目实施过程中虽然充分重视了需求管理和范围管理工作，但没有意识到使用成熟的项目管理模型(CMM、CMMI)去管理项目，也没有对成功的项目管理经验进行总结应用，在今后的项目管理工作中，我会严格要求自己，努力提高项目管理各方面的能力。为祖国的软件事业贡献自己微薄的力量。

it项目范围管理论文范文二：项目变更管理

【摘 要】

近年来，IT产业以惊人的速度发展，从而使软件产业的地位在经济发达国家提到了空前的高度。虽然软件产业在国内外得到了迅速发展，但是软件项目实施效果却不容乐观。调查分析表明，大约70%的软件项目超出预定开发周期，大型项目平均超出计划交付时间20%-50%，90%以上的软件项目开发费用超出预算，并且项目越大，超出项目计划的程度越高。

软件项目失败的原因主要有以下三点：一是需求的不断变化。二是开发的软件不能满足用户的需求。三是软件项目的管理问题，这包括两个方面：一方面是因为缺乏完善的管理项目风险的方法;另一方面是由于软件项目规模的庞大，项目的范围难以精确确定，从而在项目开发的过程中范围不断变更，过程控制的力度不够，因此导致成本估计难以精确，进度控制困难，可靠性无法保证。

1 项目变更的基本概述

项目变更意为项目实施过程中，因各种原因导致原计划发生变动的行为。项目的建设或应用环境是在变化的，需求和目标也可能是变化的，因此项目本身也是变化的。不管项目在准备阶段的工作做的如何细致、全面，在项目实施过程中仍然会遇到各种预料之外的变化。同时，这些需求和要求的变更在项目进程中出现的越晚，对于项目实施来说就越困难，项目成本消耗可能就越高。如果能有效地控制项目的变更，那么项目最终就能在变化的环境中成功实现。

1.1引起项目变更的因素

项目变更主要目的是为了保证实现建设目标，但就国内目前信息化项目建设状况而言，随意变更的现象占了很大的比例，究其原因主要来自两方面，一方面是项目从启动到结束，要经过漫长的过程，中间受各种因素影响会发生多次变动行为，过多的变动往往会改变项目实施结果，使不确定性成为大概率事件;另一方面是参与建设的主体过多，业务与技术脱节，需求不明确导致建设阶段变更内容过多，这点在软件开发服务项目这种现象尤为突出，经常是在业务调研阶段需求内容很少，但当项目投入试运行后，反而个性化要求源源不断，因此造成项目被动的局面。

引起项目变动的原因呈多样性，若按其来源划分，大致可分成主观和客观因素两大类，前者来自项目主体，如应项目建设方或是承建方要求进行变更;后者则是因为项目实施环境或部分项目要素变化带来的影响。

IT项目中引起变更的因素有两个：一是来自外部的变更要求，如客户要求修改工作范围和需求等;二是开发过程内部的变更要求，如为解决测试中发现的一些错误而修改源码甚至设计。比较而言，最难处理的是来自外部的需求变更，因为IT项目需求变更的概率大、工作量也大，特别是到项目的后期。

1.2项目变更的生命周期

项目从开始就处于不停的变化中，用户需求变了需要调整计划或者设计;测试发现了问题需要对错误代码进行变更;甚至人员流失了，也需要项目进行一定的调整以适应这种情况。Bug管理，需求管理，风险控制等本质上都是项目变更的一种。它们都是为了保证项目在变化过程中始终处于可控状态，并随时可跟踪回溯到某个历史状态。孤立的看单个变更(CR)的生命周期，那么它是比较简单的，大致就是提出-审核-修改-确认这么一个过程。但变更管理并不是单纯的一个数据库记录，做个备忘而已。在这么一个简单的流程中，变更管理要能体现出它的两个重要用途，一个是控制变更，保证项目可控;另一个是变更度量分析，帮助组织提供自己的开发变更生命周期中的几个主要过程和这些过程的要求 ：

提出—记录变更的详细信息，相当于一个备忘。需要记录的信息可能根据不同组织和不同项目的规定而不同。要点在于变更提出者能简明扼要的记录下有价值的信息，比如缺陷发生时的环境，要变更的功能等。

审核—审核者首先要确认变更意义，确认是否要修改;其次审核者要确认变更可能产生的影响，根据影响分析决定是否要修改下变更的内容以及对项目其它方面做同步改变;最后就是指派项目成员实施该变更。

实施修改—根据变更要求进行修改。首先要保证修改实施是完全而彻底的，比如提了一个需求变更，不能只改了需求文档而不改代码或者用户文档。在组织分工情况下，如何协调多个小组的同步变更保证工作产品一致性正成为一个很严峻的问题。 实现变更的一个初始目的就是为了项目的跟踪回溯，那么，针对变更而做的修改也应该被记录下来并被和变更关联起来，实现why、what的双向跟踪。

确认—确认验证变更确实得到了确实实施。查询和度量分析—项目管理者需能力。要了解项目中各个变更的当前状态，根据变更状态做出各种管理决定;度量分析变更数据，了解项目质量状况;定期进行复盘，寻找变更根源，进行有针对性，甚至是制度化的改进。

2 项目范围的变更

项目中不可避免的会发生范围的变更，不论是在项目的开始阶段或是项目的将要结束阶段，都有可能会发生项目范围的变更，而项目范围的变更会自然而然地对项目有影响，所以，怎么样控制项目的范围变更是项目管理所需要做的一个重要内容。项目所处的阶段越早，项目不确定性就越大，项目调整或变更的可能性就越大，同时带来的代价比较低。但随着项目的进行，不确定性逐渐减小，而变更的代价、付出的人力、资源逐渐增加，就会增加决策的困难度。

在实际工作中，项目实施阶段的变更原因尽管很多，但这些原因和其他阶段工作皆有密切的关联，并非在实施阶段才产生的。因此，要控制或减少实施阶段的变更行为，必须要从每个阶段工作入手，尽可能减少变动因素，尽早排除隐患，使各阶段工作成果具有稳定性， 才能在实施阶段降低项目变更的可能性，实现项目建设可控管理。

2.1 IT项目范围变更原因

范围变更的表现形式多种多样，如客户临时改变对功能需求的想法、项目预算发生变化等。在IT项目中，这些需求范围变更可能来自方案服务方、客户或产品供应商，也可能来自项目组内部。分析各种项目需求变更的原因主要包括一下四点：

(1)范围没有明确就开始细化。范围细化一般是由需求分析人员根据用户提出的描述性的、总结性的需求进行功能的提取并给出相应的描述。如果对用户的需求不明确、需求分析工作不到位;使得需求范围没有明确就开始细化，当需求进入实施阶段需求范围发生变化，就需要作出很大的变动。

(2)系统实施时间过长。在项目漫长的实施过程中，客户由于自身业务发生变化或突然产生新的想法会不断地向项目提出新的需求，从而造成需求的变更最终影响到项目整体的范围。

(3)用户业务需求的改变。由于客户竞争激烈，运行情况不确定，需要随时对业务户环境变化做出反应，用户自然会经常提出变更的请求。

(4)系统正常升级。由于开发方自身版本升级、性能改进、设计调整等要求会产生需求变更。

2.2 范围变更控制管理过程

为执行变更控制，必须建立有效的范围变更流程，它对管好项目至关重要。一个项目的范围计划可能制订的非常好，但是想不出现任何改变几乎是不可能的，因此变更是不可避免的，关键问题是如何对变更进行有效的控制。IT项目的生命周期分为启动、计划、实施控制和收尾5个过程。范围变更的控制不应该只是项目实施阶段考虑的事情，而是要分布在整个项目的生命周期。范围变更控制是指对有关项目范围的变更实施控制。主要的过程输出是范围变更、纠正行动与教训总结。再好的计划也不可能做到一成不变，因此变更是不可避免的，关键问题是对变更进行有效的控制。

在发生范围变更时，首先需要向变更控制委员会(SCCB)提交范围变更申请表。并记录变更请求的相关内容。然后由控制委员会对范围变更进行相应的评估;SCCB需要对范围变更请求产生的原因进行分析，精确的理解用户需求;评估系统对范围变更的接纳程度、变更的代价、变更系统总体架构甚至是产品发展的影响。在范围变更分析中还需要进行需求范围稳定性的分析。过于频繁的范围变更项目进程已经超出了需求变化范围。

SCCB根据项目现有进度，进行项目范围变更进度影响、费用及项目可接受影响的程度;对项目变更排列优先级，对变更请求采取应对措施提出建议，记录风险和风险应对计划。同时与项目赞助人协商项目变更影响、解决变更请求的条件相应的费用变化以及项目赞助人可接受程度等问题，从而决定是否实施变更。

实施范围变更主要过程包括有追踪所有范围变更影响的工作产品、确定是否调整需求基线、维护范围变更记录文档，此外范围变更还需要进行验证，对于未通过验证将取消变更请求。

2.3 范围变更控制管理原则

(1)建立需求范围基线。需求范围基线是指是否允许用户需求变更的分界线，在软件开发过程中，需求确定并经过评审后，课件里第一个需求基线。随着项目的进展需求基线也在变化;此后每次变更经过评审后，都要重新确定新的需求基线。

(2)制定简单有效的变更控制流程，并形成文档。在建立了需求基线后，提出的所有变更都必须遵循这个控制流程;同时，着个流程具有一定的普遍性，对以后的IT项目开发和其他项目都有借鉴意义。

(3)成立项目变更控制委员会(SCCB)或具体相关职能的类似组织，负责裁定接受那些变更。

(4)需求变更一定要先申请然后在变更，最后经过与变更级别相当的评审确认

(5)需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保证和更新的需求一致。

(6)妥善保存变更产生的文档。

3 变更管理的控制与实施

变更控制不能仅在过程中靠流程控制，有效的方法是在事前明确定义。事前控制的一种方法是在项目开始前明确定义工作范围;否则“变化”也无从谈起。另一种方法是评审，特别是对需求进行评审，这往往是项目成败的关键。需求评审的目的不仅是“确认”，更重要的是找出不正确的地方并进行修改，使其尽量接近“真实”需求。另外，需求通过正式评审后应作为重要基线，从此之后即开始对需求变更进行控制。

变更控制主要任务包括：分析变更的必要性和合理性;确定是否实施变更; 记录变更信息，填写变更控制单;做出更改，并交上级审批;修改相应的软件配置项(基线)，确立新的版本;评审后发布新版本。

3.1 控制IT项目变更的基本措施

进行综合变更控制的主要依据是项目计划、变更请求和提供了项目执行状况信息的绩效报告。为保证变更的规范和有效实施，通常项目组织会采取以下措施

(1)项目启动阶段的需求范围便跟预防

(2)项目实施阶段的需求范围变更

(3)项目收尾阶段的总结

3.2 变更管理流程

变更管理流程通过标准统一的方法和步骤来管理和控制所有对IT生产环境有影响的变更。其主要作用是安全、快速响应用户需求的变化、通过对所有变更的正确评估，可以维护IT生产环境的完整性、变更和变更实施得到正确记录，并提供审核统计、减少或消除由于变更实施准备不当等原因出现的对IT环境的破坏作用、提高资源使用率等。

变更管理流程始于变更的接收，结束于变更的实施和回顾。变更控制流程主要包括四个关键控制点：授权、审核、评估、确认。在变更过程中要跟踪和验证，确保变更被正确执行。变更控制流程(图3)

(1)提出RFC、评估、分类变更申请人提出RFC，由变更主管负责检查和完善其内容，通过查询配置管理数据库，进行风险等级的初步评估;并尽量提出可能与业务发生的关联的影响，已供决策参考。变更主管并对变更进行分类;如为紧急变更，则按照紧急变更子流程执行;如为简单变更，直接制定变更计划，并安排实施。

(2) 变更主管负责组织制定变更计划、测试变更主管安排并协调相应资源制定变更计划，包括实施计划、测试计划、回退计划、配置项更新计划等。应安排对实施计划和回退计划进行测试，随后将测试结果、实施计划、回退计划、配置项更新计划等提交给变更经理审核

(3) 变更经理评估、审批变更经理接受RFC，如果确定是紧急变更，则快速完成评估、审批。对标准变更，确定变更风险等级，审阅变更实施计划、测试报告、回退计划和配置项更新计划，批准或驳回变更申请，如需要更高级别管理层的审批，则根据不同风险级别报批。

(4) 变更控制委员会(CCB)/紧急变更委员会(EC)评估、审批变更经理将根据特定的变更请求成立特定的CCB/EC，成员包括对该变更的评估和批准提供应有附加价值的技术人员和管理人员，审阅工作包括变更的风险、对现有服务的影响、实施计划、回退计划和配置项更新计划等，并做出批准与否的决定。如为紧急变更，则快速完成以上评估、审批。

(5)管理层审批

对于风险等级为“重大”的变更，在变更委员会审批通过后，必须再由变更经理报请至管理层审批。

(6) 协调变更实施

变更主管负责协调资源，准备实施前相关工作，组织人员按计划实施变更，变更主管监控实施过程和结果，并在必要时进行协调或做出决定。在这阶段可能需要变更经理和变更委员会成员的帮助。

(7)回顾和关闭

实施变更后，变更主管确保配置项及时得到更新，并协同变更经理负责从技术、管理、业务角度去回顾变更，确保RFC得到了预期效果，并寻找改进机会或行动计划，在回顾过程中可能会需要得到变更委员会中相关领域的技术人员的帮助，随后更新变更记录并关闭RFC。

3.3 项目变更管理案例分析

在一个正在实施的系统集成项目中出现了下述情况：一个系统的用户向他所认识的一个项目开发人员抱怨系统软件中的一项功能问题，并且表示希望能够进行修改。于是，该开发人员就直接对系统软件进行了修改，解决了该项功能问题。

变更来源有两个方面，一是用户—信息系统项目需求的提出者。要求用户一次性地把需求讲清楚，并且不允许此后做任何变更，这是不现实的，开发方只能尽力减少变更，降低其影响。开发人员如何解决好自己的工作产品与变更的用户需求之间的一致性，是CMM2级需求管理这个关键过程域的主要目标。变更来源的另一个方面来自开发人员自身;在工作中可能发现前期工作中有些不妥当的地方，便要修改已经确定了的设计方案或是设计的细节。

存在的问题及可能产生的后果：

(1)对用户的要求未进行记录;缺乏对变更请求的记录可能会导致对产品的变更历史无法追溯，并会导致对工作产物的整体变化情况失去把握。

(2)对变更请求未进行足够的分析，也没有获得批准;缺乏对变更请求的分析可能会导致后期的变更工作出现工作缺失、与其他工作不一致等问题，对项目的进度、成本、质量方面也会产生一定影响。

(3)在修改过程中没有注意进行版本管理;在修改过程中不注意版本管理，一方面可能会导致当变更失败时无法进行复原，造成成本损耗和进度拖延;另一方面，对于组织财富和经验的积累也是不利的。

(4)修改完成后未进行验证;修改完成后不进行验证则难以确认变更是否正确实现，为变更付出的工作量也无法得到承认。

(5)修改的内容未和项目干系人进行沟通。未与项目干系人进行沟通可能会导致项目干系人的工作之间出现不一致之处，进而影响项目的整体质量。

【结束语】

变更管理对IT行业而言是一个关键的控制过程。它绝不是一个用于满足监管机构官僚控制的程序，事实证明对所有组织而言它都是有好处的，包括提高可用性、降低成本、服从管理、减少安全漏洞等。

在实际工作中，项目实施阶段的变更原因尽管很多，但这些原因和其他阶段工作皆有密切的关联，并非在实施阶段才产生的。因此，要控制或减少实施阶段的变更行为，必须要从每个阶段工作入手，尽可能减少变动因素，尽早排除隐患，使各阶段工作成果具有稳定性， 才能在实施阶段降低项目变更的可能性，实现项目建设可控管理。

对于软件开发项目来说，开发的过程中不可避免的会出现范围变更，发生变更的环节也比较多，因此变更控制显得格外重要。变更控制对项目成败有直接影响，项目开发之前要明确定义范围，开发过程中要严格控制范围。对变更控制的目的并不是控制变更的发生，而是对变更进行管理，以便更好的处理变更，确保变更朝着有利于项目成功的方向有序进行。

参考文献

[1]蒋国瑞.等编著IT项目管理(第2版).电子工业出版社2011.5

[2]罗伯特格拉斯，陈河南等译.软件开发的滑铁卢[M].北京：电子工业出版社，2002

[3]方德英，李敏强.信息系统项目监理机制的经济学分析[J].管理工程学报，2003(4):98-102

[4](美)凯西?施瓦尔贝，邓世忠等 译.IT项目管理(原书第2版)[M]. 北京：机械工业出版社，2004.11

[5] Davidnim.项目范围管理是项目成败的关键