软件项目变更管理

软件项目变更管理（精选8篇）

软件项目变更管理 篇1

2.1 摘要.........................................................................................................................................2 2.2 提交变更申请.........................................................................................................................3 2.3 审核变更申请.........................................................................................................................4 2.4 识别变更可行性.....................................................................................................................4 2.5 批准变更申请.........................................................................................................................4 2.6 实施变更申请.........................................................................................................................4 变更任务.................................................................................................................5

3.1 变更申请人.............................................................................................................................5 3.2 变更经理.................................................................................................................................5 3.3 变更可研小组.........................................................................................................................5 3.4 变更审批小组.........................................................................................................................5 3.5 变更实施小组.........................................................................................................................5 5 变更登记.................................................................................................................6 变更模板.................................................................................................................6

Confidential

Page 1 1 概述

描述变更管理的目的。就项目中变更管理的总体流程提供一份概述，如：

变更管理流程是成功交付项目的基础。变更管理流程确保对在项目环境中的每个变更在实施以前都得以恰当的定义、评估和审批。

对项目的变更管理是通过对以下五个关键步骤的实施引入的。，:  提交和接收变更申请  审核和记录变更申请  确定变更申请的可行性  批准变更申请

 实施和结束变更申请变更流程

对将要执行的流程和程序做一个图表概述，以启动、实施项目中的变更并审核其效果。例如：Provide a diagrammatic representation of the processes and procedures to be undertaken in order to initiate, implement and review the effects of changes within the project.An example follows:

2.1 概要

下图对将要执行的变更流程和程序做了一个概述，以有效地管理与项目相关的变更。同时也明确的变更管理中的职责分工。

Confidential

Page 2 ChangeManagementProcessChangeManagementRole1.1 Changerequirementidentified1.0 SubmitChange Request1.2 ChangeRequest FormsubmittedChangeRequestor2.1 ChangeRequest Formreviewed2.0 ReviewChange Request2.2 FeasibilityStudy required?ChangeManagerNoYes3.1 ChangeFeasibility Studyperformed3.0 IdentifyChange Feasibility3.2 ChangeFeasibility StudyapprovedChangeFeasibility Group3.3 Changedocumentationsubmitted4.1 Changedocumentationreviewed4.0 ApproveChange Request4.2 Changeapproved?ChangeApproval GroupNoYes5.1 Changeimplementationscheduled5.2 Changeimplementationtested5.0 ImplementChange Request5.3 ChangeimplementationperformedChangeImplementationGroup5.4 Changeimplementationreviewed5.5 Changeclosed2.2 提交变更申请

本步骤中项目团队中的任何成员都可以提交项目变更申请，需要完成以下工作：

 变更申请人识别项目中任何方面的变更需求（如范围、可交付成果、时限、组织）. 变更申请人完成变更申请表（CRF），并将其呈交变更经理。变更申请表对需要进行的变更做一概述，包括：

 变更描述

 变更原因（包括商业驱动） 变更利益  变更成本

 变更带来的影响  支持性文件

2.3 审核变更申请

本步骤授权变更经理对变更申请表进行审核，以决定是否需要一份充分的可行性研究报告以供变更批准小组评估变更可能带来的全部影响。做出上述决定的基本依据是：

 呈交的可选择变更数目Number of change options presented  申请变更可选反性的复杂程度Complexity of the change options requested  提出的变更解决方案的衡量Scale of the change solutions proposed 变更经理将不会在变更日志中打开一份变更申请并记录是否需要一个变更可行性研究。The Change Manager will open a 慍hange Request’ in the Change Log and record whether or not a change feasibility study is required.2.4 识别变更可行性

本步骤涉及完成一份完整的变更可行性研究，以确保对所有的变更可选项进行调查并上报，变更可行性研究包括对以下各项的定义：

 变更需求

 变更可选项Change options  变更成本及利益

 变更风险及事项Change risks and issues  变更带来的影响  变更的建议和计划

对对可行性研究进行认真审核以确保研究是切题的，同时确保（经过变更后的）最终的可交付成果是可以通过的—那研究报告就可以上报变更审批小组了。变更经理将整理所有变更文件并报变更审批小组做最终审核。这些文件包括：:  原始的变更申请表

 已通过的变更可行性研究报告  所有支持性文件

2.5 批准变更申请

本步骤涉及变更审批小组对变更申请的正式审核。变更审批小组可能做出下列任何一种结论：

 拒绝变更Reject the change  要求与变更相关的更多信息Request more information related to the change  批准变更申请Approve the change as requested  在特定条件下批准变更Approve the change subject to specified conditions

决定是否变更的标准大致为：

 实施变更给项目带来的风险  不实施变更给项目带来的风险

 实施变更对项目产生的影响（时间、资源、财务、质量方面）

2.6 实施变更申请

本步骤涉及对变更的全面实施，包括:       确定变更进度（如：实施变更的日期）

实施前对变更进行测试Testing the change prior to implementation 实施变更

对实施变更的成功度进行审核 就实施变更的成功度进行沟通 在变更日志中结束变更 变更职责

对项目中启动、审核和实施变更所涉及的所有资源（包括项目中或项目之外的资源）的职责和责任进行定义，如：

3.1 变更申请人

变更申请人最初意识到对项目进行变更的必要性并就此需求与变更经理进行正式沟通。其主要职责为:  及早识别对项目进行变更的需求

 通过完成变更需求表来完成对更申请的正式文件  将变更申请表提交变更经理以供审

3.2 变更经理

变更经理对一个项目中所有的变更进行接收、记录、监测和控制。其主要职责为：

 接收所有的变更申请并将其记录于变更登记簿中  将所有的变更申请进行分类、优选

 审核所有变更申请以确定在提交变更审核小组前是否还需增加有关信息  确定是否需要进行一个正式的可行性研究并提交变更审核小组  通过委派变更可行性研究小组来启动变更可行生研

 对所有的变更申请进展情况进行监测以确保项目按时完成  将所有的变更申请问题和风险上报变更审批小组  就变更审批小组做出的所有决定进行下达和沟通

3.3 变更可行性研究（可研）小组

变更可行性小组负责完成由变更经理签发的对于某变更申请的正式的可行性研究，主要职责为：

 通过进行摸拟研究来确定变更可能的要素：成本、利益和变更带来的影响。 将变更可行性研究报告中的所有发现形成文字  对报告进行认真审核并批准交其上报。 将报告转变更经理以提交变更审批小组 

3.4 变更审批小组

变更审批小组决定是否批准变更经理转来的所有变更申请。其主要职责为：

 审核变更经理转来的所有变更申请  考虑所有变更支持性文件

 根据每个变更申请的相关价值决定批准还是拒绝  解决变更争议（当两个或两以上变更撞车时） 解决变更问题Resolving change issues  决定实施变更时间表

3.5 变更实施小组

变更实施小组对项目中所有变更的实施进行计划、落实和审核。变更实施小组主要负责：      计划所有变更的进度（在变更审批小组提供的总体时间框架范围内）)在实施前对所有变更进行测试 实施项目中的所有变更 实施后审核变更的成功度 在变更日志中请求结束变更 变更登记簿

变更登记簿是用于登记、跟踪变更申请进展情况的日志/数据库。描述项目变更登记簿的目的和用途，在下面插入一个真实的变更登记文本 变更模版

软件项目变更管理 篇2

软件项目需求变更频繁,如果控制不好,很容易导致项目失败,本文作者通过一个案例场景对软件项目中遇到的问题进行分析和研究,结合在软件项目管理中的实践和体会,提出有效方法,用以处理软件项目管理过程中因需求变更引起的问题。

案例场景

某公司为一家软件企业,承接了一个电子商务平台项目,该项目组共16人,包括1名项目经理、1名技术经理、1名产品经理、1名项目经理助理、7名开发人员、2名UI人员、3名测试人员。

项目甲方业务发展迅速,需求变更频繁,需求由公司高层和业务部门提出,但所有需求必须由公司高层确认。

项目问题分析

1频繁的需求变更

变更的原因有以下几个:

(1)由于甲方是一家刚刚起步业务发展迅速的公司,随着业务发展电子商务平台需求频繁变更;

(2)甲方需求提出方包括各业务部门和公司高层。各业务部门根据业务发展不断提出需求,但不能确定需求是否开发,必须经过公司高层决定,但业务部门和高层之间沟通信息经常不对称,高层按照自己的理解确定需求,业务部门不敢提出异议,导致最终需求未必符合业务需要;

(3)公司高层提出需求只是框架需求,没有时间细化,产品经理根据自己的理解细化需求后,高层确认时不仔细看,但产品开发出来后又提出很多不同建议,导致开发完的产品需要不断完善。

2甲方和乙方开发周期有分歧

(1)甲方高层主导需求,新的想法非常多,想法出来后希望尽快看到结果,在开发周期上和开发方经常发生分歧,导致气氛逐渐不融洽;

(2)项目经理和甲方公司高层确定需求和开发周期时经常发生冲突,但迫于企业高层关系紧密,且企业高层要求和对方要搞好关系,所以不得不接受甲方高层提出的不合理开发周期,通常用赶工的方式进行长时间疲劳工作,造成项目团队对项目失去信心和积极性。

(3)不合理开发周期导致产品质量下降,甲方高层逐渐对开发团队不满,最后导致双方高层关系恶化。

综合以上分析,该项目具备了很多不健康项目现象,例如:需求不明确;需求变更频繁;进度要求紧;对项目风险管理薄弱等。

项目解决方案分析

针对项目中存在的以上问题,进行了分析和研究,可以判断,项目问题的症结主要在项目变更控制和沟通管理上。

1项目变更控制随意性比较强,变更控制没有流程,项目范围没有确定,需求交付成果评审没有控制。需求变更管理需要完善地方:

(1)对变更需求进行严格审核。对变更需求按照紧急性、影响性进行分类,然后安排处理的先后顺序。

(2)对变更的影响进行评估,并将评估结果和客户进行沟通确认。沟通内容包括变更引起的质量、成本、进度等方面的内容。首先从进度即开发周期上和客户确认,变更一般都会引起开发周期延长;然后从成本上,大的变更不仅影响开发周期,还需要增加人员或通过赶工完成;再就是从质量上,严格讲,如果重新评估开发周期和成本,客户能够接受,质量管理到位,变更不会引起产品质量下降,但如果前两个影响客户不能接受,开发方为了不放弃项目又硬接受不合理的周期和成本,很容易造成质量下降。

2沟通管理上需要从以下几个方面进行改进:

(1)内部沟通要注意方式方法。和甲方沟通过程中的不满不要在开发团队中散布,应该适度表达,以免整个团队对项目失去信心和积极性。

(2)采用对方能接受的沟通方式。由于对方是一个非技术人员,且是一个公司高层,需求容易变化,且为框架需求,所以要多用图和原型形式让对方确认需求。

(3)沟通的升级原则。分析项目的关键干系人,不仅包括甲方高层,还要包括自己公司的高层,所以需求变更及项目情况沟通方式进行如下改进:

(1)先和业务部门沟通变更需求;

(2)再和甲方高层确认性沟通。条件是提前做好充足准备,例如:提前形成基本需求,最好能拿出原型和对方确认;

(3)定期和自己的高层沟通项目需求变更情况;

(4)鉴于企业高层关系,说服自己的高层能和甲方高层定期沟通,促进项目顺利进行;

(5)扫除沟通障碍。沟通障碍包括过多使用行话、结构化思维不强、确认环节做的不细致等。

总结

软件项目的需求变更管理 篇3

需求管理的常见误区

软件项目的范围控制应该是在需求分析阶段就开始的，然而很多项目经理针对需求分析存在不少认识误区。

误区1：开发商和用户仅就软件需求的基本轮廓达成一致即可，具体细节准备日后协商。

从项目管理角度分析，这是非常危险的，许多软件项目失败的最主要原因就是需求分析阶段对问题、流程、细节的描述不够准确，导致后期预算超支或者工期延误。

正确的方法是：在需求分析阶段，双方必须对项目的应用背景、功能需求、性能需求、可靠性需求、可用性需求、操作界面需求、外部接口需求，以及项目评审的方法、标准、过程进行全面、细致地研究讨论，逐一进行明确。

误区2：软件需求是软件必需向用户提供的功能和界面，功能上满足需求就足够了。

从软件需求工程角度分析，这只是认识到了软件系统的功能需求，忽略了软件的非功能需求和设计约束，需求捕获不够全面。软件需求工程理论认为，软件需求包括功能需求、非功能需求和设计约束三方面内容。

正确的方法是：除了要明确软件的功能需求，还需要进一步明确非功能需求（即软件产品所必备的属性和品质，包括可靠性、可用性、安全性、可扩展性、可移植性等）和设计约束（即软件研发必须遵守的特定规约、限制条件、政策标准,如软件必须采用国内自主知识产权的数据库产品）。

误区3：需求调研的对象是用户，用户就是软件产品的最终使用人员。

从项目管理角度分析，该观点缺乏对项目相关人全面、系统的认识，对用户的概念理解不到位。“用户”是一种泛称，它可细分为客户、最终用户和间接用户三种类型。例如，很多企业的一把手并不直接参与软件的采购和操作，但是其对于软件项目实际上起到了关键意义的决定作用，属于最重要的间接用户。

正确的方法是：要充分认识用户的多重性、层次性、复杂性，在进行需求调研时应首先对用户进行分析、分类，根据重要性、优先级、特殊性对各类用户进行排序；其次，是针对不同类别的用户分别制订不同的需求调研计划，全面开展需求调研。需要重点指出的是，对于由多个业务部门共同参与的软件项目，在确认软件需求时一定要得到全部参与部门的共同认可。

误区4：按照“需求、设计、编程、测试”步骤研发出的软件不必考虑需求跟踪问题。

从软件工程角度分析，这是对于需求变更过程缺乏系统的认识的表现，严格线性顺序的开发模型并不能保证各个开发阶段的工作成果与需求保持一致。实际上，由于需求变更的不可预见性和必然性，各个阶段往往以螺旋的方式渐进。

正确的方法是：需求跟踪应该贯穿于整个软件需求管理阶段，需求跟踪的目标是实现《产品需求规格说明书》和软件产品之间的双向可追溯。

做好需求工程

需求分析是软件工程项目最重要、最基础的起始阶段，为后续的规划设计阶段提供参照依据。在软件研发项目过程中一定要树立需求工程的意识，将需求视为一项系统工程。为了能够全面做好需求管理，应根据项目实际情况严格划分项目阶段，清晰界定、定义项目阶段的基线，在每个项目阶段制订、执行阶段性需求管理计划，逐一认真落实。

1．需求工程的结构及目标任务

需求工程是一个包括创建和维护系统需求文档所必需的一切活动的过程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。需求工程结构如图1所示，需求开发与需求管理的流程如图2所示。

需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。需求开发过程有3个主要活动：需求调查、需求分析、需求定义。需求开发过程可分为两个阶段：用户需求调查阶段和产品需求定义阶段，两个阶段在逻辑上通常是以迭代的形式进行的。需求开发过程产生的主要文档有《用户需求说明书》、《产品需求规格说明书》（对于软件产品而言就是《软件需求规格说明书》）。

需求管理的目的是在用户与开发商之间建立对需求的共同理解，维护需求与软件工作成果的一致性，并控制需求的变更。需求管理过程有三项主要活动：

（1）需求确认:开发商和用户共同对需求文档进行评审，双方就需求达成共识后做出书面承诺，使需求文档具有商业合同效果。

（2）需求跟踪:通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。

（3）需求变更控制:依据“变更申请、审批、实施、重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。

需求管理过程产生的主要文档有《需求评审报告》、《需求跟踪报告》、《需求变更控制报告》等。

2．需求的跟踪

需求跟踪的目的是建立与维护“需求、设计、编程、测试”过程的一致性，确保所有的工作成果符合用户需求。需求跟踪有两种方式：

（1）正向跟踪：检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。

（2）逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。

正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵。

组建变更控制管理机构

项目变更是指项目实施过程中由于环境或者其他因素的变化而对项目部分或者全部功能、性能、架构、技术指标、集成方案、进度、质量等方面做出改变。

1．变更控制管理的任务及目标

信息系统项目实施过程中变更是无法避免的。变更控制管理的任务是：建立规范、严格、可行、高效的变更控制体系机制，组建变更控制管理机构，出台变更管理制度；对用户提交的变更请求进行快速的响应、受理；及时分析、研究、评估变更的可行性、成本、代价、范围；对于确定接受的变更请求制订变更实施计划方案及配套应对措施，实施变更任务，进行变更测试检查，做好变更记录。需求变更控制的最终目标是：通过建立严格规范的变更控制管理流程,拒绝不切合实际的变更，减少变更带来的风险，防止变更范围扩大、蔓延，杜绝随意的变更申请及受理过程等。

2．变更控制管理机构的建立

组建有效的变更控制管理机构和制订配套的变更控制管理制度，是进行变更控制管理的重要基础和前提保障，否则变更控制管理将成为一纸空文。变更控制管理机构（形式上可以是“变更控制管理委员会”、“变更控制管理办公室”、“变更控制管理组”等）是一个特殊组织，对项目负责人直接负责，它不受现存的职能组织结构的束缚,可由来自不同机构、不同部门、不同专业、不同岗位的人员组成，各成员划分权限岗位、明确职责、落实责任、协同工作。一般情况下，变更控制管理机构内部应至少配备以下四种角色的成员：

项目管理人员（类似于“项目经理”）：主要负责制订项目管理制度和项目管理计划，督促、检查、落实、考核项目执行过程，做好项目干系人之间的沟通协调工作。

技术负责人员（类似于“总工程师”）：主要负责项目中信息技术平台的分析、建模、设计、测试、实现。

业务管理人员（类似于“业务经理”）：主要负责收集整理业务需求、编写需求说明书、验证和评审需求、管理和控制需求变更。

通信联络人员：主要负责项目组织内部成员之间的信息发布。

需求变更控制 管理工作程序

需求变更的目的是希望软件产品更加符合用户的需求，但是变更涉及的人员多、范围广、影响大，在进行变更控制管理时必须建立严格、规范的变更控制管理工作程序，这样才能使项目始终按照预定的方向、模式、进度进行。

需求变更控制过程中最难办的事情不是“满足用户提出的变更请求”，而是“在用户认同支持、追加项目投资经费的前提下尽快完成变更任务”。用户往往认为提出变更需求是基本权利，而软件开发商往往认为只有义务解决在《用户需求说明书》、《产品需求规格说明书》中预先定义的各类需求，除此以外都应该拒绝或者在用户追加投资的前提下解决。

现实中信息系统项目的目标是具有一定弹性的，这一点尤其重要，用户和软件开发商之间为了达成共同目标不可能针锋相对，项目管理人员需要利用高超的管理艺术、沟通技巧、人格魅力，在对立博弈的关系之中寻求最佳的平衡点。

另外，有必要强调的是，在项目实施过程中，变更处理越早，难度越小，损失越小；变更处理越迟，难度越大，损失也越大。而且，任何变更都必须经过项目建设全部相关方（建设单位、承建单位和监理单位）多方确认后才能计划实施，严禁任何一方擅自变更。对项目变更的范围要有明确的界定，而且项目建设全部相关方对变更范围的理解上都没有任何异议。

项目需求与变更管理制度 篇4

广州远程教育中心有限公司

项目需求与变更管理制度

编制：人力资源部 审核：孙炜玲 批准：谢巍

二零一三年十二月人力资源部印制

广州远程教育中心有限公司项目需求与变更管理制度

项目需求与变更管理制度

第一节总则

第一条为规范软件变更与维护管理，提高软件管理水平，优化软件变更与维护管理流程，特制定本制度。

第二条本制度适用于应用软件已开发或采购完毕并正式使用、且由软件开发组织移交给管理组织之后，所发生的应用软件运行支持及系统变更工作。

第二节变更流程

第三条软件变更工作可分为下面三类类型：软件变更审批、软件安装和修改、报表生成。软件变更审批指根据部门的需求，申请变更软件；软件安装和修改指对一些软件功能或使用上的问题所进行的修复，这些问题主要由于软件安装上的错误而引发的；报表生成指为了满足各个部门统计报表数据生成的需要，而进行的不包含在软件功能之内的数据处理工作。

第四条系统变更工作以任务形式由需求方（一般为相应部门）和维护方（一般为信息办的应用维护组织和软件供应组织，还包括合作厂商）协作完成。第五条因问题处理引发的软件变更处理，具体流程参见《审批流程图》。

第六条需求部门提出软件变更需求，使用人员参照《单位软件需求列表》自行判断，若软件是中性名单之内则直接提交给网络管理员：若软件存在于黑白名单或名单之外则将变更需求整理成《终端软件变更审批表》，由部门负责人审批后提交给网络管理员。

第七条网络管理员负责接受需求、分析需求，提出软件变更建议并根据变更建议审批《终端软件变更审批表》。

第八条网络管理员根据自行开发、合作开发和外包开发的不同要求组织实现软件变更需求，将需求提交至内部开发人员、合作开发商或外包开发商，产生供发布的软件。

广州远程教育中心有限公司项目需求与变更管理制度

第九条变更过程应按照软件变更过程规定进行。软件变更过程应遵循软件变更过程相同的正式、统一的标准，并经过申请和正式审批才能安装或变更。

第十条网络管理员组织各个部门的终端软件最终用户对软件变更进行测试，并撰写相应报告，签字确认通过。

第十一条在软件变更完成后，网络管理员和各个部门的最终用户共同撰写《软件变更验收报告》，签字验收后存档。

第十二条网络管理员负责对软件变更过程的文档进行归档管理，变更过程中涉及的所有文档应至少保存两年。

第三节紧急变更流程

第十三条对于紧急变更，需求部门可以通过电子邮件或传真等书面形式提出申请。第十四条信息办可根据重要性和紧迫性做判断，确定其优先级和影响程度，并进行相应处理。

第十五条紧急变更过程中应使用专设的网络用户账号，由专门部门或人员启动紧急修改变更程序。信息办应对紧急变更的处理进行规范的文档记录。

软件项目变更管理 篇5

一、技术变更管理需遵守的相关规定

在工程建设项目施工的过程中，任何的技术变更都和工程建设项目中的一些重要指标有着密不可分的重要关系。基于技术变更工作的重要性，在实施技术变更的过程中，工作人员必须要认真负责，对待工作要始终保持严谨的态度，务必要以工程建设项目的施工设计图作为技术变更的依据，以免导致技术变更失败，影响工程建设项目的正常施工。由此可见，工程建设项目在技术变更的过程中应当遵守以下几项规定：首先，技术变更必须满足施工计划、建设规模及相关标准。在我国，工程建设项目的正式施工，是需要经过工程建设管理部门审批后才可以开始进行的，因此，技术变更不能超过有关部门的审批范围来进行。部分发包方为了提高自身的利益，以技术变更的名义，不断扩充建筑规模，随意提升装饰装修的标准，改变相关项目的用途。最终，导致了概算超过估算，预算超过概算、决算超过预算的情况产生，不仅会使工程建设项目遭遇结算困难，还会使国家蒙受一定的经济损失。其次，技术变更要保有足够的严谨性。从实际的施工过程中可知，工程建设项目为了提高施工效率与质量，进行适当的技术变更是在所难免的。为了确保技术变更能够符合施工设计的相关标准以及工程建设项目的实际需要，必须要对技术变更的过程进行严格的监控与管理，对通过审计的工程项目内容不能随意进行变动，尤其是涉及到装修标准与建筑规模方面的内容，更不可擅自进行更改，任何擅自变更或改变建筑规模，及设备购置指标的行为都属违法行为，根据我国《建筑项目审计处理暂行规定》，上述行为一经发现，可以按照该规定的内容对建设单位进行罚款，并责令其按照原规定进行施工。最后，技术变更虽然可以提升工程建筑项目当前的施工技术水平，在一定程度上提高了项目的施工效率与质量。但是，由于技术变更经常会导致合同价格发生较大调整，一旦在技术变更过程中出现了差错，将会对整个工程建设项目的管理工作造成巨大的影响。由此看来，技术变更在实际的使用过程中，存在着一定的风险性，如果不能给予妥善的处理，加强对技术变更工作的管理，势必会对工程建设项目产生影响。所以，在工程建设项目实际的工作中，要尽可能的减少技术变更的次数。

二、工程建设项目技术变更管理的应对措施

1.强化技术变更的及时性

在国际领域，工程建设项目合同条款中，明确规定了可进行技术变更的时间范围。我国最新颁布的工程建设项目合同版本中，对于技术变更的操作程序及时间范围也进行了明确的规定。如此一来，工程技术变更就必须按照相关原则的规定来进行，不可随意进行更改，使工程项目建设的合法性与安全性得到了有效的保障。在实际的施工过程中，按照规定中的相关要求，技术变更应在正式施工开始以前便提出，对于已经完成变更审核的技术变更方案，一定要按照审核后的相关内容进行施工处理，不能擅自进行二次改动，对于施工后才发现的问题，没有时间进行工程技术变更方法提交的技术变更方案不能给予实施，否则必将会对整个工程建设项目造成影响与破坏。由此看来，工程技术变更应该具有及时性的原则。

2.确保技术变更手续完整

工程技术变更工作必须要遵守严谨性的原则，要严格按照技术变更程序来办理工程技术变更的相关手续，不能随意省略其中的步骤与工序，要确保工程技术变更手续的完整性。例如：变更方的相关资料、审核材料以及造价分析资料、变更内容资料、确认双方的印鉴等方面。完整的手续可以确保工程建设项目后期施工的顺利进行，一旦在手续方面存在着残缺，只能暂时停工进行补办，不仅影响了工程建设项目的工期，还会为建设双方带来不良的负面影响。不仅如此，工程技术变更手续不完整会导致技术变更措施方面的科学性大打折扣，严重影响了工程建设项目施工的合理性，从而导致工程技术变更的总体成本增加，无法实现工程技术变更的真正目的。因此，必须要加强工程技术变更管理，严格艳照审批相关流程进行把关，确保每一环节的完整性以及每一细节的严谨性，从而降低企业因工程技术变更而引发的审计风险。

3.确保技术变更内容的全面性

工程技术变更是对工程建设项目中一些原有的技术手段进行变革，以提高工程建设项目的施工效率及质量。因此，技术变更的内容不能存在任何含糊不清的部分，必须要保证工程技术变更在内容方面的完整性。完整的工程技术变更内容主要包括以下几个方面：第一，工程技术变更必须附带变更后相关设计构造的设计图以及施工说明，并将变更后技术手段的优势及效果以文字的形式进行说明，并要加盖设计单位相关负责人的名章以及设计单位的印鉴。第二，工程技术变更应对新技术中涉及到的数据与原技术的相关数据进行对比，突显出新技术的优势，并对计算出技术变革所需的工程量及变更价款，并在落款处表明变更日期。在实际施工过程中，部分承包方为了追求自身利益的最大化，使用不良手段对工程技术进行变更。如此一来，在工程建设项目结算时，必定会引起不必要的争端，发包人往往都会因此调入承包方所设置的圈套之中，最后损失了自身的利益。因此，在开展技术变更的过程中，要从理由、数据，特别是变更的部位、方法、造价等进行详尽的了解，以免上当受骗。

三、总结

综上所述，基于工程技术变更对工程建设项目的重要性，加强技术变更中的管理工作是十分必要的，不仅要遵守变更中的原则与相关规定，还要对技术变更中存在的问题进行全面的分析与解决。在工程建设项目未来的发展过程中，在进行技术变更的过程中务必要小心谨慎，尽可能少的进行技术变更，以降低工程建设项目中存在的风险。

作者:王云峰 单位:宝清县城镇建设管理处

参考文献

[1]安丽红.浅谈市政工程变更对工程造价的影响[J].城市建设理论研究:电子版.2016.6(07)

软件项目变更管理 篇6

1隧道工程的变更种类分析

隧道工程属于特殊的项目，其涉及到的变更种类多种多样，应该重视相关的分类情况，及时的处理相应的问题，保证合理的处理可能引发的争议问题。作为施工单位，应该全面的了解隧道工程变更条款的内容及具体的范围。1.1正规变更。当变更的指令被颁布之后，施工单位应该从安全、环保、经济等不同的角度上全面分析，合理的修正合同条款，同时明确详细的计划和规划。变更指令应该接受施工单位的详细核查，以免其属于无效指令，以至于在索赔的时候无法得到有效的补偿。1.2建设性变更。此类变更一般是遵循着暗示指令执行，或者是也因为隧道工程项目施工前拟定的合同展开合理的施工。较为常见的是不完全或者是不确切合同文件外的工程量，起源于合同中尚未出现的工程非正式批准或者是口头的指示。1.3主体变更。在初定合同范围之外涉及到大量工程项目，意指主体变更。隧道工程在施工前，都需要进行了一个总体规划的阶段，主体变更一般是经由施工单位发布相关的指令落实基本的工作。主体变更并不属于一个单一的变更过程，而是指的已经偏离原来项目时的变更。

2隧道工程的变更处理

如果施工单位接收到了变更指令，索赔时很容易就可处理，如果是接收到指令后尚未进行确认，应该由施工单位在规定的时间内发出书面信函，要求对指令进行确认。因为工程变更很容易导致工期延长，从而也会让成本费用增加，需要及时的提出索赔的要求，在特定的时间段内计算出工期延长的时间和可能增加的费用，确保施工阶段能达到具体的要求与标准。如果出现了合同争议，在进行争议评审或者是仲裁时，施工单位尚处于有利的地位，因此可以获取到对应的补偿。从经济及安全的角度上来说，施工单位应该重视这样的变更处理，保证自身的利益不会受到损害。变更应自始至终都保持能“以成本管控和变更为核心”的项目经营理念，并相应的建立了“三个基础”，也就是建立相应变更索赔领导小组，以此形成以变更策划为管理的基础;对思想进行创新，认认真真的做好相应变更的索赔工作，真正的做到全员参与索赔工作，形成以群策、群力为项目索赔的基础条件;在对各个项目进行索赔时实现共性变更作陪的程序化和个性变更索赔的差异化，将区域化经营的优势充分发挥出来，形成有效的整合资源和多方共赢的坚实基础。在这样的“三个基础”上实现“四个支撑”，即以建立相应的变更索赔小组，来实现对“注重策划、超前立项目”的支撑;以群策群力为项目索赔的基础条件，来实现“打破传统、狠抓核心”与“活用合同、突破原有紧固”的支撑;以区域化经营的优势来实现“信息共享、互通有无”的支撑。将此四项支撑作为整个变更索赔的支柱，撑起整个变更作陪工作，实现索赔工作的精准入手，来源结果的效果。以此来实现变更索赔效益最大化的目标。

3隧道工程索赔的基础

主要是依照招投标文件，全面的分析出隧道工程的实际情况，详细的分析影响到工程进度的各种因素，确定并签订施工方案及施工组织设计。还应该将基础性的工作落实到位，通过认真的研究对应的合同，全面的解释出合同约定的赔偿范围，通过明确条件及方法等等，实现相对完善的合同管理模式，保证给索赔提供较为充足的参考依据，获取更周到的数据支持。

4隧道工程索赔的基本原则

及时的分析报告资料，依照招标文件及合同的具体要求，提出索赔的意向书，在意向书中，应该包含着多个方面的内容，如索赔的项目、索赔的事由及事件发生起算的日期等等，不需要附有较为详细的计算资料及证明材料。促使监理工程师可以结合着意向书将整个事件的起因、地点及索赔的方向能够大致了解。索赔意向书在递交于监理工程师之后，还应该经由主管监理工程师及时的确认，在签字之后，需要根据工程项目的实际情况，由项目负责人及现场负责人等到达现场进行核对。索赔意向书在送交至监理工程师手中的时候，还需要及时的收集证据，如果是收集的`证据具有真实性，且理由较为充分，所涉及到的费用和工程索赔都应该附有现场监理工程师的认可记录，并且具有详细的计算资料及证明材料等。

5隧道工程索赔的具体步骤

5.1详细资料的收集。额外费用及工期延长索赔主要是因为各种事件所致，为让索赔成功的机会大大增加，索赔者应该具备充足的证据，也就是提供对应的文件，确定出额外费用的多少和工期的具体数量。合同主体应该将事件和文件视为重要的依据，及时的记录发生事件可能造成的不良影响。许多事件的出现都会使得工期及费用等大大的增加，其中会涉及到能够索赔的方面，需要寻找到引起相关事件的原因。5.2依照索赔程序严格执行。在合同管理的阶段，会涉及到部分索赔的程序，同时也会存在着时间上的具体要求，施工单位应该及时的提供对应报告，如果没有依照合同的详细标准提出索赔的通知，将会导致索赔失败。施工单位应该及时提出合理文件的相关证明，这是实现索赔的重要前提，同样也是及时的阻止相关单位拒绝索赔的关键。

6结语

隧道工程在施工阶段往往会涉及到众多的细节问题，变更索赔属于项目管理中的重要方面，想要实现合理的变更与索赔，施工单位应该清楚的认识到相关文件和资料的重要性。隧道施工工程量大，一旦出现变更问题，将会直接的影响到工程周期，甚至于给施工单位造成较大的损失，需要在变更前做好详细的调查，为变更工作的开展创造条件。此外索赔属于较为系统的工作，应该充分的了解施工图纸及合同协议的相关条款，严格的遵照合同做好索赔基础工作，根据相关的程序办事。工程索赔就是合同管理的重要环节，同时也属于项目管理中的基础内容，是施工单位获取利润的手段，只有将索赔工作做好，才能切实维护自身权益，实现效益的最大化目标。

参考文献

[1]汪伦焰，乔然，赵延超.输水隧洞围岩类别变化变更费用索赔方法研究[J].山西建筑，，43(09)：207-208.

软件项目变更管理 篇7

本文将以软件需求工程为侧重点、从软件需求变更的原因、影响、原则及管理方案为研究领域进行分析和讨论。

一、软件需求变更的主要原因分析

1、客户需求因素。

在软件的开发过程中, 客户会随着项目开发的进程逐渐达成对软件系统的深入了解和认识, 在不断的思考过后形成了新的需求信息或改进的需求信息, 进而会提出满足其新需要的软件变更条款。2、系统内部因素。在软件开发过程中, 计算机外部硬件设备、系统软件、系统数据等内部系统之间的相互适应要求都会引起软件需求的变更。这种需求变更将会以硬件设备、操作系统、系统软件等原始系统因素为基础进行更新、升级、换代, 以此确定软件设计的安全性、兼容性和准确性。3、业务环境因素。在软件开发过程中, 与软件开发相关联的制度、规范、政策等的重新改写与设定, 或是软件开发业务要求的不断改变都将会引起软件需求变更。例如, 软件的需求会随着保险制度的变化而变更, 会随着交通制度的变化而变更等等。4、需求开发缺陷因素。在软件需求开发过程中, 需求信息调查研究、需求文档的编写及评审等工作的不足都是影响软件需求变更的主要原因。

二、软件需求变更的主要影响分析

1、影响软件开发的实际进度。

频繁的需求变更不仅需要大量项目人员的支持, 还需要投入大量的经费, 如果投入的力度过大, 将会导致软件开发项目超过预期甚至导致失败。

2、影响软件开发质量的优良。

在软件开发过程中, 需求的不断变更将会导致原有的需求链断裂, 对原定需求的部分环节造成影响, 而这些影响又将导致软件开发项目设计的改变, 最终导致系统质量的下降, 开发效率的降低。

3、影响客户与开发者之间的相互合作。

软件开发是客户与开发者之间的一种相互信任、相互合作的过程。如果二者之间在软件需求变更上产生不同意见, 而且没有得到妥善的处理, 将会导致二者之间的合作关系破裂, 甚至造成软件开发中断等严重后果。

三、软件需求变更的处理原则

1、完整性原则。

完整性是软件安全的基本要点。在软件开发过程中, 要保证需求变更信息的采纳收集、汇总整理、评判审核、监视追踪等环节的完整性, 保证软件需求变更能够按照规范的流程进行操作。

2、合理性原则。

在软件开发过程中, 客户与需求分析人员将会以不同的视角、不同的态度评估需求变更条件, 要想达成软件开发的精确性, 就需要在用户需求、软件技术和整体开发能力的基础上, 达成需求变更的合理性, 实际性。

四、软件需求变更的有效管理方案

1、达成开发者与客户之间的有效沟通。

在发生软件需求变更时, 需求分析人员要与客户进行及时有效的沟通和反复的确认, 向客户说明开发建议和解决方案并制定相应的合同规范, 以此来达成对客户的承诺和软件修改后的满意度。2、制定软件需求变更信息的整理报告。在软件需求变更过程中, 要对客户需求的规范、变更后的功能、软件质量目标、变更解决方案等信息进行整理、分析和记录, 制定明确的需求分析整理报告, 以此来确保需求变更的准确性、实际性与科学性。3、进行明确、合理的人员分工。在需求变更达成协议后, 就需要对开发人员进行合理的安排和组织, 对操作人员和测试人员进行明确的分工;利用合理的需求变更管理工具, 达成整体软件项目开发的高效和优质。4、做好需求和产品特性的评审和测试工作。做好需求变更相关信息的记录后, 需求分析人员要组织开发、测试与客户等相关人员对更改后的需求进行评审和测试, 筛出掉不符合实际的变更需求, 确保需求变更流程的顺利进行。在软件变更实施的最后阶段, 要对软件产品系统进行测试, 以检验其是否满足客户的原定需求、是否达到了预期的效果和期望, 以保证更改后产品系统的基准性和安全性。

总之, 在出现软件需求变更状况时, 首要的就是与客户做好沟通和协商, 其次要做好需求变更信息的详细记录, 最后做好软件需求变更后的测试。只要做好这关键的三部, 就能够充分确保软件开发的规范化和优质化。

参考文献

[1]李厚明.软件项目需求变更风险管理[D].山东大学2012

软件项目变更管理 篇8

项目变更意为项目实施过程中，因各种原因导致原计

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

项目变更原因分析

(一)信息化项目建设过程

分析项目变更原因，需先认识项目建设过程。根据实际工作中项目的运作流程，我们将政府投资的信息化项目建设过程细化成5个阶段，即项目立项决策阶段、项目需求调研阶段、项目设计阶段、项目招投标阶段、项目实施阶段，各阶段的主要工作内容和成果见表1所示：

从下表可以看出，5个阶段的工作构成了一个完整的工作流程，每个阶段均有不同的工作成果，上一阶段的工作成果对下一阶段工作具有指导功能，整个管理过程按照规划——设计——实施的思路逐步落实，直至项目建成交付使用。项目建设管理的全过程，体现出项目各阶段之间的紧密联系。同样，这种紧密关系也体现在不同阶段产生的变动因素之间，并为这些不确定性因素的产生和扩散提供了环境。

(二)变动因素分析

通常，表1中各阶段的工作成果大多是在理想环境条件下分析得出的结论，但在实际工作中，因受条件限制，每个阶段的工作都可能会产生部分模糊性成果。而这些模糊性成果在经过流程被传递至项目实施阶段后，将会对项目施工产生影响，导致实施路线与建设目标偏离，最后不得不采取变更手段加以修正，因此造就了信息化项目动态性强、不确定性多、预计性和度量性差的特征。可以说这些变动因素就是后期项目管理变更的源头，为了更进一步分析变更原因，我们结合工作实际情况，将各阶段的变动因素进行具体分析：

1）变动因素来源之一是上一阶段的工作成果存在不确定因子，因而产生变动因素，这些因素会沿着今后的工作阶段进行传导，并存在逐级放大可能，形成“雪球效应”，冲击项目实施成果。例如，在实际工作中第1、2阶段若是对风险因素分析不足，论证也不充分，或是需求模糊，都将会直接影响第3、4、5阶段的工作成果，以致出现设计和实施方案缺陷等问题，这些问题的相应之处也会在签订合同时被忽略，其产生的后果是实施阶段对或有风险因素准备应对不足，相应措施有限，只能被动变更，变更在这里成为一件痛苦的事情；

2）变动因素来源之二是前后工作阶段成果衔接出现问题，导致新的变动因素产生，并通过次级阶段再次传导，壮大了变动因素“队伍”。例如，第1和第2阶段的成果，项目可行性研究报告和需求说明都具有严谨性，第3、4、5阶段工作应严格在这两项成果基础上进行。但在实际工作中，我们经常看到不尊重上一阶段成果的现象出现，要么是各种个性化需求源源不断，超出了可研分析报告确定的项目边界，结果使项目范围扩大到无法完成的地步，要么是项目业务使用部门在建设实施阶段脱离需求说明争先恐后提需求，条件越提越多，项目实施者觉得难以实现，这种状况下的变更已处于失控状态；

3）变动因素来源之三是新老变动因素相互影响，衍生出新的变动因素，新变动因素的特点因此具有突发性和隐蔽性，其危害性更甚。例如，项目进度被拖延是经常性事件，由于受到需求不明、设计缺陷和供应商能力等因素的影响而变动，项目进度受到影响后，其结果必然导致工期延长。在延长的时间段，由于项目未完成，政策、施工环境等变动因素在这期间皆存在变化的可能，前期在稳定性条件下做出的可行性研究报告指导性就会下降，论证的可靠性基础也会受动摇，这样就更加剧了项目的不确定性，如此反反复复的影响，将会产生项目不可控的严重后果，此时再考虑变更已晚矣。

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

项目建设管控策略

通过对近年来财政投资建设信息化项目的工作经验总结，我们认为项目管控策略的选择对有效变更管理最为重要，选择这些策略应考虑以下数点：

1）相关职能管理部门在项目建设中不可缺位，作为信息化建设主管部门，不仅要对区域内信息化建设进行统一规划，还要在项目建设的各阶段发挥统筹管理，协调推进的作用。职能管理部门的出现，能有效防止业务与技术脱节现象出现，减少项目主体的随意性影响；

项目应分阶段进行管控。在每个阶段工作中，尽可能考虑到不确定性变动因素的影响，对其给予重点关注，并有预防措施应对，这样既能容易发现变动要素，也能提前防范，将项目建设纳入可控范围；

2）第三方服务力量的作用不可忽视。因信息化建设项目牵涉面广、新技术含量高，应注重依靠第三方的专业优势，评估项目可行性，检查需求调研工作完善性，论证方案的合理性，加强现场施工的监督管理，提高对项目的把控能力；

3）慎重对待项目变更。以完成建设内容，实现建设目标为目的引导变更管理，建立由信息化职能管理部门主导，项目各方主体参与的变更评审委员会，通过对变更行为进行事前评审，事后备案管理，在充分评估变更对项目影响后进行决策，防止片面理解项目变更管理的行为出现；

4）重视基线的作用。基线即标准，对项目变更管理具有权威制约性。在项目建设工作中，应在信息化职能管理部门主导下，参照国家法规、政策和区域内相应的管理办法进行管理，分别就需求、成本、进度等建立基线，以保证项目管理变更在可控范围内。

变更管理是项目管理的一部分内容，随着政府投资信息化项目规模的扩大，项目管理的重要性也日渐突出，从近些年信息化项目的建设案例看，大多数建设者将关注点放在成本和进度上，认为只要这两方面能控制住，变更管理就是成功的，但现实却往往是朝相反的方向发展，结果与意愿相悖。究其原因，除了没有完全理解变更管理的含义，缺乏科学管理的手段外，缺少对项目建设全程管控变更的思想，没有在项目前期工作中尽量减少实施阶段的变动影响因素也是原因之一。本文提出的方法是将变更管理放到项目建设管理的全生命周期去实施，从预防变动入手，从早期控制开始，更能有效地实现管理变更，才能将项目的不确定性压至最少，风险降至最低程度。