关于项目失败的小结

转自http://jueshitou.blog.51cto.com/385947/481070

有那么一则笑话,讲的是养鱼。养鱼每周要换次水，我常忘。就只好每周换次鱼了。我觉得世界的事物总有那么一丝相似的地方。比如这个养鱼的笑话，和我们这次项目管理失败的总结有一些相似之处。

这次讨论一下项目管理的失败，为什么讨论失败？有句话说失败是成功之母，我们讨论失败，是为了规避失败，趋近成功。也就是那句话，大方向对了，通向成功也只是拐个弯而已，但如果错误了，离成功只会越来越远。

1.什么是项目的失败？

一般情况下，它不满足系统所包含的管理者、用户，或者其他受影响的项目干系人的要求。项目失败通常意味着不能满足成本、工期安排、绩效、质量、安全或者相关的目标要求。又或者我们开发出来的软件产品的功效与客户所需求的不能达成一致。

当然，从用户的角度和开发者的角度，项目失败有可能是对立的，比如一个失败的软件项目，耗费了开发者的成本，但是他的用户却从项目中获得大量的利好或者利润。失败只针对开发者而已。但其实，我认为，这只是一个经济上的暂时失利，而利好，却可能通过用户的口碑相传，得到另一个项目的开发机会。

? 太平洋老总严介和刚下海的时候，接一个30万的工程项目，但预算下来，预计亏损5万元左右。他跟手下说：“亏5万不如亏8万，就让他多亏一点吧”。结果，以最快的速度，最优异的质量用70天的时间干完原本140天的活。后来，验收的时候以各项指标全部优秀予以验收，赢得好评，接到上千万的工程。

所以从这个意义上说，有时候这个项目亏了，也赚了。但如果成本的超支，软件又没有满足用户的期望，那确是很糟糕的事。当然，先不考虑工程项目和IT项目的区别，比如工程项目有行业标准，而IT项目却没有。

2.造成失败的原因。

有些失败是不可避免的，因为它们超出了人力所能预期、避免或者影响的范围。这种类型的失败源于难以解决的技术难题以及其它不可预见或者不可控制的外力。不过，这并非是大量项目失败的原因。相反，失败通常是由于“缺陷”引起的，这些缺陷存在于：

项目和用户组织——态度、实践和结构。

??项目最终产品——硬件、软件和组成部件。

这些缺陷往往是相互联系的，比如，一个拙劣的软件产品通常会追溯到设计时的失误，而设计失误又可能是由于需求分析是不完全或者没有体现用户的期望，接下来又可以追溯到管理过程上的失误等等。而我们的缺陷管理或者说控制项目的管理又允许低劣的设计、糟糕的质量、不充分的检查因素没有经过纠正就过关，最终会导致软件产品本身的失败。

? 网上报账的工资发放单是一个自动流程，有HR系统发起，通过接口传到网上报账自动提交，大大的方便了用户的操作，而自动发起后的下一个环节，必须要设置好审批人，否则传过来的单子会将无法提交而搁置在系统里变成废单，无法提交或者退回，这样，必须要求实施者在配置流程的过程中按照一定的规则设置好。按照需求这项功能可能已经完成，但却也留下很多的缺陷，没有考虑到提交失败的处理，为以后系统出现问题埋下伏笔。这可能是一个缺陷管理的缩影。

3.项目失败的项目管理原因

导致项目失败的项目管理原因可以分为3个层次、14个原因。

第一层次：项目管理环境中的失败

这些失败的根源可以追溯到项目组织与项目目标、项目任务、高层管理部门以及更大的环境之间的不适当的“配合”。它们包括使用对于项目目标和项目环境来说不正确的项目管理方法或模型，以及缺乏高层管理部门对项目的支持等。

1.不恰当的项目管理方法

项目不具备正确的组织结构、项目经理或者团队（以技能、经验、权力、正规性、复杂性来衡量）来“配合”项目。例如：

? 项目组织结构、计划和控制与项目环境、项目经理的哲学，以及公司文化或目标不一致或者不协调。

? 更多的重点放在保持团队的忙碌而不是放在结果上。团队成员分配没有考虑其适合的技能和经验。

? 要么是没有人对整个项目负责，要么是项目经理的责任、期望和权力不明确或者未定义。

? 一个在过去的项目中成功的项目团队、项目经理或者项目结构被“塞”进一个新项目，而不考虑当前项目的独特要求或者当前项目环境的不同特征。

2.缺乏高层管理部门的支持

高层管理不给予达成项目目标所必需的积极的、持续的支持。例如：

? 高层管理部门没有把足够的责任或权力下放给项目经理，或者没有支持项目经理的决定或行动。

? 公司没有按照高效的项目管理所需要的政策和程序做出改进（预算、计划、控制系统、报告和授权关系等）。

? 高层管理部门没有参与审阅项目的计划和进程。

第二层次：项目管理系统中的失败

这些失败的根源可以追溯到项目领导及错误实践。它们包括项目经理在项目生命周期中对系统方法的忽略，以及项目管理技巧的错误应用等。具体的可以归结为：

1.不胜任的项目经理

担任项目经理职位的人不具备领导和管理项目的背景、技能、经验和个人品质。例如：

? 项目经理不能面对矛盾，分析问题，从而提出深层的，适合用户需求和项目原始需求的方法，不能为了项目的最大利益而进行有效的努力。

? 项目经理不能对一个传统的工作环境做出调整来适应新项目的变化和不确定性。缺乏在短时间限制和有压力的环境下高效工作的能力。

? 项目经理在技术和管理技能上不能令人满意。有时这源自于所谓的彼得法则的变更：将一个优秀的技术人员任命到一无所知的管理职位上。

2.忽略了项目的系统本质

项目没有被当成一个系统来对待。项目的单元和步骤被划分成独立的部分，而没有考虑它们相互之间的作用。例如：

? 硬件、软件、资源和设施被单独的看待而没有考虑它们与整个项目目标的关系。将重点放在各个单独的活动上而不是放在项目总体目标上。

? 系统开发的演变过程被分段地看待，而没有考虑随后的或者先前的阶段。这在对于未来阶段糟糕的计划和对于过去阶段不恰当的评估中表现很明显。问题从一个阶段传送到下一个阶段。

3.管理技巧不恰当或者错误的运用

项目管理技巧被曲解或者被不恰当地运用。问题在于项目经理、项目团队或者被运用的技术本身。例如：

? 项目经理未能将非技术的计划、协调及控制与项目活动所需的技术区分开来。如PERT、WBS、绩效分析和团队建设等，这些技巧被错误的应用或者根本就没用上。

? 项目经理未注意到项目的人力、行为方面。他没有建立一个项目团队，帮助团队成员理解项目目标，也没有激励项目团队成员朝着目标一起工作。

? 用到的技术太复杂或者太简单而不适合特定的项目。工期安排和报告对于项目决策来说过于详细或者不够详细。更简单、更恰当、更适合小型项目的能动性技巧因为偏爱复杂的（但是笨重的或者不需要的）计算机化的报告系统而被忽略了。

第三层次：在计划和控制过程中的失败

这些失败的根源来自于项目计划和控制过程。

一些错误的源头，像效率低下的沟通和不充分的用户参与，会在项目的任何阶段发生，需要给予持久的注意。

其它的，像不恰当的定义、估计、工期安排或者控制等主要发生在项目的某些阶段。

1.项目中没有良好的沟通

这些问题的产生是由于信息的质量、准确性，或者时间性的缺乏，以及粗劣的数据收集和记录，或者未能将信息分配给那些需要信息的人。例如：

? 在项目的早期，关于目的、责任和接受标准的信息没有做成文献资料。

? 在项目中没有关于项目状态或者对于计划或最终产品的变更的信息记录和报告。

? 没有召开足够的会议来收集和发布信息。讨论没有足够深入，也未能提出探索性的问题。对项目开发没有做项目日志或者审查记录。

2.缺少用户的参与

用户或者顾客未能参与计划、定义、设计、实现过程，用户的需求被忽视。这是最经常被提到的项目失败的根源之一。

? 用户可能感到尴尬或者不舒服因而想尽量减少参与。一些用户被邀请的时候甚至抵制参与。

? 项目团队的行为阻碍了用户的参与。项目团队的成员可能表现高傲，这使得用户感到自己被忽视或者感到自卑。这样的行为限制了用户与项目团队之间的信任，使相互的沟通变得紧张。

3.不充分的项目计划

项目细节的分析和计划不充分、马虎，从以前的项目得来的报告和建议被忽视。管理不是预先做好准备，而是当事情出现的时候才做出相应的安排。

4.不充分的项目定义

模糊不清的、错误的、让人误解的项目定义或者缺乏项目定义是被经常提到的一个失败的原因。对于技术要求、任务或者项目范围没有正式的定义。定义问题来源于：

? 缺乏提案、WBS、责任矩阵以及工作责任等的定义，或者这些提案的定义准备得很糟糕。

? 在定义项目范围、任务和要求的时候缺乏用户的参与。项目团队对用户的操作一点也不熟悉，不能指导一个与用户的要求相关的设计。

5.糟糕的时间和资源估计

对资源需求、活动工期、完成日期的估计不现实。糟糕的估计发生是因为：

? 没有利用类似项目的标准或者文件来估计本项目会持续多长时间。

? 做估计时没有考虑员工的经验，而是假设所有的职员都是专家，他们都可以毫无差错地工作。

? 估计是由不熟悉细节问题的人做出的，那些负责工作的人没有参与做估计。

? 没有足够的时间来做估计。

? 用户施加压力，要求项目快速完成，这就导致制订了不切实际的完工日期，并删除了“不必要的”任务，诸如文件记录等。

6.不正确的工期安排和资源处理

工期安排和资源分配不正确、没有预期工作、没有备用资源。

? 未能预期估计资源需求并做好预先安排，当资源问题出现时才进行处理。没有显示项目中可用技能的详细目录。

? 项目职员被重新委任或者整个换掉，但没有调整工期安排以弥补失去的时间或者学习时间。

7.在执行阶段为数众多的变更

对原始要求做了变动，但没有对相应的工期安排、预算或者计划的其它部分做改动。这种疏忽导致不充分的项目沟通、低劣的项目定义、用户参与的缺乏以及马虎的项目控制等。

8.不恰当的控制

项目管理不是预期可能有什么问题而是在问题出现的时候才进行处理；控制集中在对于日常事务的处理而不是看到潜在的问题环境；直到项目结束日期，管理部门才查看项目是否准时。控制问题的根源：

? 工作任务的定义太大而不能进行有效的控制；工作组或者工作团体太大而不能被监督；里程碑太远以至于不能对项目进行分步监测。

? 不遵守设计、记录、测试或者评估的标准或规范。审计员没有进行仔细的评估。

? 在项目早期出现问题时没有尝试去解决。控制过程不是前瞻性和预防性的，而是回顾性和修补性的。

? 对于为保证项目目标的完成所需要的资金没有预测或者计划。

9.项目终止的计划很拙劣

不知道什么组成了项目的完成或者最终产品，接受的标准是什么，或者谁必须终止项目；没有正规的终止程序来处理目标、绩效、最终产品、以及维护问题等；这些问题经常和拙劣的项目定义以及缺乏用户参与联系在一起。

? 当项目终结还没有被清楚的定义时，项目甚至在经过长时间的停止后仍然被允许继续进行以做出有成本效益的进步。

? 当用户没有参与计划时，对于最终的接受条件会有更多的分歧。在接受之后，对于最终产品的问题未加识别就通过，或者不管用户的不满而被允许继续向前。

诸如养小鱼，如何使它们都能存活，那怕一个地方出错了，都可能导致其死亡。项目管理亦不例外，因为成功的方式可能有很多种，但失败可能就那么一个错误就能导致，阿里巴巴马云说过，我不清楚我怎么做成功的，但我却清楚的知道我每一次是怎么样跌倒的。通过理解失败再去分析项目成功的重要因素，才能够保证项目在正确的道路上按计划不断地推进。