需求变更
需求变更与变更管理

详细描述:该软件开发项目在需求变更管理方面采取了有效的措施,包括明确变 更流程、加强与客户的沟通、及时响应变更请求等,成功地应对了各种需求变更 ,确保了项目的顺利进行。
案例二:某项目管理中的需求变更处理
总结词:积极应对
详细描述:在某项目管理过程中,团队积极应对需求变更,通过制定详细的需求变更计划、加强团队沟通与协作、优化资源 配置等措施,有效地处理了各种需求变更,确保了项目的质量和进度。
决策依据
综合考虑变更的利弊、资源投入和风 险等因素,做出是否批准变更的决策 。
需求变更实施
制定实施计划
根据决策结果,制定详细的实施计划,包括实施时间、负责人和实施步骤等。
协调资源
确保所需资源到位,协调各方面工作,确保变更顺利实施。
需求变更验证
验证实施效果
对已实施的变更进行验证,确保其达到预期效果。
需求变更管理技术
01
需求变更影响分析
分析需求变更对项目范围、时间、成本和质量等方面的 影响,以便评估变更的可行性和优先级。
02
需求变更评审
对需求变更进行评审,确保变更的合理性和可行性,并 确定是否需要调整项目计划和资源。
03
需求变更控制
建立需求变更控制流程,包括变更申请、评估、批准和 实施等环节,确保变更过程的有序和规范。
反馈与改进
收集项目干系人的反馈意见,持续改进需求变更管理流程。
04 需求变更管理工具和技术
需求变更管理工具
需求管理工具
这类工具用于记录、跟踪和管理需求变更,包括需求变更的提出、评估、批准或拒绝等 过程。常用的需求管理工具有Doors、Jira等。
配置管理工具
这类工具用于维护和追踪软件配置项,包括源代码、文档和数据等。常见的配置管理工 具有Git、SVN等。
需求变更管理

需求变更管理需求变更是指在项目开发过程中,对于已经确定的需求进行修改、添加或删除的过程。
在项目实施过程中,需求变更是不可避免的,因为随着项目的推进,客户或业务方往往会提出新的需求或对旧的需求提出修改。
因此,良好的需求变更管理对于项目的成功实施至关重要。
本文将介绍需求变更管理的重要性以及如何有效地进行需求变更管理。
一、需求变更管理的重要性需求变更管理对项目的成功实施有着重要的影响,具体体现在以下几个方面:1. 控制项目范围:需求变更管理有助于控制项目的变化范围,防止项目范围的无限扩大。
通过有效地管理需求变更,可以确保项目团队专注于核心的需求,避免项目目标的偏离,从而提高项目的成功率。
2. 提高项目交付质量:需求变更管理可以帮助项目团队准确理解客户的需求,及时响应变更请求,并将变更及时反馈给开发团队。
通过及时处理需求变更,可以有效地提高项目交付的质量,并满足客户的期望。
3. 避免项目风险:未经控制的需求变更可能导致项目进度延迟、成本增加以及质量下降等风险。
通过有效地进行需求变更管理,可以及时发现潜在的风险并采取相应措施,最大限度地减少项目风险。
二、需求变更管理的步骤要有效地进行需求变更管理,可以按照以下步骤进行操作:1. 变更请求的提出:客户或业务方需求变更的提出应以书面形式进行,并明确说明变更原因、变更内容以及对项目的影响等信息。
项目团队应及时接收变更请求,并对变更相关信息进行记录和分析。
2. 变更请求的评估:项目团队应在接收变更请求后,对变更的合理性、可行性进行评估。
评估的内容包括变更影响的范围、项目进度和成本的调整等。
根据评估结果,可以对变更请求进行初步筛选和分类。
3. 变更请求的审批:经过初步评估后,项目经理或相关决策者应对变更请求进行审批。
在审批过程中,需要综合考虑项目的目标、价值以及变更可能带来的影响等因素。
审批结果应及时通知变更提出方,并在变更请求中注明是否批准以及批准的条件。
4. 变更实施与验证:在变更获得批准后,项目团队应根据变更请求的内容,进行相应的变更实施工作。
客户需求变更处理流程

客户需求变更处理流程一、需求变更申请阶段1.客户向项目经理或相关负责人提出需求变更申请,并提供详细的理由和变更内容。
2.项目经理评估需求变更的影响,包括对项目进度、成本和资源的影响,并与客户进行沟通和协商。
二、需求变更评审阶段1.项目经理召集项目团队成员、相关利益相关者和决策者,组成需求变更评审委员会。
2.需求变更评审委员会评估需求变更的可行性,包括技术、经济和可操作性等方面的考量。
3.需求变更评审委员会根据评估结果,决定是否接受需求变更,以及对变更进行的调整和限制。
三、需求变更确认阶段1.项目经理与客户就需求变更进行最终确认,包括调整后的需求内容、变更后的进度和成本等方面的沟通和协商。
2.双方达成一致后,由客户签署需求变更确认文件,确认变更后的需求和相关条款。
四、需求变更实施阶段1.项目团队根据客户需求变更确认文件,制定变更后的项目执行计划。
2.根据变更后的计划,项目团队对需求进行调整,并进行相关的开发、测试和部署工作。
3.项目团队与客户保持密切的沟通和协作,确保需求变更的顺利实施。
五、需求变更控制阶段1.项目团队建立合适的需求变更控制机制,跟踪和管理所有需求变更的情况。
2.项目经理定期对变更情况进行汇总和分析,评估变更对项目的影响,并与客户进行沟通和协商。
3.在变更控制委员会或相关决策机构的指导下,对需求变更进行审查和批准,确保变更的合理性和可行性。
六、需求变更关闭阶段1.项目团队完成所有的需求变更工作,并进行相应的测试和验证。
2.客户对变更后的需求进行验收,并确认需求变更是否达到预期效果。
3.项目经理与客户进行项目总结和回顾,总结经验教训,为以后类似项目的实施提供参考。
以上是一个较为完整的客户需求变更处理流程,通过规范化和标准化的流程,可以确保客户需求变更的有效管理和控制,提高项目实施的质量和效率。
同时,在实施过程中,保持与客户的良好沟通和协作,是确保需求变更成功的关键因素之一。
需求变更流程说明

需求变更流程说明1.需求识别和评估需求变更通常从项目干系人或相关方提出,项目团队需要对变更请求进行认证和评估。
在这一阶段,团队会评估变更的影响程度、风险和成本,以确定是否需要进行需求变更。
2.变更需求提案如果经过评估后变更请求被认可,项目团队将起草一份变更需求提案。
提案中应包括变更的原因、具体内容、预计的成本、时间和资源需求,以及变更会对项目目标和已有需求的影响。
提案还应说明变更对项目进度和资源分配的影响。
3.变更需求审批一旦变更需求提案完成,项目经理或决策委员会将对提案进行评审。
评审过程中,将评估变更需求对项目目标的影响,包括时间、质量和成本。
决策委员会将根据评审结果,决定是否批准变更需求。
4.变更需求分析在变更需求得到批准后,项目团队将进行需求分析和详细设计。
在这一阶段,团队需要进一步明确变更需求的范围、界限、功能和接口要求,以确保变更能够被准确地实施。
5.变更需求实施一旦变更需求分析和设计完成,项目团队将开始执行变更方案。
在执行过程中,团队需要对变更的实施进行跟踪和监控,并确保变更的适时交付和符合质量要求。
6.变更需求验证和验收在变更实施完成后,项目团队将对变更进行验证和验收。
验证过程中,团队将核实变更是否满足了原始需求,并进行相应的测试。
验收过程中,团队将向干系人和相关方展示变更的结果,并取得他们的认可和接受。
7.变更需求文档更新在变更需求验证和验收完成后,项目团队将对变更需求文档进行更新。
更新后的需求文档应包括变更的详细说明、实施过程中的问题和解决方案,以及最终的实施结果。
8.变更需求的变更控制在变更需求实施后,项目团队需要对变更进行跟踪、监控和控制。
如果在实施过程中出现了问题或变更需求不符合预期的影响,团队需要及时采取纠正措施,并对变更的过程进行反思和总结。
以上是一个完整的需求变更流程说明,通过明确的流程和步骤,可以帮助项目团队更好地应对需求变更,确保变更的实施正确和有效。
需求变更与优化方案

需求变更与优化方案一、需求变更分析在过去的一段时间里,我所负责的项目经历了一些需求的变更。
通过对需求变更的分析,我们可以看到这些变更的原因,以及对项目的影响。
1.1 需求变更的原因需求变更的原因主要有以下几个方面:(1)用户反馈:用户在使用产品过程中提出了一些改进的建议和意见,这些意见有助于提高产品的用户体验和功能完善度。
(2)市场变化:市场需求和竞争环境随时都在发生变化,需要我们及时响应,通过对产品进行调整和优化,以满足市场的需求。
(3)技术更新:随着技术的不断发展,我们也需要不断地进行技术升级和优化,以适应新的技术要求和提高产品的性能和稳定性。
1.2 需求变更的影响需求变更对项目的影响主要表现在以下几个方面:(1)时间成本:需求变更可能导致项目的进度延迟或重新调整,增加了项目的开发时间和成本。
(2)资源调配:需求变更可能需要重新调配项目资源,使得项目团队需要重组或增加新的成员,以满足新需求的开发和测试要求。
(3)风险管理:需求变更也带来了一定的风险,需要对变更进行评估和管理,以避免对项目的不利影响。
二、优化方案提出为了应对需求变更带来的影响,我们需要制定相应的优化方案。
以下是我针对需求变更提出的一些优化方案:2.1 需求管理优化在需求管理方面,我们可以借助一些工具和方法来提高需求的收集、分析和管理效率,以减少需求变更的次数和影响。
(1)需求调研:在产品开发之前,进行充分的市场调研和用户需求分析,确保对用户需求进行准确的把握和理解。
(2)需求评估:对需求进行评估和筛选,判断需求的优先级和可行性,避免不必要的需求变更。
(3)需求管理工具:使用专业的需求管理工具,对需求进行统一的管理和跟踪,及时反馈和处理用户的需求变更。
2.2 项目管理优化在项目管理方面,我们可以优化项目的组织和协调,以适应需求变更带来的挑战。
(1)敏捷开发方法:采用敏捷开发方法,迭代式地开发和交付产品,能够更好地应对需求变更和快速响应用户反馈。
需求变更管理

需求变更管理需求变更是项目管理中常见的一种情况。
随着项目的进行,需求可能会发生变化,这需要及时响应并进行有效管理,以确保项目的成功交付。
本文将探讨需求变更的管理方法及其重要性。
一、需求变更的定义和原因在项目开展过程中,需求变更指的是经过全面分析和确认的需求,在项目执行过程中随着环境变化、利益相关方需求变化、项目目标调整等因素的影响,发生了修改或补充的情况。
需求变更的原因多种多样,包括但不限于以下几点:1. 新的业务要求:随着业务的发展,企业往往需要面对新的市场需求,这可能需要调整项目的原有需求。
2. 外部影响:项目周边环境的变化,如法律法规、技术标准、市场竞争等,可能导致项目需求发生变更。
3. 内部需求:项目执行过程中,项目团队成员或利益相关方对需求的理解与初衷不一致,需要进行调整。
二、需求变更管理的流程有效的需求变更管理流程可以帮助项目团队及时并有效地处理变更请求,确保项目的顺利进行。
以下是一个常见的需求变更管理流程:1. 变更请求的收集:项目团队应设立适当的渠道,接收项目各方提交的变更请求。
这可以通过会议、需求管理工具、邮件等方式完成。
2. 变更请求的评估:项目团队应对收集到的变更请求进行评估,包括变更的影响范围、风险评估、成本估算等。
评估结果将有助于决策者确定是否批准变更请求。
3. 变更请求的决策:基于评估结果,决策者将根据项目目标、计划、资源等因素综合考虑决策是否批准变更请求,并及时向相关方通报决策结果。
4. 变更的实施和控制:一旦变更请求被批准,项目团队需要制定变更的实施计划,并严格控制变更的过程。
在实施过程中,项目团队需要监测变更的影响,及时采取措施保证项目进展。
5. 变更的验证和确认:当变更实施完成后,项目团队应对变更进行验证,确保变更带来的功能实现、质量提升等目标达到预期。
三、需求变更管理的重要性需求变更管理在项目中扮演着重要的角色,具有以下几个方面的重要性:1. 防止项目滞后:如果项目中的需求变更得不到及时管理,可能会导致项目目标的模糊、资源的浪费,从而使项目延期或超预算。
需求变更的基本流程

需求变更的基本流程需求变更是指在项目实施过程中,由于各种原因导致项目需求发生调整或修改的过程。
在项目开发中,需求变更是一种常见的现象,它可以是客户需求的变化、项目目标的调整、技术限制的改变等多种原因所致。
为了能够有效管理和控制需求变更,项目团队需要建立一套规范的流程来处理需求变更,以确保项目能够按时、按质量完成。
需求变更的基本流程通常包括以下几个阶段:1. 需求变更申请:在项目实施过程中,当客户或其他相关方发现项目需求需要修改或调整时,首先需要向项目团队提交需求变更申请。
申请人需要详细描述变更内容,并说明变更的原因和影响。
2. 变更评估:项目团队收到需求变更申请后,需要对变更进行评估。
评估的目的是确定变更的可行性和影响程度。
评估内容包括变更对项目进度、成本和质量的影响,以及技术可行性和资源需求等方面。
评估结果将作为决策变更的依据。
3. 变更决策:根据变更评估结果,项目团队需要进行变更决策。
决策的内容包括是否接受变更、何时变更以及如何变更等。
在做出决策时,需要综合考虑项目的整体目标、进度、成本和质量等因素,以及变更对项目团队和客户的影响。
4. 变更实施:一旦变更决策通过,项目团队需要开始实施变更。
实施过程包括变更需求的设计、开发、测试和部署等环节。
在实施过程中,需要确保变更的正确性和稳定性,以及与原有需求的兼容性和一致性。
5. 变更验证:变更实施完成后,项目团队需要进行变更验证。
验证的目的是确认变更已经按照需求进行了正确的实施,并且达到了预期的效果。
验证内容包括功能测试、性能测试、用户验收等方面。
验证结果将作为确认变更成功与否的依据。
6. 变更记录:在整个变更过程中,项目团队需要进行变更记录。
记录的内容包括变更申请、评估结果、决策依据、实施过程、验证结果等。
变更记录的目的是为了追踪变更的历史和过程,以便后续的需求管理和项目评估。
以上就是需求变更的基本流程。
通过建立规范的流程,项目团队可以更好地管理和控制需求变更,保证项目能够按时、按质量完成。
需求变更申请书

需求变更申请书
引言概述:
需求变更申请书是在项目实施过程中,由于各种原因导致需求发生变化时,向项目管理团队提出的一种书面申请。
它用于记录和说明需求变更的原因、影响范围、变更内容以及变更后的计划和成本等信息。
本文将从需求变更的背景、变更的原因、变更的影响、变更的内容和变更的计划与成本等五个大点进行详细阐述。
正文内容:
1. 需求变更的背景
1.1 项目背景介绍
1.2 需求变更的定义和重要性
1.3 需求变更的管理过程
2. 变更的原因
2.1 业务需求变更
2.2 技术需求变更
2.3 环境需求变更
2.4 制度需求变更
2.5 风险需求变更
3. 变更的影响
3.1 项目进度的影响
3.2 项目成本的影响
3.3 项目质量的影响
3.4 项目资源的影响
3.5 项目风险的影响
4. 变更的内容
4.1 需求变更的类型
4.2 需求变更的详细描述
4.3 需求变更的优先级
4.4 需求变更的评估和批准过程
4.5 需求变更的实施和验证过程
5. 变更的计划与成本
5.1 变更计划的制定
5.2 变更计划的执行
5.3 变更计划的监控与控制
5.4 变更计划的成本估算
5.5 变更计划的成本控制
总结:
需求变更申请书是项目实施过程中的一项重要工具,它记录了需求变更的背景、原因、影响、内容以及计划与成本等关键信息。
正确管理需求变更可以确保项目按时、按质、按成本完成,并满足客户的期望。
因此,项目管理团队应该高度重视需求变更,并及时做出适当的决策和调整,以确保项目的成功实施。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
ERP实施中最恐怖的事情:需求变更Posted by compsoft on 2009-4-22 14:47:24View 259Comments2辛辛苦苦熬了几个月的通宵,终于确立了ERP需求,规范了工作流程,系统配置也完成了,正准备按部就班ERP系统上线时,企业用户突然改变了需求,不想这么做了,提出了新的需求。
这对于ERP实施顾问来说,正如晴天惊雷,这也是所有ERP顾问最感到恐怖的事情。
因为有时候,用户只是简单的一句话,但是对于系统的调整来说工作量是非常大的。
一.需求变更:迁就or拒绝?从ERP项目立项开始,需求就是ERP实施顾问的心头之痛。
随着对ERP的深入认识、项目环境的变动,企业内外部多种因素都可能使客户对ERP的需求不断改变。
如果不能有效处理这些需求变更,项目实施进度必将一再调整,上线日期也会随之一再拖延,项目成员的士气也将越来越低落,严重的还会直接导致ERP项目失败。
需求变更,本应是客户的权力,但也是实施顾问的为难之处。
如果确需变更,当然要满足客户需要。
问题是不能让变更权力滥用,把一些无关痛痒的变更宠惯养成堂而皇之的变更。
例如,我曾经在某ERP项目中属于“谦虚型”,对于客户提出的变更,无论大小都给予解决,客户对此非常满意。
然而,项目进度却拖得很长,项目一再延期。
相比之下,在另一个项目上我显得稍有些“盛气凌人”,对于客户提出的需求变更,大多都不予理睬,客户对此不是很满意。
不过,该项目的进度控制得较好,基本能按期完成项目。
按后一种“盛气凌人”的做法,对客户的要求一概不理,自顾自地按照最初的需求和计划实施,很可能会由于没有用户的参与,使得ERP系统与用户的需求相差甚远,导致验收通不过,收不回尾款而使公司利益受损。
对于客户来说,达不到需求的满足也浪费了投资。
事实上,客户不满意,则项目就不算成功,实施顾问辛勤劳动最后就只能落得个“没有功劳,只有苦劳”的份。
但按前一种“谦虚型”做法,完全顺着客户的意见走,客户满意度就一定会高吗?其实也不一定。
由于需求变更会带来工作量的大量增加,甚至可能会出现大量的无效劳动。
而且,频繁变动的需求也会导致实施质量下降,留下许多隐患。
因此,一味的迁就用户将会使进度一拖再拖,实施方案一改再改,变更越来越多,士气越来越疲,公司越来越不满意,用户越来越急。
二.需求变更为什么总是做不完?在ERP实施过程中,实施顾问所要面对的将是一系列和多方面的考验。
经常发生而又最令人头疼的恐怕就是需求变更了。
客户变更需求是ERP项目与生俱来的特性,也是一个无法避免的事实。
需求变更的表现形式是多方面的,如客户临时改变想法、项目预算增加或减少、客户对功能的需求改变等。
它会导致ERP实施过程中成本增加、进度拖延等风险,而且越往后的变更产生的风险将越大。
以笔者参与的多个ERP实施项目的实际经历来看:需求变更泛滥是非常可怕的事,尤其是到了项目实施后期,客户不断对移交的ERP系统提出修改意见,甚至有时刚刚重新完成的更改,客户又要求改回去或改成另一种模式。
需求变更越来越多,实施顾问只能疲于应付。
“无底洞”是大部分实施顾问进行ERP项目的共同感觉。
实施顾问作为项目的承担者,在规定时间内利用有限资源保质保量的完成项目,让客户和公司都满意是最终目标。
但是让客户满意就是不断满足客户无穷无尽的需求吗?我们分析一下出现需求变更的根源。
ERP实施最恐怖的事情:需求变更2(1)合同签订马虎,没有真正明白客户需求签订合同时缺乏对客户需求认真对待,导致需求描述不清,为后期的实施工作带来困惑。
ERP销售顾问为使客户能够快速的签订合同,往往草率决定和片面同意客户提出的需求。
当客户提出新的需求时,往往是销售顾问一看“应该”只是一个小小的修改,没有太大的影响,所以直接答应能变更。
该问题的关键是合同签署的太烂,没有把需求明确再签合同,而且也没有把需求变更的流程写入合同。
如果在合同时把客户需求弄清楚,后期就根本不需要频繁的变更需求。
签订合同时明确定义项目需求的范围,可以为以后各项实施工作的开展奠定深厚的基础。
(2)调研时没有深入理解客户需求在ERP上线前的需求调研分析阶段,项目组成员和客户的深入交流是减少频繁需求变更的关键阶段之一。
但是由于双方的误解通常使需求交流难以进行。
更严重的是,实施顾问只根据用户提出的描述性、总结性的短短几句话去制定实施方案,没有真正挖掘和按客户的需求去制定实施计划。
当客户头脑一热或领导一拍脑袋提出新的需求时,实施顾问往往也就不能区分客户真正需求和镀金需求。
如果项目组对客户需求的细节了解不充分,双方对需求的理解就会产生差异,就会导致移交 ERP系统时才使问题暴露出来,客户只能频繁的提出需求变更。
(3)没有明确的需求变更管理流程没有明确的需求变更管理流程,就会使需求变更变得泛滥。
并不是所有的变更都要修改,也不是所有变更都要立刻修改,需求变更管理的目的是为了决定什么类型的变更需要修改和什么时候修改。
比如ERP界面风格问题,就可以先不修改,或者规划一下修改的时间待到以后进行优化。
另外,对于核心模块的修改没有严格把关流程,有些小需求看起来工作量不大,但是实际上实施顾问和开发顾问要耗费比较长的时间去完成这些销售顾问或者客户没有考虑到的细节问题。
(4)没有让客户知道需求变更的代价对变更的影响没有评估是需求变更泛滥的根本原因。
变更都是有代价的,应该要评估变更的代价和对项目的影响,要让客户了解需求变更的后果。
如果客户不知道需求变更付出的代价,对实施顾问的辛苦就会难以体会。
在评估代价过程中,可以请客户一起做判断:“我可以修改,但您能接受后果吗?”。
三.如何有效控制需求变更?需求变更对项目成败有重要影响,既不能一概拒绝客户的变更要求,也不能一味地迁就客户,所以实施需求变更之前必须做好控制。
例如授权、审核、评估和确认,在实施过程还要进行跟踪和验证。
有句通俗的话说得非常好:“需求变更控制的目的不是控制变更的发生,而是对变更进行管理,确保变更有序进行。
”用户需求的变更总是不可避免的,所以我们要以积极的心态去接受和控制用户的需求,而不仅仅是埋怨。
对待客户频繁的需求变更,应采取有效办法应对,避免事态蔓延,不让客户养成随意变更的毛病。
(1)合同约束需求变更给ERP实施带来的影响是有目共睹,所以在与用户签订合同时,可以增加一些相关条款,如限定用户提出需求变更的时间,规定何种情况的变更可以接受、拒绝或部分接受,还可以规定发生需求变更时必须执行变更管理流程。
虽然ERP项目合同很难在签订之初就能够精确定义每项需求,单靠合同是帮不上忙的,但也不能忽视合同的约束力。
有一个笑话,就是许多销售顾问都开玩笑说他们都是清政府。
为什么是清政府?清政府的特点之一就是丧权辱国的条约太多。
(2)建立需求变更审批流程明确需求变更审批环节、审批人员、审批事项、审批流程等。
目的有两个:一是将客户下达变更的流程尽可能地规范化,减少张嘴就来的非必要、非紧急、非合理、非高层领导意图的“无效变更”。
二是留下书面依据,为今后可能的成本变更和索赔准备好“变更账”。
凡未履行审批程序的“变更”,一律是无效变更不予受理。
有效的需求变更流程应该包括确认变更、评估变更的价值、分析变更对项目的影响,以及提交给双方高层进行评价以确定是否执行变更。
变更请求必须有书面材料,当用户发现由于业务变化而引起的需求变更,需要提出书面申请。
这样对所有的变更,双方的项目负责人都能做到心里有数。
而且用户在递交书面变更申请时比较慎重,一般都在内部经过讨论后进行,这样减少了因用户内部看法不同导致的反复变更。
ERP实施最恐怖的事情:需求变更3(3)对于零星变更,集中研究、批量处理每周或每两周甚至每月召开一次需求变更专题会议,集中研究处理这些零碎变更事项,主动控制好工作节奏,尽量避免由于处理零碎变更而影响项目运行的总体进度。
例如向客户正式提交一份各阶段需求变更的完成计划,注明变更引起的时间、成本、工期的代价和增加的工作量。
要求客户配合需求变更计划,确定变更时限,控制变更规模,过时变更不候,离谱的变更不做,保大局弃小变。
(4)评估各种需求变更的影响客户的需求是永远不会满足的,可能一天一个样,为了达到控制频繁的需求变更。
需要将需求变更后产生的成本进行评估与量化,形成分析报告提交双方领导。
否则,一味的妥协只会让项目进一步恶化,实施顾问需要掌控客户及公司的进度成本,把客户的每一次需求变更进行成本分析。
确认哪些需要收费变更,哪些可以免费配合客户。
这样既可以维护客户关系,又不致造成公司无谓的损失。
(5)确认客户是否接受变更的代价让客户认识到变更都是有代价的,要和客户一起判断需求变更是否依然进行。
例如,变更是没有问题的,但是要明确客户能否接受由此引起的如进度延迟、费用增加、效率下降等问题。
一般来说,如果客户认为该变更是必须的(不是其上级领导拍脑袋提出的)就会接受这些后果,通过与客户的协商,项目组可能会得到回报或者即使没有回报也不会招致公司和客户双方的埋怨。
如果客户认为该变更虽然有必要但是可以暂缓,双方签署备忘录后留待以后解决。
如果客户认为该变更可有可无,多数情况下会取消变更。
这样即可防止频繁变更,也让客户认识到不是所有的需求都需要变更,更不是所有的需求变更都需要立刻修改。
客户一般对E RP不甚了解,他们认为很简单的事情,但可能解决起来会很复杂。
以笔者的经验来看,一般来说用户的镀金需求可以延期解决甚至不考虑。
用户的新增需求如果不是影响到核心业务的实现,也可以安排在现有功能的完善之后。
(6)每月变更记录上报双方领导最后,实施顾问要将有关变更措施和记录随时抄报双方最高层留档备案,可采取简报、文件、抄报、抄送、会议等多种形式。
掌握主动权,逐步让不合理的随意频繁变更,成为客户不好意思开口的尴尬事件,尽快形成正常的项目执行氛围和良好的工作习惯,也为可能受到变更所带来的责任问题留下伏笔。
最后,要特别提醒,要在ERP项目开始就对项目组和客户进行宣传和培训,让所有成员都理解变更控制的重要意义。