关于项目失败的小结

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

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

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.项目终止的计划很拙劣

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

? 当项目终结尚未被清楚的定义时，项目甚至在通过长时间的中止后仍然被容许继续进行以作出有成本效益的进步。

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

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