项目管理失败的原因

上传人:枫** 文档编号:506419170 上传时间:2023-07-04 格式:DOC 页数:8 大小:43.52KB
返回 下载 相关 举报
项目管理失败的原因_第1页
第1页 / 共8页
项目管理失败的原因_第2页
第2页 / 共8页
项目管理失败的原因_第3页
第3页 / 共8页
项目管理失败的原因_第4页
第4页 / 共8页
项目管理失败的原因_第5页
第5页 / 共8页
点击查看更多>>
资源描述

《项目管理失败的原因》由会员分享,可在线阅读,更多相关《项目管理失败的原因(8页珍藏版)》请在金锄头文库上搜索。

1、项目失败分析1.为什么要讨论失败大家都知道,失败是成功之母。著名的哲学家Karl Popper说:知识实际上是通过失败,而不是通过成功来获得的。牛顿的理论被爱因斯坦的理论所补充是因为牛顿理论不能解释某些现象,而爱因斯坦的理论正在被更新。在通常的实践中也是如此。当关于为什么会失败的根本原因(理论)被发现以后,其他人就可以采取行动防止类似的失败重演。许多具有新闻价值的项目失败(包括生命或者重要资源的损失的失败)最后都有一个公开结果的调查或者研究。然而大多数失败并没有得到完全的调查,尽管需要如此。对于项目失败的分析是基于学习和提高的精神。2.什么是项目失败任何失败都不是孤立发生的,也就是说,失败实际

2、上是从一个特定的系统产出。从这个意义上来说,所有的失败都是系统失败。广义地说,一个系统如果符合下面两种情况之一它就会失败。_导致项目失败的两种情况它不满足系统所包含的管理者、用户,或者其他受影响的项目干系人的要求。项目失败通常意味着不能满足成本、工期安排、绩效、质量、安全或者相关的目标要求。它产生了那些参与系统的项目干系人不想要的结果。一个失败的项目不能满足用户或者开发者的期望,或者结果比他们所期望的更糟糕。_项目失败的标准可以从以下两个角度观察当一个已经确定了价格的项目成本超标时,开发者必须承担额外的成本,遭受利润损失或者利润减少。从开发者的角度来看,项目是失败的。项目最终产品不能被接受或者

3、使用,尽管它是按照工期,在预算范围内,根据规范交付。这是用户或者其他的项目接受者所经历的项目失败。这两种失败,即项目开发者失败和项目用户失败可能是互相排斥的。就是说有一方失败,可能使另外一方得到好处。比方说,一个失败的项目,项目开发者破产了。但是他的用户或者反运作人,从项目当中赚取大量的利润。当然,这两种失败也可能是一致的,如一个建筑物倒塌所引起的生命损失,对所有人来说都是一个失败。3.造成失败的原因有些失败是不可避免的,因为它们超出了人力所能预期、避免或者影响的范围。这种类型的失败源于天气或者劳动力问题、难以解决的技术难题以及其它不可预见或者不可控制的外力。但是,这并非是大量项目失败的原因。

4、相反,失败通常是由于“缺陷”引起的,这些缺陷存在于:_项目和用户组织态度、实践和结构。_项目最终产品硬件、软件和组成部件。这些缺陷通常是相互联系的。例如,尽管硬件失败是因为部件和程序的缺陷,但这些缺陷通常可以追溯到设计时的失误,接下来又可以追溯到在设计和管理过程上的失误,这些失误使得错误没有纠正就过关了。也就是说,计划和控制项目的系统,即项目管理系统内的缺陷可能允许和导致低劣的设计、糟糕的质量控制、不充分的检查,最后导致最终产品本身的失败(“硬件”或者“部件”的失败)。【案例】1986年“挑战者号”航天飞机的失败和它的七个宇航员的丧生,尽管是不完美的硬件设计直接导致了这起爆炸,但根本原因是项目

5、组织中不称职的有缺陷的管理,它们让设计错误未加改正就通过了。挑战者号事故的直接起因是有缺陷的O型环火箭助推器上的封条,就是它们使得热废气泄漏并触发了外部燃料箱的爆炸。然而,大家都知道而且有明确文献记录说这种封条在某些温度下的表现很糟糕,这样就会对飞行安全造成严重的威胁。在悲剧发生的当天,有好几位工程师警告说封条可能会失效,但这些警告没有引起人们的注意,仍然做了升空决定。先前保留并非最优化的封条并批准发射的决定是全然不顾警告的管理决策,它忽略了大量的反面信息。很容易就可以得出这样的结论:事故是有缺陷的管理系统的产出。从这一点来说,实际上航天飞机的发射失败,是由于错误的管理系统产出而导致的。由于错

6、误的管理决策忽略了一些非常有价值的警告信息,最后导致了巨大的财产和生命的损失。类似的问题,在大大小小的项目中都是普遍存在的。也就是说,很多项目失败的根本原因,实际上并非是难以解决的技术问题,也不是不可控制的外力,不是用户,仅仅是由于不良的项目管理、有缺陷的项目管理系统、项目的组织实践或过程导致的结果。项目失败的项目管理原因导致项目失败的项目管理原因可以分为3个层次、14个原因。第一层次:项目管理环境中的失败这些失败的根源可以追溯到项目组织与项目目标、项目任务、高层管理部门以及更大的环境之间的不适当的“配合”。它们包括使用对于项目目标和项目环境来说不正确的项目管理方法或模型,以及缺乏高层管理部门

7、对项目的支持等。1.不恰当的项目管理方法项目不具备正确的组织结构、项目经理或者团队(以技能、经验、权力、正规性、复杂性来衡量)来“配合”项目。例如:_项目组织结构、计划和控制与项目环境、项目经理的哲学,以及公司文化或目标不一致或者不协调。_更多的重点放在保持团队的忙碌而不是放在结果上。团队成员分配没有考虑其适合的技能和经验。_要么是没有人对整个项目负责,要么是项目经理的责任、期望和权力不明确或者未定义。_一个在过去的项目中成功的项目团队、项目经理或者项目结构被“塞”进一个新项目,而不考虑当前项目的独特要求或者当前项目环境的不同特征。2.缺乏高层管理部门的支持高层管理不给予达成项目目标所必需的积

8、极的、持续的支持。例如:_高层管理部门没有把足够的责任或权力下放给项目经理,或者没有支持项目经理的决定或行动。_公司没有按照高效的项目管理所需要的政策和程序做出改进(预算、计划、控制系统、报告和授权关系等)。_高层管理部门没有参与审阅项目的计划和进程。第二层次:项目管理系统中的失败这些失败的根源可以追溯到项目领导及错误实践。它们包括项目经理在项目生命周期中对系统方法的忽略,以及项目管理技巧的错误应用等。具体的可以归结为:1.不胜任的项目经理担任项目经理职位的人不具备领导和管理项目的背景、技能、经验和个人品质。例如:_项目经理不能面对矛盾,不能提出深层的、探索性的问题,不能为了项目的最大利益而进

9、行有效的辩论。_项目经理不能对一个传统的工作环境做出调整来适应项目的变化和不确定性。缺乏在短时间限制和有压力的环境下高效工作的能力。_项目经理在技术和管理技能上不能令人满意。有时这源自于所谓的彼得法则的变更:将一个优秀的技术人员任命到一无所知的管理职位上。_其它的情况是,项目经理具备管理才能,但是对具体的管理细节如此的投入以致于忽略了关键的技术问题。这样就缺乏在项目团队中的相关方面发号施令的能力和号召力。2.忽略了项目的系统本质项目没有被当成一个系统来对待。项目的单元和步骤被划分成独立的部分,而没有考虑它们相互之间的作用。例如:_硬件、软件、资源和设施被单独的看待而没有考虑它们与整个项目目标的

10、关系。将重点放在各个单独的活动上而不是放在项目总体目标上。_系统开发的演变过程被分段地看待,而没有考虑随后的或者先前的阶段。这在对于未来阶段糟糕的计划和对于过去阶段不恰当的评估中表现很明显。问题从一个阶段传送到下一个阶段。3.管理技巧不恰当或者错误的运用项目管理技巧被曲解或者被不恰当地运用。问题在于项目经理、项目团队或者被运用的技术本身。例如:_项目经理未能将非项目技术的计划、协调及控制与项目活动所需的技术区分开来。如PERT、WBS、绩效分析和团队建设等,这些技巧被错误的应用或者根本就没用上。_项目经理未注意到项目的人力、行为方面。他没有建立一个项目团队,帮助团队成员理解项目目标,也没有激励

11、项目团队成员朝着目标一起工作。_用到的技术太复杂或者太简单而不适合特定的项目。工期安排和报告对于项目决策来说过于详细或者不够详细。更简单、更恰当、更适合小型项目的能动性技巧因为偏爱复杂的(但是笨重的或者不需要的)计算机化的报告系统而被忽略了。第三层次:在计划和控制过程中的失败这些失败的根源来自于项目计划和控制过程。一些错误的源头,像效率低下的沟通和不充分的用户参与,会在项目的任何阶段发生,需要给予持久的注意。其它的,像不恰当的定义、估计、工期安排或者控制等主要发生在项目的某些阶段。1.项目中没有良好的沟通这些问题的产生是由于信息的质量、准确性,或者时间性的缺乏,以及粗劣的数据收集和记录,或者未

12、能将信息分配给那些需要信息的人。例如:_在项目的早期,关于目的、责任和接受标准的信息没有做成文献资料。_在项目中没有关于项目状态或者对于计划或最终产品的变更的信息记录和报告。_没有召开足够的会议来收集和发布信息。讨论没有足够深入,也未能提出探索性的问题。对项目开发没有做项目日志或者审查记录。2.没有用户的参与用户或者顾客未能参与计划、定义、设计、实现过程,用户的需要被忽视。这是最经常被提到的项目失败的根源之一。_用户可能感到尴尬或者不舒服因而想尽力减少参与。一些用户被邀请的时候甚至抵制参与。_项目团队的行为阻碍了用户的参与。项目团队的成员可能表现高傲,这使得用户感到自己被忽视或者感到自卑。这样

13、的行为限制了用户与项目团队之间的信任,使相互的沟通变得紧张。3.不充分的项目计划项目细节的分析和计划不充分、马虎,从以前的项目得来的报告和建议被忽视。管理不是预先做好准备,而是当事情出现的时候才做出相应的安排。4.不充分的项目定义模糊不清的、错误的、让人误解的项目定义或者缺乏项目定义是被经常提到的一个失败的原因。对于技术要求、任务或者项目范围没有正式的定义。定义问题来源于:_缺乏提案、WBS、责任矩阵以及工作责任等的定义,或者这些提案的定义准备得很糟糕。_在定义项目范围、任务和要求的时候缺乏用户的参与。项目团队对用户的操作一点也不熟悉,不能指导一个与用户的要求相关的设计。5.糟糕的时间和资源估

14、计对资源需求、活动工期、完成日期的估计不现实。糟糕的估计发生是因为:_没有利用类似项目的标准或者文件来估计本项目会持续多长时间。_做估计时没有考虑员工的经验,而是假设所有的职员都是专家,他们都可以毫无差错地工作。_估计是由不熟悉细节问题的人做出的,那些负责工作的人没有参与做估计。_没有足够的时间来做估计。_用户施加压力,要求项目快速完成,这就导致制订了不切实际的完工日期,并删除了“不必要的”任务,诸如文件记录等。6.不正确的工期安排和资源处理工期安排和资源分配不正确、没有预期工作、没有备用资源。_未能预期估计资源需求并做好预先安排,当资源问题出现时才进行处理。没有显示项目中可用技能的详细目录。

15、_项目职员被重新委任或者整个换掉,但没有调整工期安排以弥补失去的时间或者学习时间。7.在执行阶段为数众多的变更对原始要求做了变动,但没有对相应的工期安排、预算或者计划的其它部分做改动。这种疏忽导致不充分的项目沟通、低劣的项目定义、用户参与的缺乏以及马虎的项目控制等。8.不恰当的控制项目管理不是预期可能有什么问题而是在问题出现的时候才进行处理;控制集中在对于日常事务的处理而不是向前看潜在的问题环境;直到项目结束日期,管理部门才查看项目是否准时。控制问题的根源:_工作任务的定义太大而不能进行有效的控制;工作组或者工作团体太大而不能被监督;里程碑太远以至于不能对项目进行分步监测。_不遵守设计、记录、测试或者评估的标准或规范。审计员没有进行仔细的评估。_在项目早期出现问题时没有尝试去解决。控制过程不是前瞻性和预防性的,而是回顾性和修补性的。_对于为保证项目目标的完成所需要的资金没有预测或者计划。9.项目终止的计划很拙劣不知道什么组成了项目的完成或者最终产品,接受的标准是什么,或者谁必须终止项目;没有正规的终止程序来处理目标、绩效、最终产品、以及维护问题等;这些问题经常和拙劣的项目定义以及缺乏用户参与联系在一起。_当项目终结还没有

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 建筑/环境 > 建筑资料

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号