项目管理论文.docx

上传人:b****8 文档编号:28848978 上传时间:2023-07-20 格式:DOCX 页数:20 大小:33.04KB
下载 相关 举报
项目管理论文.docx_第1页
第1页 / 共20页
项目管理论文.docx_第2页
第2页 / 共20页
项目管理论文.docx_第3页
第3页 / 共20页
项目管理论文.docx_第4页
第4页 / 共20页
项目管理论文.docx_第5页
第5页 / 共20页
点击查看更多>>
下载资源
资源描述

项目管理论文.docx

《项目管理论文.docx》由会员分享,可在线阅读,更多相关《项目管理论文.docx(20页珍藏版)》请在冰豆网上搜索。

项目管理论文.docx

项目管理论文

【摘要】

2013年3月,我作为项目经理参与了xx省移动公司“商机管理平台”项目。

该项目是xx省移动公司为应对日益激烈的市场竞争形势,更好的把握市场商机而投资建设。

目标是构建一个包括商机采集、商机审核、商机处理、商机过程管理、商机案例管理、报表分析等6大功能域于一体的管理平台。

总投资1000万元人民币,建设工期8个月,于2013年11月正式通过了项目验收。

本项目涉及业务范围广泛,和CRM、CSP和OA等系统接口众多,建设难度较高。

而且作为xx省移动公司2013年重点信息项目,客户要求务必在2013年12月底之前投入生产。

因此在项目实施过程中,进度管理就显得尤为重要。

在项目的进度管理中,包括活动定义,活动排序,活动资源估算,活动历时估算,编制进度计划,项目进度控制这过程。

本文结合作者在项目中实际管理经验,讨论下在项目中如何进行有效的进度管理和控制。

【进度管理】

“商机管理平台”是xx省移动公司为应对日益激烈的市场竞争形势,更好的把握市场商机而投资建设。

目标是将原有分散在各个系统的商机管理相关功能整合,构建一个集商机采集、商机审核、商机处理、商机过程管理、商机案例管理、报表分析等6大功能域为一体的商机管理系统。

该项目最终由我公司承建,投资1000万元人民币,建设工期8个月。

系统采用“B/S”架构,考虑到未来运行的稳定性,服务端采用较为成熟的J2EE+Oracle的模式,服务器采用HP小型机,操作系统为HPUX11v3,数据库使用Oracle11gR2并搭建RAC,中间件采用IBM公司的Websphere。

项目组采用矩阵式结构,其中需求管理(6人),开发小组(12人),测试小组(5人),实施小组(6人),质量小组(4人)以及管理协调支撑(3人)。

我被任命为项目经理,负责整个项目的管理工作。

项目合同中约定系统必须在13年12月底之前正式投入生产运营,因此能否按期完成项目交付成为衡量项目是否成功的重要标准。

作为项目经理,除了对其他管理领域进行严格管理之外,特别对项目进度从如下几个方面进行管控。

(1)合理的活动定义和排序

合理的活动定义和排序是成功进行项目进度管理的基础。

活动定义是根据前期WBS分解结构和WBS字典,通过滚动波式规划、模板、分解等工具和技术,进一步细化定义出为完成项目目标而必须进行的所有活动。

在此基础上,通过箭线图、前导图等工具对项目活动进行排序,确定活动间的依赖关系,完成活动排序。

根据本项目特点,项目组在活动定义阶段与移动公司涉及商机管理的各业务部门及用户代表进行了充分沟通,对商机管理流程有了整体的了解。

召集技术专家对业务流程进行分析,由于涉及的人员众多且个人的知识水平参差不齐,因此我们决定采用滚动波式计划。

对于即将开展的活动进行详细的分析和计划,对于后期的活动尽量粗略的估计,避免出现大范围的变更。

在此基础上,我们采用了简单有效的前导图法,确定了各个活动间的逻辑关系,完成了项目计划网络图的编制。

(2)恰当的资源和历时估算

恰当的资源和历时估算是成功进行项目进度管理的关键任务之一。

在活动定义和排序的基础上,通过专家判断、类比估计等工具和手段,结合项目资源可用性等条件,估算出项目的资源要求和活动的历时情况。

因为公司承建过其他公司类似平台的建设项目,在这一领域有着丰富的项目经验。

因此在资源和历时评估阶段,我们主要采取以类比估算为主的方式,结合领域内专家的意见,自上而下的评估出项目的资源要求和历时情况。

在评估过程中,我们充分考虑到了新技术应用,项目环境复杂等因素可能对进度造成的影响,在资源评估阶段就做好准备。

例如项目中应用到的e-bus总线,因为是公司新近研发的消息总线模块,部分项目组成员不是很熟悉,有可能在开发时遇到瓶颈。

在资源评估阶段我们识别到这一因素,特别配置了e-bus技术培训和咨询服务资源,避免了这一新技术的应用造成进度延误,从而影响客户感知。

(3)识别关键任务,制定进度计划

识别关键任务,制定合理的进度计划是成功进行项目进度管理的核心。

以定义的项目活动和资源、时间评估为基础,通过进度网络分析,关键路径法等工具,制定出项目进度计划和项目基线。

在这一阶段我们利用关键链,资源平衡等手段,制定出了详细的项目进度计划。

明确每一项任务的开始、结束时间,工作量和完成标准,让每个项目组成员都明确自己承担任务的安排情况。

根据和项目组成员、项目管理专家以及客户的沟通结果,我们意识到消息总线和商机工作流引擎是整个系统的基础,这两项任务受到任何影响都有可能对整个项目进度造成影响。

因此我们对这两个模块的工作进行了适当的资源倾斜,将项目团队中最有经验的工程师安排到这部分的工作,确保不对整个项目进度造成影响。

(4)随时掌握进度情况,做好进度控制

再完美的计划,没有良好的执行都是一场空。

我们深知进度控制工作对项目进度管理的重要意义。

依据详细的进度计划,我们采取了定期检查和定点检查相结合的方式控制项目进度。

定期检查是利用周项目例会的方式,在每周五的项目例会中,一个重要的议程就是由各小组汇报项目进展情况。

汇报中明确规定不得使用“大概”、“差不多”等不确定的字眼,必须要“已全部完成”,“已完成80%”等准确的描述。

这样可以准确的掌握项目的进展情况,并针对不同情况作出相应的调整。

定点检查是根据事先设置的检查点,对项目的完成情况进行检查,掌握项目的实际进度情况。

在8月份第一周的项目例会上,通过汇报发现项目编码工作有20%左右的滞后。

究其原因,是因为一位资深工程师家里出现了变故,工作时间被迫缩短,因此将部分工作移交给另外一名新进工程师。

但新进的工程师因为能力限制,无法按时完成移交的这部分工作,导致进度出现延误。

了解到这一情况后,我们立即做出调整,将工作调整给另外一位资深工程师,并安排相关人员适当加班追赶进度。

加强了对这一部分工作的质量监控,避免因为赶工而出现质量问题。

对参与加班人员,给予了绩效奖励并在后期有条件时适当安排的调休。

通过这一系列的举措,项目组在两周后追赶上了计划进度,资深工程师也恢复了正常的工作时间。

且未重现重大质量问题。

(5)追求进度的同时质量要求不放松

项目组一直秉承“没有质量的进度毫无意义”这一观念。

在追求进度的同时,项目组从未放松过对质量的要求。

在每周的项目例会上,我们会严格检查项目的质量状态,要求上游责任人必须对提交给下游的工作保质保量,真正做到“守土有责”。

(6)做好团队建设,努力工作乐享生活

根据公司惯例,在项目开始后我们申请到一笔专项资金作为项目活动经费。

每周三晚和周日下午组织项目组成员聚餐,打球,卡拉OK等活动,促进项目组内友好合作的氛围,提升工作效率,而这业务确保项目进度立下了汗马功劳。

在项目实施过程中,我们碰到了一些影响项目进度的干扰因素。

针对这些因素,我们采取了各种积极的手段和措施,消除其对项目的不良影响。

(1)技术因素:

“商机管理平台”需要对各种来源,各种格式的消息进行汇聚处理,对消息总线的性能和稳定性的要求非常高。

经过分析和评估,我们决定采用我公司新研发的e-bus消息总线。

考虑到项目组多数人员未接触过这一新技术,在实施中可能会遇到各种问题进而对进度产生影响,我们在项目初期就向公司申请了两位参与过e-bus研发的资深工程师,在详细设计阶段就加入项目团队。

并申请培训资源,在项目组内安排了e-bus技术专项培训,使大家提前学习和了解,最终避免了这一新技术对项目的进度造成延误。

(2)需求管理因素:

客户不受控制,随意变更需求对项目进度的影响将会是致命的。

我们在项目初期就和移动公司领导进行了充分的沟通并达成了共识,对需求变更实施严格的变更管理。

经过评估认为会严重影响项目进展的需求坚决拒绝,通过评估的需求提交CCB评审,通过评审的才能发布和实施。

针对实施过程和后续影响进行监督和根据,确保不对项目产生不良影响。

(3)沟通因素:

有效的沟通是项目顺利进展的保证。

在项目实施过程中,经和移动公司协商,照顾双方的工作习惯制定了半月例会制度。

在例会中对项目的现状,紧张,存在的问题和解决方案等进行面对面的沟通。

同时不定期的上门拜访移动公司领导和骨干人员,和他们就项目情况进行交流,征询他们对项目的意见和建议。

通过这些手段,我们成功的获得了客户对项目工作的理解和支持,保障了项目工作的顺利开展。

回顾整个项目过程,我们通过科学的进度管理工作、技术和手段,有效的确保了项目顺利完成。

但在项目过程中,还存在着一些问题,例如工作加班安排较多,部分非场景测试案例不够充分等等。

虽然经过调整,没有影响到项目最终的结果,但这其中的经验教训深思。

在接下来的工作中,我还要加强学习,提升项目管理水平,为中国的信息化事业贡献自己的力量。

【成本管理】

“商机管理平台”项目业务复杂,而且作为公司打入xx省移动运营商领域的标志性项目,商务谈判中做出了一定的让步。

因此,在整个项目的实施过程中,如何确保项目在批准的成本预算范围内尽可能好地完成,成为项目是否成功的重要标志之一。

项目成本管理主要关心的是完成项目活动所需资源的成本,同时也需要考虑项目决策对项目产品、服务或成果的使用、维护和支持成本的影响。

在项目的整个生命周期,项目组综合利用包括MicrosoftProject2010在内的各种工具和技术手段,确保项目在批准的预算内完工。

1.估算项目成本

成本估算工作为后面的成本预算提供了一个完整的框架和坚实的基础。

只有成本估算工作做得全面,成本预算才能更准确。

依据项目前期范围说明书,利用模板将项目进行分解,获得WBS层次结构图。

WBS描述了为完成项目目标而分解出的工作任务,是成本估算的重要基础。

在WBS分解结构基础上,我们综合考虑系统的功能、关键技术及难度、团队人员情况等因素,开始工作量的估算。

工作量估算是成本管理的关键,其估算结果决定了成本估算。

工作量估算一般有参数估算法、类比估算法和自底向上估算法等等,因为我公司有其他内容和投资类似项目经验,我们决定采用类比法估计作量。

我们参考所开发过的系统进行代码行估算和功能点估算工作,再通过项目专家组成员沟通对估计值进行不断校正的方法,得出估算值。

处于谨慎的态度,在估算工期时,我们还充分考虑了活动清单,资源需求,人员能力因素,以及环境因素和风险因素对工期的影响。

对WBS的每项活动先确定具体人员,然后对活动本身进行详细分析确定工期,最后通过财务计算得出人力资源成本。

对于估算把握不是很好的任务,我们一般通过提供一个乐观估算A、悲观估算B、正常估算M后利用公式(4*M+A+B)/6计算取整。

除此之外,整个系统还包括系统软件、硬件、集成费用、推广实施费用。

而且,为了避免因需求变更、人员调整或其它不可预见事件给项目带来超出预算的风险,还预留总成本的3%作为项目准备金。

2.制订项目预算

成本预算既是将成本估算进行细化,结合项目具体活动将项目成本进行预先的演练;同时又要考虑成本控制的标准,在项目的各个里程碑确立成本控制的指标。

因此说,成本预算是成本控制的基础。

根据成本管理计划,项目组结合本项目特点,以及公司对项目的要求,制订了切实可行的项目预算。

我们将得到批准的项目估算总成本,逐项分摊到每一个工作包中,为每一个工作包制订具体的项目预算,并且对于相对比较复杂的工作包还制订了成本控制的标准,确保项目所有的工作包预算累加不超过项目总体预算。

在此基础上将每一个工作包的预算再次分摊到每一个项目活动中,以确定项目的每一项预算的支出时间,最终形成项目时间点对应的项目预算累计支出,并形成项目预算支出计划。

在项目预算过程中我使用了成本总计方法,将WBS每一个工作包的预算累计成为WBS上一级的预算金额,最终累计成为整个项目总体预算。

进行成本预算时,考虑到了项目的管理上的储备,我们按照5%的额度设定了项目管理储备。

3.控制项目成本

成本控制的目的就是使项目活动按照成本管理计划完成,对项目实施过程中项目活动所发生的项目实际成本与项目预算进行对比、检查、纠正,尽量使项目的实际成本不超出计划成本。

为了确保项目执行过程的成本控制,项目组决定每周做一次的绩效测量,每两周做一次整体项目的绩效测量,通过计算项目挣值,与成本管理计划和成本预算进行比对,找出与项目成本管理计划和预算的差距。

在项目实施过程中,我们制订了公司级与项目级的两级成本控制体系,根据项目实施过程的绩效测量,当与预算出现6%以内的偏差时,在项目组内部解决,出现6%以上的偏差,立即上报公司解决。

当出现项目成本偏差出现以后,我们依据变更管理流程,通过成本变更申请、成本变更审批以及成本变更执行最终完成变更,并将修改的成本基线计划报送项目各方。

在本项目管理过程中,我们全面应用了项目成本管理的方法,使得该项目成本管理方面较好地达到了预期目的。

鉴于我们在项目初期就建立了项目成本管理计划,并依据成本管理计划对项目进行了合理的估算;在项目估算的基础上,综合考虑了项目的特点,并结合公司对该项目的要求,我们制订了行之有效的项目预算;在项目执行过程中,通过挣值分析进行项目成本与预算的比对,并形成项目于公司两级成本控制体系。

通过以上这些举措,我们成功完成了项目成本管理工作,最后还为公司成功节约项目资金约60万元。

4.严格的质量能促进成本控制

项目组一直秉承“没有质量的工作毫无意义”这一观念。

从未因成本控制而影响质量控制的资源,从未放松过对质量的要求。

如果不加强对质量的控制,造成返工或交付物不满足客户的质量要求,造成更大的成本支出和浪费。

在每周的项目例会上,我们会严格检查项目的质量状态,要求所有人对自己提交的工作保质保量,真正做到“守土有责”。

5.做好团队建设,努力工作乐享生活

根据公司惯例,在项目开始后我们申请到一笔专项资金作为项目活动经费。

每周三晚和周日下午组织项目组成员聚餐,打球,卡拉OK等活动,促进项目组内友好合作的氛围,提升工作效率,团队工作效率的体则,则又对项目成本控制起到了积极的促进作用。

 

【风险管理】

风险是客观存在,不以人的意志为转移的。

但风险又是相对的,它依赖于决策目标,同一方案不同的决策目标会带来不同的风险。

能否做好项目的风险管理对项目最终是否能够成功至关重要。

商机管理平台涉及多个业务部门,项目需求来源广而杂;和现有系统关联的接口众多,涉及大量和其他公司联调的工作。

这些情况对项目的范围、进度和成本等都有可能产生消极影响,因此我们在管理过程中一直把风险管理作为管理的重点项目之一。

我们紧紧抓住编制风险管理计划、风险识别、定性风险分析、定量风险分析、风险应对计划编制和风险监控这6个重点环节,科学合理的利用各种工具和手段,有条不紊的完成了相关工作。

一、风险管理计划编制

风险管理计划是定义如何实施风险管理活动的过程。

它决定了在项目中如何进行、规划和实施项目风险管理活动,并为评估风险奠定一个共同认可的基础。

在项目初期,我组织有关人员编制了风险管理计划。

我们采用会议的方法广泛搜集信息来制定风险计划,因为该项目工期较紧、人员较少,项目组邀请了所有的重要项目干系人如各业务部门管理员,业务支撑部门骨干,部分营业员话务员代表和关联系统接口联调人员等参加了风险管理计划会议,全面地考虑了风险对项目的影响,制订充分的风险管理计划。

在计划中,我们确定了每两周召开一次风险评估会议作为基本风险管理活动,根据项目管理要求和我公司的项目实践,定义了项目中的风险管理过程,估计了风险管理的时间表和费用,并把风险管理活动纳入了项目计划,把风险管理费用纳入了成本费用计划。

二、风险识别

风险识别是判断哪些风险会影响项目并记录其特征的过程。

根据项目的实际情况,我们采取以文档评审为主的方式,把项目中的风险划分为技术风险、团队风险、外部风险三大类,采用风险分解结构(RBS)列举了已知的风险。

在识别了上述风险后,我们还确定了这些风险的基本特性,引起这些风险的主要因素,以及可能会影响项目的方面,形成了详细的风险列表记录。

通过这一阶段,我们识别出项目主要有以下风险因素:

e-bus等新技术的应用;个别核心开发人员离职倾向;需要联调的接口众多,配合联调难度大。

三、风险定性分析

风险定性分析是评估并综合分析风险的发生概率和影响,对风险进行优先排序,从而为后续分析或行动提供基础。

我们根据风险管理计划中的定义,确定每一个风险的发生可能性,并记录下来。

除了风险发生的可能性,还分析了风险对项目的影响,包括对时间、成本、范围等各方面的影响。

在这个过程中,我们还是采用会议的方式来进行的。

不过,在风险分析的会议中,除了有关项目干系人外,我们还专门邀请了公司在其他省份实施过类似项目的专家参加评估,尽量提高分析结果的准确性。

我们还利用了风险概率和影响评估技术,分析了其他如工期紧、人员少、关键人员离职倾向等风险问题,确定了整个项目的风险情况。

并采用了风险优先级矩阵来评定风险优先级。

最后得出的结论是技术风险排在第一位,该风险的可能性很高,影响也很大,需要重点防范。

四、定量风险分析

定量风险分析就是对识别的风险对项目总体目标的影响进行定量分析。

在风险进行定性分析的基础上,我们又定量地分析了各风险对项目目标的影响。

在这个过程中,我们采用了专家评估为主并结合仿真和建模的方法,对项目进行乐观、最可能性和悲观估计。

同时,也利用了我公司历史项目的数据,用来辅助评估。

进行定量风险分析,更新了风险记录列表。

五、风险应对计划编制

风险应对计划编制是针对项目目标,制订提高机会、降低威胁的方案和措施的过程。

根据定性和定量分析的结果,我们对已识别的风险,制订了相应的应对计划,并把风险应对所需的资源和费用加进项目的预算和项目项目管理计划中,并明确和分配实施风险应对措施的风险应对责任人。

对不同的风险,我们采取了不同的措施。

例如针对e-bus等新技术的使用,从公司申请了两名相关领域的专家加入项目团队,并加强对有关人员的培训工作;针对外部接口联调难度大的问题,我们提前和局方就此问题进行沟通,获得局方高层领导的支持,专门组建了包括局方领导、关联系统接口维护人员、项目组外部接口负责人在内的联调协调小组专门负责协调这项工作;针对关键岗位人员存在离职的可能性,我们在项目实施过程中,明确了关键岗位全部由2人A、B角色工作,可以将关键人员的离职给项目带来的风险降到最低。

六、风险监控与跟踪

经过上述五个过程后,该项目中的风险已经比较清晰。

风险监控就是在整个项目生命周期中,跟踪已识别的风险、监测残余风险、识别新风险,实施风险应对计划,并对其有效性进行评估。

在这个过程中,我们主要采用了风险再评估、风险审计、偏差绩效测量的方式来进行的。

【范围管理】

范围管理是项目管理的基础,也是项目管理工作的重点和难点。

含糊的需求和频繁变更的范围让项目的甲乙双方吃尽了苦头。

如何做好项目的需求管理与范围管理常常是项目经理最头疼的问题之一。

在本项目中,我们紧紧抓住制定范围管理计划、定义范围、创建工作分解结构、核实范围、控制范围这几个重点环节,科学合理的利用各种工具和手段,有条不紊的完成了项目工作。

一、制定范围计划

作为一名合格的项目管理者,做任何事之前都应该先做好计划。

好的计划,是成功实施项目的基础。

有人认为为做项目范围计划花费了太多时间,不如把它们用于执行工作,项目将会更快更好的完成。

我认为这是一个错误的想法,通过省略范围计划制定,虽然能在短暂期间内节省一定的时间,但在长期来看常常会因缺乏管理计划指导而使得范围定义不清、范围蔓延、以致无法完成项目。

因此,在该项目中,我们非常重视范围计划的制定。

在正式做计划之前,我们参考公司历史类似项目信息找出范围管理计划的模板,再结合公司里本领域专家的意见,制定出一份初步计划。

然后和整个项目团队一起讨论,对计划进行修改和完善,在全体参与下,最终完成了一份详细的、科学的范围管理计划,用于指导项目如何定义、分解以及核实和控制范围。

二、定义范围

一个成功的项目,应该做且只做成功完成项目所需的全部工作。

为了保证这一点,就需要在项目前期定义一个明确的项目范围。

在项目的早期阶段,项目组到客户现场收集需求。

组织了局方业务部门、营业部门、客服部门和IT部门召开需求讨论会,共同商讨项目范围。

收集需求的时候,客户有时候需求描述的不是很清楚,造成了双方对需求理解有歧义。

甚至有时候客户对于其需求自己都不清楚,只有一个模糊的概念。

针对这种情况,我们采用原型法将收集到的需求做成模型供客户参考确认,以此消除彼此的歧义。

充分挖掘用户的需求,并基于团队自身的经验以及专业水平,对客户的需求进行引导、细化,将其模糊的概念形象化,粗糙的需求具体化。

基于需求文件,我们召集了项目的主要干系人进行开会讨论,同时邀请了系统的最终用户代表对系统功能做评价,通过用户的角度,去发现和改进系统的功能,以此最终形成了完整的项目范围说明书。

三、创建WBS

基于项目范围说明书,我们开始对项目范围进行分解,以形成该项目的WBS。

在分解过程中,我们按照以下原则进行分解:

在各层次上保持项目的完整性,将该项目生命周期涉及的需求调研、系统设计、开发、测试等完整的一一列出作为分解结构第一层,避免遗漏必要的组成部分。

一个工作单元只从属于某个上层单元,对于该项目中的数据库设计,就只将其归入系统设计单元中,在其他单元不再重复出现,避免了交叉从属。

相同层次的工作单元应有相同性质,对于系统设计单元下的数据库设计、接口设计、系统设计等设计内工作,它们从属性上来讲都属于设计,因此将其一并归入系统设计单元下。

工作单元应能分开不同的责任者和不同的工作内容,对于该项目中每个工作包,都指定唯一的负责人和其负责的工作内容,便于项目管理进行计划和控制的管理需要。

对于该项目的每个工作包,都对其进行编号并与组织结构图和成本控制点深度融合,便于项目的日后管理。

将项目管理工作,包括分包出去的工作都包含其中;WBS的最低层次的工作单元是工作包,对于该项目中工作单元,参照8/80小时原则细化成具体的工作包,并指定具体的负责人。

同时制作WBS词典,对工作包做具体描述。

四、核实范围

范围确认并不是件容易的事情,与客户的沟通上,我们希望客户尽快确认以便尽快开展后续的开发阶段工作。

而客户则可能认为自己什么也没看到,怎么确认呢?

针对这种情况,我们在提交文档给到客户的相关干系人后,重点对客户的IT人员进行沟通培训,详细介绍系统的设计,然后用他们的声音去向客户的业务部门做出介绍。

这样既有益于专业人员之间的技术沟通,也有益于客户业务部门对系统范围的认可与信任。

同时与客户的业务部门沟通时,我们强调虽然范围确认是正式的,但这并不意味着项目的范围就是铁板一块,不能再修改了。

只要通过标准的变更流程,且审批通过的,是可以进行变更的。

这样就消除了客户的顾虑,便于快速,高效的完成范围确认。

五、控制范围

控制范围就是监督项目的范围状态,管理范围基础变更的过程。

在本项目中,我们定期组织召开项目状态审查会,审查项目的范围。

通过对照范围基线,找出范围偏差并进行分析,严格杜绝一切的范围蔓延情况。

例如在一次状态审查会上,我们发现项目的功能模块中,系统管理模块多了登陆日志审计功能。

查了一下系统变更日志,没有找到类似的变更记录。

于是参照责任分配矩阵,我找到这个模块开发的负责人李工询问原因。

李工表示,他增加登陆日志审计这个功能是因为客户在一次电话中,向他提过希望在系统中能提供类似的功能。

针对这种情况,我首先向李工强调了范围基准、以及变更流程的重要性;其次,针对这项多出来的功能,要求相关人员提交正式的变更申请,走正常的变更控制流程重新申请。

变更并不可怕,项目干系人出于项目利益以及各种情况考虑,总会有一些需求变更,可怕的是这些不受控制的变更。

要管理好这些变更,就需要在项目规划时,就制定好变更控制流程以及成立需求变更控制委员会(CCB)。

项目组在项目早期就制定了一套标准的变更流程:

1、提交变更申请2、评估变更3、报CCB审批4、实施变更并调整基准5、将变更信息通知相关干系人6、对变更的结果进行追踪与审核。

有了这些流程以及CCB的控制,项目的需求变更得以良性发展,变更带来更多是项目利益以及效率的提升。

需求管理(6

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 人文社科 > 文学研究

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1