求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
     
   
分享到
系统集成项目失败因素分析总结
 
发布于2012-8-13,来源:MYPM
 

案例

A公司是一家国内中型IT系统集成公司,有多年的行业系统集成经验。通过多年的经验积累和管理探索,建立了一些项目管理流程和项目管理信息系统。

在一次大型项目的招投标项目上,公司副总任命James为本次投标项目的负责人,来组织和管理整个投标过程。

James接到项目任务后,得知必须在天内完成,随后立即召集了商务部、售前技术部、销售部、客服部和质量部等相关部门,进行了一次项目内部启动说明会,并把各自的分工和进度计划进行了部署。

然而,在投标前三天进行投标文件评审时,发现技术方案中所配置的设备在以前项目使用中是有问题的,必须更换。James和方案编制人员经过加班加点,终于修改完成。到了正式评标会上,James又遇到了一点麻烦,原来授权代表声明和投标方案中写的不一致,影响了评标分数。不过还好,项目最终拿了下来,并和用户确定了合同。根据公司流程,James把项目移交给了售后实施部门,由他们具体负责项目的执行和验收。

实施部门接手项目后,Bob被任命为实施项目经理,负责项目的实施和验收工作。Bob发现由于项目前期自己没有尽早介入,许多项目前期的事情都不很清楚,而导致后续跟进速度较慢,影响项目的进度。同时,Bob还发现设计方案时,售前工程师没有很好地了解用户需求,也没有书面的需求分析调研报告。在接手项目后,必须重新开始了解用户需求,编制实施方案,这样无形中增加了实施难度和实施成本。

等到这一切理出了头绪,在商务下单订货过程中,又发现由于商务人员的工作失误,导致少采购了几台设备,并且设备模块配置功能错误而不能符合要求。

而在A公司中,由于售后和售前是两个独立的部门,在项目执行中,特别是项目执行完毕后,没有一套明确而完善的项目总结和闭环的问题分析和关闭流程,导致许多项目中重复出现相同或类似的错误或失误(包括:技术方面和商务方面),进而导致投标失败、项目成本较高、项目执行中困难重重、用户满意度较低等诸多风险。

基于以上诸多原因,A公司管理领导层要求系统集成部门负责人Paul就此问题提出合理的改进办法,同时编制一份各个项目可以参考的项目总结模板。希望将项目完成后各部门不同阶段的总结反馈给相关部门和人员,形成一个闭环的流程,以便避免和减少类似问题的重复发生。那么Paul是如何通过有效的项目总结和流程来解决这些问题呢?

说起项目总结,大家都认为它很重要。然而,在实际工作中,人们很少把它与进度、成本等同等对待,总认为它是一项可有可无的工作。因而,在项目实施过程中,项目干系人就很少会注意经验教训的积累,即使在项目运作中碰得头破血流,也只是抱怨运气、环境或者团队配合不好,很少系统地分析总结,或者不知道怎样总结,以至于同样的问题不断出现。

在上面的案例中,A公司在项目中重复出现相同的错误或失误,从而导致项目进度延误、项目执行成本较高甚至客户满意度下降等问题。这也是系统集成公司或软件公司在项目中经常会出现的问题。

项目中问题出现后,大家不知如何做到防微杜渐,如何通过有效的项目总结做到亡羊补牢,避免在下一个项目中在出现类似的问题。这实际上就是通过有效的总结从而使项目过程形成一个闭环的反馈机制,最终避免和减少问题的发生。

经过调查和分析公司的多个项目后,A公司的部门负责人Paul认识到了做好项目总结工作是其中的关键之处。并且,在与项目经理和项目成员沟通后,Paul发现要做好项目总结的工作,首先就应该在项目启动时将其加以明确规定,比如项目评价的标准、总结的方式以及参加人员(如项目办公室、商务部、售前部、市场部、储运部等)等。

当然,除此以外,如果可能,项目总结大会上还应吸收用户及其它相关项目干系人参加,以保证项目总结的全面性和充分性。

事实上,项目总结工作应作为现有项目或将来项目持续改进工作的一项重要内容,同时也可以作为对项目合同、设计方案内容与目标的确认和验证。正如上文所说的,项目总结的目的和意义在于总结经验教训、防止犯同样的错误、评估项目团队、为绩效考核积累数据以及考察是否达到阶段性目标等。总结项目经验和教训,也会对其他项目和公司的项目管理体系建设和项目文化起到不可或缺的作用。完善的项目汇报和总结体系对项目的延续性是很重要的,例如项目完成后项目的售后维护、设备保修等。特别是项目收尾时的项目总结,项目管理机构应在项目结束前对项目进行正式评审,其重点是确保能够为其它项目提供可利用的经验,另外还有可能引申出用户新的需求而进一步拓展市场。

项目总结的信息来源

那么,总结项目经验所需的信息应来自哪些方面呢?在项目实施中,项目经理有时会发现,以前项目中的总结信息很零散,每个部门只从本部门出发,总结自己的问题,而没有其他部门或人员的参加。而实际上,它应该来自项目的各个方面,其中包括来自项目组、客户及其它项目干系人的反馈及项目管理信息系统(PMIS)。同时,使用这些信息以前,应确保收集这些信息的系统、组织和流程能够正常运行,并且应建立项目信息的收集、发布、存贮、更新及检索系统,确保有效地利用项目中的各种信息资源。

从管理的观点来说,项目生命周期的每个阶段或者称之为里程碑,都应该进行评估总结,以确定是否实现了此阶段的目标,项目是否可以正式开展下一个阶段工作。总之,项目的不同阶段都应该有完善的项目总结,只不过总结的形式、内容、编写者和阅读对象等侧重点不同而已。

在编写项目总结报告时,应该首先明确编写的目的,同时也应简述项目概况、项目背景和项目进展情况。因为既然叫项目,就有其独有性、时间性,这样项目总结的内容才能够更具有针对性、时效性和持续改进的意义。

最后,Paul根据美国项目管理协会(PMI)的项目管理框架,把项目总结的框架提纲分成以下几个方面来进行

项目总结的框架

项目进度

按照项目整体计划或项目滚动计划编写的计划工期与实际工期之间差距和原因分析。其间有哪些变化?对工作量的估计如何?以便为项目经验库提供相应数据,提高下次计划的准确性。

项目质量

项目的最终交付物与客户实际需求的符合度。需要注意的是“客户”,他可以是一般意义上的外部客户,也可以指内部的客户。项目质量管理不但包括对项目本身的质量管理,也包括对项目生产的产品进行的质量管理。具体可以从质量计划、质量控制、质量保证入手,以保证项目质量的持续改进。具体可以采用ISO质量保证体系,加上完善的质量管理工具、图表等辅助工具加以统计分析,得出改进建议。

项目成本

就计划成本、实际成本对比成本构成明细的差距和原因分析及建议,也包括项目合同款执行情况的分析总结。IT项目经理一般可控制的成本主要是人工费,对于未建立项目级核算的组织,可以用加权人天数表示,对不同级别的人员(项目经理、高级工程师、一般工程师)赋予不同的权重。

项目风险

就风险识别、风险分析和风险应对中的经验和教训进行总结,包括项目中事先识别的风险和没有预料到而发生的风险等风险的应对措施的分析和总结。也可以包括项目中发生的变更和项目中发生问题的分析统计的总结。

项目资源

项目资源不但包括人力资源情况,而且还包括设备、材料等其它资源的合理使用、开发情况。特别是项目成员的绩效统计分析和评价,以便更加有效地开发和利用人力资源。通常,可以采用直观的图表形式来反映项目的资源情况。

项目范围

项目范围包括产品范围和项目范围。其中,产品范围定义了产品或服务所包含的特性和功能;项目范围定义了为交付具有规定特性和功能的产品或服务所必须完成的工作。合同中所规定的产品范围和项目范围以及用户确认的计划等都属于项目中要控制的范畴,另外还包括实际执行情况的差距和原因分析。

项目沟通

沟通是人员、技术、信息之间的关键纽带,是项目成功所必须的。在国内,不少项目经理对沟通不够重视,或者不知如何做好项目中的沟通工作,这都需要各级项目管理人员对其加以重视。在项目总结时,可以就项目过程中的内部、外部沟通交流是否充分,以及因为沟通而对项目产生的影响等方面进行总结。

项目采购

国内IT项目的项目经理一般对项目采购接触不多或接触不到,多由商务和财务部门负责。如果是项目级的核算,采购管理是很重要的组成部分,否则可能因采购过程中的成本、风险、进度、技术和资源等方面引起很多问题。

项目文档

项目文档,包括硬拷贝文档和电子文档,都应该收集、整理、编制、控制和移交,以便统一归档保存和进一步开发利用。文档是过程的踪迹,它提供项目执行过程的客观证据,同时也是对项目有效实施的真实记录。项目文档记录了项目实施轨迹,承载了项目实施及更改过程,并为项目交接与维护提供便利。此外,项目文档还是项目实施和管理的工具,用来理清工作条理、检查工作完成情况,提高项目工作效率。所以每个项目都应建立文档管理体系,并做到制作及时、归档及时,同时文档信息要真实有效,文档格式和填写必须规范,符合标准。

项目评价

项目评价是对项目交付物的生产率,产品质量,采用的新技术、新方法、项目特点等的总结。另外还应该包括项目客户满意度收集统计和分析。客户满意度调查内容不但包括项目管理或流程层面,也应包括技术层面。同时,有必要说明本项目与以往项目相比的特别之处。例如:特殊的需求、特殊的环境、资源供应、新技术新工艺等,总之是具有挑战性的、独特的事件以及关键的解决方案和实施过程。

遗留亟待解决问题

说明项目有无遗留亟待解决问题。如果有,必须针对这些问题进行深入分析,明确责任,提出解决方案。

经验教训及建议

不断将实施过的项目中的技术经验、管理经验以及教训等进行总结,积累起来就可以成为公司的财富。

在上面的案例中,Paul总结出的项目总结模板和项目总结流程在A公司的推广和使用,在加上公司领导层的重视,以前A公司项目中重复发生的问题得到了有效的控制。

以上是项目总结时应该包括或者应该注意的几个方面。总之,项目总结应该根据不同的汇报对象,提供有针对性的内容。因为不同的报告阅读者需求不一样。例如,像公司级项目主管领导,他可能只关注项目收款及影响收款进度的原因、项目验收计划、项目中的重大事故或问题。技术经理可能更关心项目中新技术、新流程、新工艺的采用情况及效果。质量经理可能更重视项目的质量控制、变更、风险、问题报告。项目经理应该尽可能要求项目团队所有成员提交项目总结报告,因为每个人都会根据自己的知识、经验和能力,就所承担的不同工作、不同项目阶段,提出不同的问题和建议,这样能够从不同侧面来总结项目,更好地为下一阶段或以后的项目提供有意义的参考。

最后,需要强调的是,项目总结不能报喜不报忧,特别是对于失败的项目,总结会不应该成为批斗会,要坚持对事不对人的原则。这样项目总结才能够顺利开展,并对今后工作有指导意义。

 
相关文章

项目流程_IPD
EA中的项目管理-计划与跟踪
大型项目中的敏捷项目管理实践
敏捷项目管理概述
 
相关文档

IPD体系框架下的项目管理
项目管理基础与敏捷开发入门
IT项目管理培训
软件项目管理
 
相关课程

软件开发过程中的项目管理
基于IPD的项目管理方法与实践
敏捷项目管理实践
项目管理高级实践
 
分享到
 
 
     


如何有效地进行项目沟通
如何进行项目计划及质量管理
IT项目风险管理案例和应对之道
组建高效快速研发团队的必要
一个甲方项目经理的自白
TFS使用指南


软件项目管理
软件开发项目管理
研发项目管理
高级项目管理实战
敏捷项目管理实践
项目风险管理

相关咨询服务
建立项目管理规范


中国银行 IT外包项目管理
北京软件项目管理
某电子软件中心 项目外包管理
某电信服务商 项目外包管理
富士 软件外包项目管理与进度
Schneider 项目管理+软件质量
中国电信 软件项目管理