当项目灾难来临时该怎么办
据统计,IT项目开发中80%是不成功的,有些甚至是灾难性的后果,最近刚好读到《项目灾难拯救之道》的书,这是一本翻译版本的外籍书,这本书全面分析了关于项目开发失败产生的原因及处理方法,这里把书中的一些要点摘录出来与大家分享。
对于项目灾难发生时,书中提到约克大学的约翰.麦克德米德教授的处理方法,约翰.麦克德米德教授是信息技术(IT)项目及其问题领域的专家,他指出,对于扭转失败项目,有五个很重要的步骤:
1.以诚实和坦率的态度来对待灾难。
“不要对传达信息的人开枪。”
第一步是要意识到问题的存在,并诚实和坦率地面对它,这样做当然并非易事,令人烦恼的推诿文件普遍存在于社会和许多组织之中,并打击着那些意识到问题存在的人。难以承认事情错了是项目灾难产生的原因之一,如果问题能够及早被揪出来治愈它们,比留着以后再解决要更省钱、更简单。
2.明确根本原因。
“评估而并稽查。”
当评估一个沉陷困难的项目的状态时,很重要的一点是先不要动手去处理它,就好象你是一个挑剔的稽查员,否则,这又是“推诿”的问题的。你这样做只会带来敌意,却不能推动事情向前发展,当请外部人员来帮忙解决问题时尤其如此。如果他们采取了类似于稽查的方式,人们极有可能隐藏信息来保护自己。人们更需要的是一种评估,来外部看待项目状况的观点。其目的是明确做了或还不做什么事情,计划做/不做什么事情等。
“不要只找一个原因――继续找。”
当你分析得出问题的原因时,不要仅仅停滞于找到的第一个可能的原因,因为它不太可能是惟一的问题根源。
3. 找出解决方法。
在扭转失败的项目时,存在四个关键变量:规模、时间、资源和质量。任何想要拯救项目的人都需要考虑所有这些变量,而且也只有充分考虑到这四个变量才能得到一个比较好的结果。通常,在变量之间存在一定程度的相互作用,例如,没有跃然的资源可能还预示着时间也不够用了。
对于规模,他说:“我们能丢弃什么?”――这是我们所需要问的第一个问题,这个问题可以被分解为:什么是项目必需的核心成分,少了它们就不能产生其他任何东西?最快能得到什么要素?我们应该谨记,“伟大的企业获利最快”。我们不能仅仅因为比较容易对某些地方进行调整就去那样做了,而应该优先考虑与顾客需要有关的方方面面。
对于时间,他说:“虚假的期限vs.真实的期限”,人们很容易为满足内部的最终期限而失去自制。在达成客户交付的关键环节上,哪一个是真正的最终期限?哪一个只是在评估进度时可能有用,但其自身并不是重要的里程碑?弄清它们之间的区别是很重要的。
对于资源,这里存在两个重要的问题:拥有足够的资源和拥有合适的资源。两者都很重要,缺一不可,拥有过多不当的资源几乎等同于没有任何资源。通常,人们倾向于在项目中投入过多的资源,但遗憾的是,这并不起作用。可以用挖洞这个传统的比喻来形容这种状况,虽然人很多,但是洞里的空间只有那么大,只有有限的几个人能够进得去。
对于质量,他说:“优秀就好,不求完美。”在有些项目中,问题是存在于太多的“质量”要求,项目沉浸在了质量评估和文件的海洋里。但是,在更多的情况下是没有对质量做出充分的要求,即没有足够的检查来保证交付物达到了既定要求。项目质量计划是用来保证交付物符合若干要求的(如果没有质量计划,就如同没有风险计划一样,那就应该问自己“为什么没有?”,这是一项重要的遗漏)。至于质量文件,当事情变得很糟糕的时候,人们常常容易抛弃与质量有关的活动。一个较好的的解决方法是,评估一下为了帮助项目完整交付所需要达到的最低质量,即使这意味着增大而非减轻工作量。作为最低限,质量文件通常包括包括质量责任、产品描述、适用标准、适用方法以及某种检验计划。
4. 实施拯救行动。
如果知道了问题的原因所在(更有可能是多个原因),就应该采取补救措施以得到可能得到的最好结局。归结起来,就是的制定出一份计划来说明谁将做什么,在什么时间怎样将新的项目交付给客户,并就新的交付结果和时间表与客户进行沟通。这常常是一个反反复复的过程,这时谈判会很重要的。另个很重要的一点是,要能够展示出所提出的补救措施很有可能会成功。在这一点上,可信度意味着一切,因为如果补救行动失败,则几乎不可能再有另外一次机会了。出于公共关系的原因,我们有必要让其他人而非原来的项目经理,来提出补救方案,可能的话还会让他来管理补救行动计划。这一行动不仅需要行之有效,而且需要能够欣然接受它的交付方法。我们应该记住,大多数是对实现项目的利益,而非项目交付的方法,更感兴趣。
5. 实施持续的管理控制。
假设一起灾难被部分或全部化解了,那就应该采取措施以防止重蹈覆辙。仅仅解决已经发生的问题是不够的,消除问题的原因也很重要,尤其是当原因归结为管理不善时。在理想状况下,这些原因是工业标准的问题,而我们能对其加以改善。如果所使用的工具能为人所广泛理解,这会有所帮助,因为这会使获得资源和沟通更容易进行一些。而有一些方法则非常复杂,以致人们还没来得及学会使用,新的灾难又降临了。
在一般情况下,所采用的任何方法都需要明确以下几个方面:
1、报告:对演变趋势和进展做出简单明了的确定;
2、目标和要求:必需明确地传达这些内容,并能够为人所理解;
3、交付物:明确指出内部和外部的交付物;
4、变量:设定一种机制为辨识、控制、批准和监控变量;
5、风险:必须有助于提高认识、评估、计划和监控新的或正在发生的风险;
6、任务:要有可能让每一个人都明确所需要的全部工作要求;
7、衡量:必须要有(简单的)衡量标准来确定项目是否达到目标,因为如果你不能衡量项目,你就不知道它是否完成了。
任何经历项目灾难的组织最后都应该有一个彻底的总结,以明确以下几个方面:
1、原因;
2、哪些地方做得较差;
3、应该做什么(却没做)来扭转危机;
4、做了什么(本不应该做的)使得事情变得更糟;
5、应该做什么来改善结果;
6、下次怎样能够防止重蹈覆辙。
很重要的一点是,如果要指出真正的、需要学习的经验教训,就必需彻底消灭推诿文化。
项目灾难发生以下这些策略是不可取的:
1、什么也不做
这种策略之所以危险,是因为它错失了让当事人接受不可避免的事情终于发生了的时机,最终会耽搁实施补救措施的时间。
2、隐瞒事实
这种策略也是在于错失接受现实的时机。一旦真相败露,人们就不会再相信那些曾经隐瞒真相的人了。
3、辞职
首先,即使负责项目或工作的经理(或任何人)工作做得并不好,但调离他们也不太可能最终解决问题。只有针对真正引发灾难的原因采取一些措施,才会使情况在长期内变好。这项工作如果没有处理好,对项目团队中其他成员的士气也会产生负面影响,甚至可能影响到整个组织。而且,给团队引入新的管理层,会不可避免地再经历一次新团队的形成过程,并降低它的生产力。因为项目已经面临灾难,无论采取什么策略,挽救措施都不会在瞬间成功,但这也许是应该付出的代价。
4、违反协议
违反协议约定的义务并不是一件轻松的事情,肯定获利的人只有律师,他们无疑要收取大量的费用。即使他们能够帮助组织直接从灾难中摆脱出来,但可以肯定的是,违反协议的条款越多,与客户的关系就会越紧张,在不久的将来与该客户也不大可能再进行交易了。而且,那些为这个项目工作的人也会受到打击,一些人可能会离开,整个团队的士气也会受到破坏,这个组织的声誉也会受到负面影响
5、投入更多资源
首先这个策略是基于一个错误的前提。更多的资源并不一定能提高效率,仅仅盲目地在出现问题的环节投入资源,这对解决问题是不会有任何帮助的。其次,通常是有限供给的资源(财务、人或机器设备方面)的来源问题。即使项目问题得到解决(可能不是由既定的原因引起的),但非常有可能在该组织的其他地方引发连锁反应,进而引发其他许多灾难的发生。最后,成本不断增加(极少甚至负的收益),再加上进展不力,会带为更大损失和低落的士气,其结果会将灾难演变成毁灭性的惨败。
6、归咎于转包或分包商
这个策略比较危险,因为管理转包(分包)商是整个项目团队工作的一部分。期望客户认同转包(分包)商的延误导致了项目的延误,如果确实如此,那就是项目经理没有看出问题以及没有采取必要措施,因此在某些地方就会很容易出现问题。
7、归咎于客户
供应商很少能够通过责备他们的客户而得到想要的结果,就像归咎于分包(转包)商那样,管理客户也是项目管理或会计部门的职责之一。如果这个团队让既定的管理范围(有时称之为使命)慢慢发展到不可控,或监控失败以及对变动失去控制,那么这就不是客户直接的错误了。
联系客服