当项目灾难来临时该怎么办

 

当项目灾难来临时该怎么办

据统计，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、归咎于客户

供应商很少能够通过责备他们的客户而得到想要的结果，就像归咎于分包（转包）商那样，管理客户也是项目管理或会计部门的职责之一。如果这个团队让既定的管理范围（有时称之为使命）慢慢发展到不可控，或监控失败以及对变动失去控制，那么这就不是客户直接的错误了。