当前位置:首页 >> 正文

项目管理失败的反思:避免五种错误可提升项目成功率

[ 日期:2019-4-1 ]

恒佳PMP培训中心

(一)常见五种错误,会造成项目失败

每一个项目都是独特的,然而项目失败的根本原因通常都是相同的。当我们知道这些原因后,我们可以最小化发生问题的几率,增加项目成功的概率。

那么,当我们面对粗糙的项目启动、过弱的控制、缺乏资源、项目风险和不切实际的期望时,应该怎么做?以下是五个常见问题和解决方法可供借鉴。

简单粗糙的项目启动
也许最常见的问题是没有正确地启动项目,而这其实只需要花点时间去收集客户需求、同意客户要求、创立一个良好的项目计划以及设定客户的期望。而人们总是倾向于迅速开展项目工作。但是,一个简单粗糙的项目启动阶段经常会导致问题的发生,甚至项目的失败。

解决方法
在正确的项目启动过程完成之前不要开展项目工作。如果客户为了尽早得到可交付成果而推动你基于假设开展项目工作,请不要同意。事实上,简单粗糙的项目启动会带来返工、错误、疏忽、只会令项目变糟。所以,当项目被不合理推动时,只能说”不“,并且绝对不可太早开始。

过弱的项目控制
即便计划再周密、启动再充分,如果不能有效地进行管理,也是没有意义的。缺乏控制导致的典型问题包括:范围渐变、过于简单的工作计划、缺乏变更控制、缺乏沟通和风险问题的管理。

解决方法
(1)建立变更管理过程并且令所有人都知道这些控制。使用这些过程与保证你的团队保持关注与交付关键的东西。
(2)使用异常报告。这样可以保证当风险和问题出现的时候可以得到更好的关注。
(3)定期与客户、发起人以及其他重要的项目相关方进行沟通。
(4)定期评审、更新项目计划。如果项目计划没有评审和更新,那其实也没有必要制定计划。

缺乏人手和技能
项目人手不足,或者配足人员的数量却配错了技能组合,这些问题经常导致项目失败。当你的项目没有足够的、具有合适技能的人员,那确实是令人沮丧的。这个问题在当前的项目管理中非常普遍。
解决方法
坚持要求管理层提供合适的人员,无论是从内部调配还是雇用外包合同员工。使用可靠的项目计划来说明在哪些方面你还需要投入人员来支持你的要求。不要保持沉默并且苦苦支撑,这对你和你的团队都不公平。

没有强调风险和问题
在项目的生命周期中,有很多场合风险和异常会导致问题,甚至失败。这些例子包括:
(1)没有清晰的定义需求,结果不能满足客户的期望。
(2)使用前沿的新技术导致无法预料的问题。
(3)过于简单的技术设计使得未来的方法没有变更与伸缩的可能。
(4)无效的变更控制使得变更要求导致项目偏移原来的目标。
(5)测试不充分导致错误和缺陷遗留到产品上。
(6)在关键时刻缺乏关键人物的支持。
解决方法
在项目开始的时候对风险和问题列表进行评审。其中一个好办法是使用头脑风暴列出可能的风险和问题,参与人员包括项目成员、其他参与过类似项目的项目经理等。在整个项目过程中不断对风险和问题进行评审。

对上面例子中的解决方法包括:
(1)雇用商业分析人士勾画出客户的需求,并使用清晰、明确的文档进行记录。
(2)提问是否必须使用前沿的新技术,后者是否有能提供相同功能的更多方法。
(3)由你的团队进行技术设计。这样有很大的机会获得一个可靠和灵活的设计,而且你的团队也有了可以继续使用的基础设计。
(4)在项目启动之前与客户达成一个变更控制的流程,并且严格根据流程执行。
(5)将测试计划与根据客户要求制定的测试场景放在一起。保证你有足够的资源以及保证客户承诺进行测试。
(6)制定一个针对失去关键人物的风险的应急计划。

不能有效管理客户期望
通常项目开始都是在一个有很多乐观估计的基础上。在项目的生命周期中,客户期望会膨胀成为根本不现实的程度,当客户不知道他们应该期待什么或者他们不能看到项目的实际进展情况,他们就会对你感到失望,你们的关系就会破裂。 

解决方法
将期望值管理到一个合理的水平是项目经理的职责。其中一个方法是将项目分解为有多个里程碑的各个任务块或者项目阶段。你可以通过发布周期性的可交付成果给客户,让他们看得到他们将要得到什么。
通过这种方式让客户在早期就能看到你们在做什么,从而保证项目可交付成果能符合客户的期望。

(二)项目失败谁之过?

  3个月前,我新加入这家公司。很快我进入到一个项目里,这个项目是为某公司提供一个信息管理系统,主要是管理供应商的情况。当时项目刚处于初期,主要是获取需求,做DEMO,然后去为客户作演示。其中主要是我做开发,公司这边还有些其他人员(他们有一些客户关系)。我以前主要一直做系统的开发和设计工作,加入这个项目后,公司希望我作为项目的PM,来推动这个项目往前走,而我对这个客户行业(某工程行业)非常不了解,因此对获取需求毫无办法,虽然我也希望能参考一些类似的系统,但一直没有找到。所以基本上就是公司有客户关系的人零零碎碎的发过一些需求,然后我就去照着做。最近,客户终于认为我们的系统并不适合他们。所以这个项目可以说是失败了,于是,公司认为我没有达到要求,解除了合同。
  从我本人来讲,当项目进展缓慢时,没有积极主动的去寻求解决办法,缺乏主观能动性。
  想听听各位的看法。
  我认为我本人并不应该负主要责任,因为联络客户、拿到订单不应该是我的责任,当然这也需要能符合用户需求的DEMO。我本人并没有客户关系,也对行业不了解,没有需求来源,怎么能推动项目前进呢?

分析:首先在接手这个项目的时候就要和领导分析清楚这个项目是否能够达成目标;达成目标的前提条件是什么;如果项目失败了,后果是什么,由谁来承担责任......;其次考量一下自己是否能够胜任PM的角色;再者用户需求是开发DEMO的充分必要条件,需求不清项目已经就失败了。顺便说一句,边做边推进与客户的面对面交流是搞清楚客户需求的好方法。

分析:1.没有相关工作经验就不应该承担相关工作;2.应通过各种手段、渠道收集相关资料;3.遇到问题时应及时与领导及相关各方沟通;4.作为管理者,不能怨天尤人,而应通过失败总结原因,才能有所提高。

分析:身为一个PM,了解清楚客户的需求是最基本的,只有了解清楚后开发的产品才能满足客户要求,这个项目过程中缺乏PM的风险管理,沟通及及时上报协调资源的意识。

(三)项目管理之失败案例

引言:项目经理大部分时候都是只有一次机会
项目背景:公司只做传统WMS项目部分,总包是SAP项目,两个系统集成,需求来源前期全部是总包公司(坑1),实际与客户交流只有一次(公司项目管理坑2),项目经理是开发,一个比较喜欢开发的同事(坑3),总包项目经理大牛(坑5),客户许多需求都是按他的设计进行的,他能够说服客户

项目进行模式:瀑布模式,设计、开发、测试、UAT、上线
经历:当时我作为主力开发之一参与项目;设计、开发都没有问题,去客户现场UAT问题来了,大问题4类1、许多功能与界面未经过客户确认,修改许多,基本都修改了2、与SAP对接,由于他们的系统许多业务功能修改导致我们系统不断修改3、内部管理流程缺失,有问题现场修改,出现新的问题不断;4、客户前期什么都行,UAT各种需求提出;经过一个多月的试运行,用户许多新修改需求不断出现,我们不断修改,但是客户就不最终验收,这个时候还出现一次业务问题,SAP那边业务大修改,其中有拆分单据情况,导致我们系统无法识别拆分情况,系统崩溃,修改涉及到所有业务流程。(这个时候我们已经收到60%的钱,已经保本并有小部分盈余的,目前看应该重新签订需求变更合同或中止项目),sap项目经理说服了我们领导,公司继续执行修改,也是失败的根源。这次修改不只我们修改还有sap业务修改,双方也没有进行统一设计同步,导致系统修改后,他们的问题不断出现(与我们系统无关),我们系统跟随他们不断崩溃,最终修改了60%的需求与问题;三方想以此为结点,未达成一致(客户不同意,许多需求未实现);项目停止近1个月,SAP项目经理离职,我们项目经理 项也离职了。后期SAP新项目经理接手我们又支持了近一个月,已经延期了50%,领导拍板与sap谈判,要不中止项目,要不他们再掏钱我们做。最终失败!

结果:SAP项目经理离职不管了,我们项目经理也不久离职,项目失败
分析一下:坑1,需求自己不调研是有很大问题的,项目最终目的是做客户想要的东西;坑2,不管需求是不是自己调研的,需求的确认,详细沟通是少不了的,多开交流会是没有错的;坑3,开发型项目经理缺点就有是“追求代码完美”思想,管理上更多关注开发,需求与客户交流思想过少;坑4,总包项目经理太过自信,许多事他说了算,有些需求的确认也是他说了算,他说有本事说服客户,导致后期需求不断,一个项目经理可能在他的领域比较牛,在其他领域可能是小白;

总结:1、项目经理是项目的主负责人,项目失败了可能就滚蛋了2、传统项目管理模式已经快走到尽头了,不太适合当时的小公司项目模式了3、项目经理牛B就体现在项目范围的把控上,需求蔓延是最恐怖的;项目经理要与领导多沟通,时时提供项目数据,让领导能够知道项目情况判断项目风险(自己牛了也行)。问题:如果这个项目使用敏捷是否能够成功?

(四)一次失败的项目管理的反思

一、开始:
1.要有规划,并且铁一般的意志推进规划的执行!
2.规划不是大概,而是要有可量化的目标和标准,比如写作写了几页。
3.唯结果论,只有输入没有产出等于零。跑了一天code没写几页等于作废。
二、事中
1.不为未来而忧虑,不为过去而后悔。我所有的现在就是最应该好好把握的时间。
2.我不是一蹴而就的天才,当下没做的事情别指望下一刻就能勤快起来出现奇迹。
3.完成胜过完美。只要出了成果就可以不断修改,烂尾楼被返修成精装容易还是平底一夜起高楼的概率大?
4.带着目标、带着问题去做事,而不是盲目尝试,否则就是浪费时间。
5.写不出来其实是编不出来,有理有据阐述事实就容易多了。所以怎么想办法去做得扎实?
三、事后
1.只为成功学经验,别为失败找借口。
2.成功、勤奋其实是一种惯性,你尝到奋斗的甜头就会不断原因去拼搏,像滚雪球一样越来越容易成功。越努力越幸运!
3.拖延到最后那一刻全力爆发的感觉其实会上瘾,但是更想要玩个踏实睡个好觉的心安。 

(五)你的项目为什么失败?原因竟然是这个!

  小P说项目管理论坛
  在当前常见的大型复杂项目(集)之中,传统项目管理方法在应用过程中备受掣肘。不少项目问题的解决必须扩展到项目治理的层面予以解决,本文从决策角度探讨了无效项目治理的原因,梳理了建立有效决策项目治理结构的基本原则。

  目前项目失败的主要原因中,很大一方面在于继续沿用传统的项目管理方法来适应越来越复杂、越来越庞大的项目,随着项目、项目集涉及的利益相关方不断增加,解决项目问题所需要的资源无法只在项目管理层面得以解决,必须扩展到项目治理的层面予以解决。

  当前虽然对项目治理的研究逐渐增多,对项目治理的研究视角仍然比较分散。从众说纷纭的中外学者观点中可以提炼当前项目治理的要点:项目治理是针对项目主体的责、权、利以及项目活动的政策、程序的制度安排;项目治理的终极目标是实现组织目标,直接目标就是实现项目目标;项目治理应满足、协调好各个项目利益相关方的需求,明确各方职责。项目经理博客

  在项目进行过程中,为了适应不断变化的环境,决策的制定无疑是至关重要的,可以说,一个好的决策可以促使项目取得成功,一个差的决策也会导致项目的失败,所以有效的项目治理一定要处理好决策制定的问题。因此,项目治理也可定义为:为实现项目目标而建立的一个用于制定有效的项目决策,同时明确项目中各方职责的,满足各方利益相关方需求的,实施项目专用的框架结构。在这里,项目治理的重点是要保证项目决策的有效性,而导致无效项目治理的原因主要是不合理的项目治理结构影响了决策的有效性,具体体现为以下四个原因。转自

  偏离有效决策的核心目标

  项目治理的终极目标是实现组织目标,直接目标是实现项目目标,而实现项目目标的关键要素是有效快速地决策,所以项目治理结构的建立应当以能够快速、高效地制定项目决策为初衷和目标。当然,项目治理结构的建立也有其他目的,比如明确项目中各方的职责,满足利益相关方的需求,提高项目相关信息上下级传递的效率等。项目治理结构若是以这些目的为初衷而建立的话,就会出现无效项目治理的问题。

  如果以满足各方利益相关方的需求为核心目标而建立项目治理结构,那么就可能会将尽可能多的利益相关方纳入项目治理框架当中,项目治理框架的规模就会不断扩大,当参与决策人员规模过于庞大时,就会降低项目决策制定的效率和质量,这样并不利于项目目标的实现,会导致无效的项目治理。由于每个利益相关方都要参与决策的制定,那么其中在组织结构中有较高职位的人的意见分量就会较大,甚至会大于项目经理,并且这些利益相关方并不亲身参与到项目中,那么不仅会降低决策的质量,也会极大地影响项目经理和项目工作人员的积极性。

  如果是以提高项目相关信息上下级传递的效率,加强项目与组织的联系为核心目标,那么,项目治理体系框架主要的服务对象容易变成了组织的各层领导,便于组织时刻监控整个项目的实施进展情况,而不是为解决项目问题而服务的,并且通常这样的项目治理框架会逐渐被组织结构所覆盖,对项目目标的实现没有实质上的帮助,同样也会导致无效的项目治理。

  过度回避风险

  回避风险对每个组织来说都是至关重要的,在有的组织中,回避风险甚至是影响制定决策的最重要的因素之一。过度厌恶风险,尤其是个人风险,可能会导致决策制定缓慢低效,无法适应不断变化的项目环境需求。

  在非常厌恶风险的组织文化环境中,制定决策所涉及的每个项目人员都会想尽办法减少决策制定所带来的风险,尤其个人的风险。没有人愿意为决策所带来的风险负责,最终只能通过利益相关方联合讨论来进行决策,那么决策所带来的风险就会分摊到每一个利益相关方身上,每个人的风险都很小。这种制定决策方法的优点是制定出来的决策是得到每个利益相关方认同的,实施阻力很小,但是缺点也很明显。决策变得很缓慢,特别是在大型组织中,要经过各个层级、部门的讨论和批准,非常耗时,同时会降低决策的质量。如果使用联合讨论的决策方法,那么不可能在这么多人之间划分清楚责任,就没有人清楚地知道自己对决策制定的职责。那么这个项目治理框架必然是无效的。

  有的组织中,对风险的回避非常严重时,项目人员甚至会采用各种方法来避免自己做出决策,比如沿用传统的解决方案,或者收集大量的市场信息来调整措施,传统的解决方案是无法适应不断变化的市场环境的,而收集大量信息不仅会耗费大量的人力财力,也会延误最佳的决策时机。

  项目治理结构与组织结构混淆

  组织的结构、部门划分和责任划分都是为了满足和促进公司日常运营而设计的,而不是为了满足项目交付成果的需求而设计的。项目的工作与组织的日常运营工作非常不同,日常运营是持续性的,在稳定的组织结构中进行;而项目往往是相对短期的,在动态变化的环境中进行。所以项目需要用不同的结构来加以管理,也就是意味着项目不能依靠现有的组织结构来实现项目目标。

  很多组织中把项目治理结构与组织结构重叠在一起没有分开,此时决策制定时就会产生这样的问题:决策机构的层次会增加,决策需要经过组织结构的层层审批,从而会延缓决策的速度,而项目往往需要根据项目进展情况或突发情况进行及时决策,而如果沿组织结构进行决策就不能满足这一点;组织结构层级中参与项目决策的人员,一般并不熟悉比较复杂的项目工作,他们更熟悉日常运营工作,这就导致他们所做出的决策往往不是最适当的;决策过程中的责任不明确,在这种情况下不太可能明确区分不同人员的不同责任,一般会把决策链顶端的人默认为决策的负责人,但是这个人可能并不是对项目负责的最佳人选。

  把项目治理结构与组织结构相混淆的另一个重要影响是,项目的决策制定机构会缺乏必要的职权,无法相对独立地制定决策,受制于组织结构中的上级领导,决策的制定要经过各层级领导的审查批准,依然会产生决策缓慢、低质量的问题。各个层级的领导可能会对决策文件进行一些毫无意义的修改,或添加自己的建议,来体现自己对决策的贡献,但是这些领导可能根本不了解项目,甚至从未参与过项目,这样不仅会减缓决策的制定,更重要的是无法做出真正适合项目的决策,这样的项目治理同样是无效的。

  不当的利益相关方参与

  利益相关方对于项目的支持,对项目的成功具有非常重要的意义,缺少关键利益相关方的支持,很可能导致项目失败。所以在项目决策机构中必须包括核心的项目利益相关方,但要注意的是,不能让所有的利益相关方都加入这个决策机构。

  大型的决策机构通常很难进行高效及时的决策,一旦决策机构的成员超过六个人,决策的效率就会降低,这就是所谓的群体决策效应。项目决策机构的组成要合理,如果决策机构中利益相关方组成不合理,会导致利益相关方的不满。也就是说在组建决策机构时要确定哪些利益相关方应该加入决策机构,同时应该建立一个有效的机制来满足那些在决策机构中没有席位的利益相关方表达诉求的需要,如果不能做到这些,就有可能导致项目治理的无效化。

  小结

  本文仅从项目决策的角度出发,探讨项目治理层面影响项目失败的原因。当然,还有很多其他导致项目无效治理的原因,例如项目工作人员的能力、素质以及组织环境等,而且实际中这些因素常常并不是单独的而是混合在一起对项目治理发挥影响。

分享到: