项目变更管理论文.doc

1、武汉学院学生课程论文题 目： 项目变更管理 指导教师： 吴胜 职称： 副教授 学生姓名： 贾丹 学号： 09011266 专 业： 信息系统与信息管理 年级： 09级 二一二年五月三十日8目 录【摘 要】11 项目变更的基本概述11.1引起项目变更的因素11.2项目变更的生命周期22项目范围的变更32.1 IT项目范围变更原因32.2 范围变更控制管理过程32.3 范围变更控制管理原则53 变更管理的控制与实施53.1 控制IT项目变更的基本措施53.2 变更管理流程63.3 项目变更管理案例分析7【结束语】8项目变更管理【摘 要】近年来，IT产业以惊人的速度发展，从而使软件产业的地位在经济发

2、达国家提到了空前的高度。虽然软件产业在国内外得到了迅速发展，但是软件项目实施效果却不容乐观。调查分析表明，大约70%的软件项目超出预定开发周期，大型项目平均超出计划交付时间20%-50%，90%以上的软件项目开发费用超出预算，并且项目越大，超出项目计划的程度越高。软件项目失败的原因主要有以下三点：一是需求的不断变化。二是开发的软件不能满足用户的需求。三是软件项目的管理问题，这包括两个方面：一方面是因为缺乏完善的管理项目风险的方法；另一方面是由于软件项目规模的庞大，项目的范围难以精确确定，从而在项目开发的过程中范围不断变更，过程控制的力度不够，因此导致成本估计难以精确，进度控制困难，可靠性无法保

3、证。1 项目变更的基本概述项目变更意为项目实施过程中，因各种原因导致原计划发生变动的行为。项目的建设或应用环境是在变化的，需求和目标也可能是变化的，因此项目本身也是变化的。不管项目在准备阶段的工作做的如何细致、全面，在项目实施过程中仍然会遇到各种预料之外的变化。同时，这些需求和要求的变更在项目进程中出现的越晚，对于项目实施来说就越困难，项目成本消耗可能就越高。如果能有效地控制项目的变更，那么项目最终就能在变化的环境中成功实现。1.1引起项目变更的因素项目变更主要目的是为了保证实现建设目标，但就国内目前信息化项目建设状况而言，随意变更的现象占了很大的比例，究其原因主要来自两方面，一方面是项目从启

4、动到结束，要经过漫长的过程，中间受各种因素影响会发生多次变动行为，过多的变动往往会改变项目实施结果，使不确定性成为大概率事件；另一方面是参与建设的主体过多，业务与技术脱节，需求不明确导致建设阶段变更内容过多，这点在软件开发服务项目这种现象尤为突出，经常是在业务调研阶段需求内容很少，但当项目投入试运行后，反而个性化要求源源不断，因此造成项目被动的局面。引起项目变动的原因呈多样性，若按其来源划分，大致可分成主观和客观因素两大类，前者来自项目主体，如应项目建设方或是承建方要求进行变更；后者则是因为项目实施环境或部分项目要素变化带来的影响。IT项目中引起变更的因素有两个：一是来自外部的变更要求，如客户

5、要求修改工作范围和需求等;二是开发过程内部的变更要求，如为解决测试中发现的一些错误而修改源码甚至设计。比较而言，最难处理的是来自外部的需求变更，因为IT项目需求变更的概率大、工作量也大，特别是到项目的后期。1.2项目变更的生命周期项目从开始就处于不停的变化中，用户需求变了需要调整计划或者设计；测试发现了问题需要对错误代码进行变更；甚至人员流失了，也需要项目进行一定的调整以适应这种情况。Bug管理，需求管理，风险控制等本质上都是项目变更的一种。它们都是为了保证项目在变化过程中始终处于可控状态，并随时可跟踪回溯到某个历史状态。孤立的看单个变更（CR）的生命周期，那么它是比较简单的，大致就是提出审核

6、修改-确认这么一个过程。但变更管理并不是单纯的一个数据库记录，做个备忘而已。在这么一个简单的流程中，变更管理要能体现出它的两个重要用途，一个是控制变更，保证项目可控；另一个是变更度量分析，帮助组织提供自己的开发能力。如（图-1）图-1 项目变更生命周期的基本过程 变更生命周期中的几个主要过程和这些过程的要求 ：提出记录变更的详细信息，相当于一个备忘。需要记录的信息可能根据不同组织和不同项目的规定而不同。要点在于变更提出者能简明扼要的记录下有价值的信息，比如缺陷发生时的环境，要变更的功能等。审核审核者首先要确认变更意义，确认是否要修改；其次审核者要确认变更可能产生的影响，根据影响分析决定是否要修

7、改下变更的内容以及对项目其它方面做同步改变；最后就是指派项目成员实施该变更。实施修改根据变更要求进行修改。首先要保证修改实施是完全而彻底的，比如提了一个需求变更，不能只改了需求文档而不改代码或者用户文档。在组织分工情况下，如何协调多个小组的同步变更保证工作产品一致性正成为一个很严峻的问题。实现变更的一个初始目的就是为了项目的跟踪回溯，那么，针对变更而做的修改也应该被记录下来并被和变更关联起来，实现why、what的双向跟踪。确认确认验证变更确实得到了确实实施。查询和度量分析项目管理者需要了解项目中各个变更的当前状态，根据变更状态做出各种管理决定；度量分析变更数据，了解项目质量状况；定期进行复盘

8、，寻找变更根源，进行有针对性，甚至是制度化的改进。2 项目范围的变更项目中不可避免的会发生范围的变更，不论是在项目的开始阶段或是项目的将要结束阶段，都有可能会发生项目范围的变更，而项目范围的变更会自然而然地对项目有影响，所以，怎么样控制项目的范围变更是项目管理所需要做的一个重要内容。项目所处的阶段越早，项目不确定性就越大，项目调整或变更的可能性就越大，同时带来的代价比较低。但随着项目的进行，不确定性逐渐减小，而变更的代价、付出的人力、资源逐渐增加，就会增加决策的困难度。在实际工作中，项目实施阶段的变更原因尽管很多，但这些原因和其他阶段工作皆有密切的关联，并非在实施阶段才产生的。因此，要控制或减

9、少实施阶段的变更行为，必须要从每个阶段工作入手，尽可能减少变动因素，尽早排除隐患，使各阶段工作成果具有稳定性， 才能在实施阶段降低项目变更的可能性，实现项目建设可控管理。2.1 IT项目范围变更原因 范围变更的表现形式多种多样，如客户临时改变对功能需求的想法、项目预算发生变化等。在IT项目中，这些需求范围变更可能来自方案服务方、客户或产品供应商，也可能来自项目组内部。分析各种项目需求变更的原因主要包括一下四点：（1） 范围没有明确就开始细化。范围细化一般是由需求分析人员根据用户提出的描述性的、总结性的需求进行功能的提取并给出相应的描述。如果对用户的需求不明确、需求分析工作不到位；使得需求范围没

10、有明确就开始细化，当需求进入实施阶段需求范围发生变化，就需要作出很大的变动。（2） 系统实施时间过长。在项目漫长的实施过程中，客户由于自身业务发生变化或突然产生新的想法会不断地向项目提出新的需求，从而造成需求的变更最终影响到项目整体的范围。（3） 用户业务需求的改变。由于客户竞争激烈，运行情况不确定，需要随时对业务户环境变化做出反应，用户自然会经常提出变更的请求。（4） 系统正常升级。由于开发方自身版本升级、性能改进、设计调整等要求会产生需求变更。2.2 范围变更控制管理过程为执行变更控制，必须建立有效的范围变更流程，它对管好项目至关重要。一个项目的范围计划可能制订的非常好，但是想不出现任何改

11、变几乎是不可能的，因此变更是不可避免的，关键问题是如何对变更进行有效的控制。IT项目的生命周期分为启动、计划、实施控制和收尾5个过程。范围变更的控制不应该只是项目实施阶段考虑的事情，而是要分布在整个项目的生命周期。范围变更控制是指对有关项目范围的变更实施控制。主要的过程输出是范围变更、纠正行动与教训总结。再好的计划也不可能做到一成不变，因此变更是不可避免的，关键问题是对变更进行有效的控制。其过程如（图-2）所示图2 范围变更控制流程在发生范围变更时，首先需要向变更控制委员会（SCCB）提交范围变更申请表。并记录变更请求的相关内容。然后由控制委员会对范围变更进行相应的评估；SCCB需要对范围变更

12、请求产生的原因进行分析，精确的理解用户需求；评估系统对范围变更的接纳程度、变更的代价、变更系统总体架构甚至是产品发展的影响。在范围变更分析中还需要进行需求范围稳定性的分析。过于频繁的范围变更项目进程已经超出了需求变化范围。SCCB根据项目现有进度，进行项目范围变更进度影响、费用及项目可接受影响的程度；对项目变更排列优先级，对变更请求采取应对措施提出建议，记录风险和风险应对计划。同时与项目赞助人协商项目变更影响、解决变更请求的条件相应的费用变化以及项目赞助人可接受程度等问题，从而决定是否实施变更。实施范围变更主要过程包括有追踪所有范围变更影响的工作产品、确定是否调整需求基线、维护范围变更记录文档

13、，此外范围变更还需要进行验证，对于未通过验证将取消变更请求。2.3 范围变更控制管理原则（1） 建立需求范围基线。需求范围基线是指是否允许用户需求变更的分界线，在软件开发过程中，需求确定并经过评审后，课件里第一个需求基线。随着项目的进展需求基线也在变化；此后每次变更经过评审后，都要重新确定新的需求基线。（2） 制定简单有效的变更控制流程，并形成文档。在建立了需求基线后，提出的所有变更都必须遵循这个控制流程；同时，着个流程具有一定的普遍性，对以后的IT项目开发和其他项目都有借鉴意义。（3） 成立项目变更控制委员会（SCCB）或具体相关职能的类似组织，负责裁定接受那些变更。（4） 需求变更一定要先

14、申请然后在变更，最后经过与变更级别相当的评审确认（5） 需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保证和更新的需求一致。（6） 妥善保存变更产生的文档。3 变更管理的控制与实施 变更控制不能仅在过程中靠流程控制，有效的方法是在事前明确定义。事前控制的一种方法是在项目开始前明确定义工作范围；否则“变化”也无从谈起。另一种方法是评审，特别是对需求进行评审，这往往是项目成败的关键。需求评审的目的不仅是“确认”，更重要的是找出不正确的地方并进行修改，使其尽量接近“真实”需求。另外，需求通过正式评审后应作为重要基线，从此之后即开始对需求变更进行控制。变更控制主要任务包括：分析变更的必

15、要性和合理性；确定是否实施变更； 记录变更信息，填写变更控制单；做出更改，并交上级审批；修改相应的软件配置项（基线），确立新的版本；评审后发布新版本。3.1 控制IT项目变更的基本措施进行综合变更控制的主要依据是项目计划、变更请求和提供了项目执行状况信息的绩效报告。为保证变更的规范和有效实施，通常项目组织会采取以下措施（1） 项目启动阶段的需求范围便跟预防（2） 项目实施阶段的需求范围变更（3） 项目收尾阶段的总结3.2 变更管理流程变更管理流程通过标准统一的方法和步骤来管理和控制所有对IT生产环境有影响的变更。其主要作用是安全、快速响应用户需求的变化、通过对所有变更的正确评估，可以维护IT生

16、产环境的完整性、变更和变更实施得到正确记录，并提供审核统计、减少或消除由于变更实施准备不当等原因出现的对IT环境的破坏作用、提高资源使用率等。变更管理流程始于变更的接收，结束于变更的实施和回顾。变更控制流程主要包括四个关键控制点：授权、审核、评估、确认。在变更过程中要跟踪和验证，确保变更被正确执行。变更控制流程（图3）（1）提出RFC、评估、分类变更申请人提出RFC，由变更主管负责检查和完善其内容，通过查询配置管理数据库，进行风险等级的初步评估；并尽量提出可能与业务发生的关联的影响，已供决策参考。变更主管并对变更进行分类；如为紧急变更，则按照紧急变更子流程执行；如为简单变更，直接制定变更计划，

17、并安排实施。（2） 变更主管负责组织制定变更计划、测试变更主管安排并协调相应资源制定变更计划，包括实施计划、测试计划、回退计划、配置项更新计划等。应安排对实施计划和回退计划进行测试，随后将测试结果、实施计划、回退计划、配置项更新计划等提交给变更经理审核（3） 变更经理评估、审批变更经理接受RFC，如果确定是紧急变更，则快速完成评估、审批。对标准变更，确定变更风险等级，审阅变更实施计划、测试报告、回退计划和配置项更新计划，批准或驳回变更申请，如需要更高级别管理层的审批，则根据不同风险级别报批。（4） 变更控制委员会（CCB）/紧急变更委员会（EC）评估、审批变更经理将根据特定的变更请求成立特定的

18、CCB/EC，成员包括对该变更的评估和批准提供应有附加价值的技术人员和管理人员，审阅工作包括变更的风险、对现有服务的影响、实施计划、回退计划和配置项更新计划等，并做出批准与否的决定。如为紧急变更，则快速完成以上评估、审批。（5）管理层审批对于风险等级为“重大”的变更，在变更委员会审批通过后，必须再由变更经理报请至管理层审批。（6） 协调变更实施变更主管负责协调资源，准备实施前相关工作，组织人员按计划实施变更，变更主管监控实施过程和结果，并在必要时进行协调或做出决定。在这阶段可能需要变更经理和变更委员会成员的帮助。（7） 回顾和关闭 实施变更后，变更主管确保配置项及时得到更新，并协同变更经理负责

19、从技术、管理、业务角度去回顾变更，确保RFC得到了预期效果，并寻找改进机会或行动计划，在回顾过程中可能会需要得到变更委员会中相关领域的技术人员的帮助，随后更新变更记录并关闭RFC。图3 项目变更控制流程3.3 项目变更管理案例分析 在一个正在实施的系统集成项目中出现了下述情况：一个系统的用户向他所认识的一个项目开发人员抱怨系统软件中的一项功能问题，并且表示希望能够进行修改。于是，该开发人员就直接对系统软件进行了修改，解决了该项功能问题。变更来源有两个方面，一是用户信息系统项目需求的提出者。要求用户一次性地把需求讲清楚，并且不允许此后做任何变更，这是不现实的，开发方只能尽力减少变更，降低其影响。

20、开发人员如何解决好自己的工作产品与变更的用户需求之间的一致性，是CMM2级需求管理这个关键过程域的主要目标。变更来源的另一个方面来自开发人员自身；在工作中可能发现前期工作中有些不妥当的地方，便要修改已经确定了的设计方案或是设计的细节。存在的问题及可能产生的后果：（1） 对用户的要求未进行记录；缺乏对变更请求的记录可能会导致对产品的变更历史无法追溯，并会导致对工作产物的整体变化情况失去把握。（2） 对变更请求未进行足够的分析，也没有获得批准；缺乏对变更请求的分析可能会导致后期的变更工作出现工作缺失、与其他工作不一致等问题，对项目的进度、成本、质量方面也会产生一定影响。（3）在修改过程中没有注意进

21、行版本管理；在修改过程中不注意版本管理，一方面可能会导致当变更失败时无法进行复原，造成成本损耗和进度拖延；另一方面，对于组织财富和经验的积累也是不利的。（4）修改完成后未进行验证；修改完成后不进行验证则难以确认变更是否正确实现，为变更付出的工作量也无法得到承认。（5）修改的内容未和项目干系人进行沟通。未与项目干系人进行沟通可能会导致项目干系人的工作之间出现不一致之处，进而影响项目的整体质量。【结束语】变更管理对IT行业而言是一个关键的控制过程。它绝不是一个用于满足监管机构官僚控制的程序，事实证明对所有组织而言它都是有好处的，包括提高可用性、降低成本、服从管理、减少安全漏洞等。在实际工作中，项目

22、实施阶段的变更原因尽管很多，但这些原因和其他阶段工作皆有密切的关联，并非在实施阶段才产生的。因此，要控制或减少实施阶段的变更行为，必须要从每个阶段工作入手，尽可能减少变动因素，尽早排除隐患，使各阶段工作成果具有稳定性， 才能在实施阶段降低项目变更的可能性，实现项目建设可控管理。对于软件开发项目来说，开发的过程中不可避免的会出现范围变更，发生变更的环节也比较多，因此变更控制显得格外重要。变更控制对项目成败有直接影响，项目开发之前要明确定义范围，开发过程中要严格控制范围。对变更控制的目的并不是控制变更的发生，而是对变更进行管理，以便更好的处理变更，确保变更朝着有利于项目成功的方向有序进行。参考文献1蒋国瑞.等编著IT项目管理(第2版).电子工业出版社2011.52罗伯特格拉斯，陈河南等译.软件开发的滑铁卢M.北京：电子工业出版社，20023方德英，李敏强.信息系统项目监理机制的经济学分析J.管理工程学报，2003(4):98-1024（美）凯西?施瓦尔贝，邓世忠等 译.IT项目管理(原书第2版)M. 北京：机械工业出版社，2004.115 Davidnim.项目范围管理是项目成败的关键EB/OL.,