【IT168 技术文章】

　　当项目半路抛锚时，在没有有效的外部干预下，将项目拉回正轨的机会将与日俱减。而接下来的问题将会成倍增长，团队成员的行为将会恶化，错误也会一犯再犯。

　　发现并对项目中出现的问题的具体症状进行观察，是进行项目救助及干预的前提。将症状与问题的起因区分开来尤为重要。一个问题的起因并不见得就会阻碍项目的进展。例如，缺乏具体的业务需求可能导致将来出现问题。然而，若项目小组成员之间拥有默契，就有可能通过与用户的有效合作，弥补该问题所带来的不便。

　　征兆性的症状其实是一个预警系统，它告诉项目小组应该对问题的具体情况进行进一步了解，同时也告诉项目经理应该深入探究是否需要进行项目救助，以及如果需要进行救助的话，救助的范围和程度应该如何掌握。

　　我们需留意的项目症状有十种类型，下文列出了进一步缓和这些症状的重要措施，以及一些亟需考虑的问题。如果你发现你的项目出现了其中任何一种症状，就可能需要对之重新进行审视。

　　症状之一：工期一拖再拖

　　项目的最后期限总是一延再延，其原因也各式各样，其中包括计划不周、意外频发及业务复杂等等。你也可以下一道死命令，要求项目必须赶在最后期限内完成，因为这很重要，但是这无异于自欺欺人。然而，不能遵循项目的进度安排或者不断地将项目延期，将会导致项目团队成员的行为变得非常糟糕。如果你的团队总是一而再再而三地贻误项目期限，那么你凭什么认为他们会改变这种行为呢?这些问题是贯穿于整个项目，还是仅仅局限于项目早期的几个阶段呢?谁应该为此负责呢?没有项目最终期限也意味着纪律涣散，缺乏约束。

　　项目经理可以将可交付成果分解开来，要求项目团队每两个星期就要完成一部分有价值且可衡量的成果。这样成果会逐渐越积越多。对于风险较高的项目来说，这个时间可以设得更短一些。对可交付成果进行管理使得项目监管变得更加容易，同时也能在连贯的基础上对风险进行管理。

　　症状之二：要求不断改变

　　即使大家都尽了最大的努力，还是有很多因素会导致项目要求经常发生变化。例如，新的想法被提出;原先的计划考虑不周;业务的利益相关者改弦更张等等。技术通常会带来更多的变化。关键是要搞清楚，是要求发生变化了、被修改了，还是有所补充和完善，抑或是被其他要求所取代，还是说一直保持稳定没有变过?如果某人一直在改变主意，那你就要怀疑他是否真的知道自己要的是什么。这种症状是项目出现问题的征兆，它预示着在项目预备阶段就有可能蕴藏着深层次的矛盾和问题。也许是对项目的预期并不明朗，抑或真正的决策者没有参与项目的决策。也许真正的利益相关者并没有被识别出来，或者虽然被识别却没有好好地向他们请教过。

　　要求不断发生变化，这对任何行业的任何项目来说都是不可避免的状况。其背后的动机是为了让客户和用户感到满意。然而，计划周全的项目建立在早先拟定的项目章程的基础之上，且该章程中所确立的时间表建立在具体的业务要求之上。这笔账很好算。项目要求的改变会影响到项目进度及项目成本，因此计划需要更新，而拟定的最终期限可能需要延期。

　　在项目启动之初，即应明确变更流程是如何操作的，以及何时需要应用这一流程。让相关方了解，未来的要求变更将要求项目团队再次发布项目信息。在要求发生改变之初，就应该让相关方了解它将对成本、利益和项目本身造成的影响。让用户或利益相关者在这些事实的基础上做出决策。

　　症状之三：决策摇摆不定

　　业务决策有始无终、摇摆不定是风雨欲来的征兆。这看起来虽然显而易见，然而许多项目，不论是二人小组还是价值五千万美金的大型项目，都有可能是建立在某个高层的业务愿景之上，而该愿景则是由若干尚未完成的“故事”大纲和业务章程组成的半成品。这样的愿景只能带着项目团队前进一小段，直到你发现由于项目缺乏清晰的目标而必须不断返工为止。

　　在项目生命周期之初，我们就应该确定以下几项关键业务决策：

　　·谁是企业的所有者-谁决定最终的项目验收条件?

　　·项目的最终产品应该是怎样的?

　　·缺陷率为多少是可以接受的?

　　·最终解决方案的绩效以及运作指标有哪些?

　　·业务准则有哪些?哪些是关键?在剩下的准则中，优先次序如何?哪些将会被用户所接受?

　　症状之四：行百里，半九十

　　当某位项目经理第一次听到项目已经完成了90%，肯定会觉得异常兴奋和开心。项目完成到这个程度应该是一周一周不断累积的成果，而且其成果应该是在定期的进度报告或进度会议上予以汇报的。然而进度报告可能会存在若干问题。该数据通常都是建立在对项目的不精确评估之上，或出自于项目经理、项目协调员的直觉。剩下10%有多复杂依然是个未知数，而且这个看起来较小的百分比还有可能让人掉以轻心。

　　事实上，项目倾向于滞留在这个阶段。当项目进度在相连的进度报告期间内停滞不前时，你就需要深挖其中的原因了。另一个预警信号是，项目进度突然骤减。例如，某个项目正以每周完成20%到30%的速度前进，而突然间你发现进度降到了1%或2%。这个时候项目小组也许才刚刚开始认真研究真正的项目要求，也许在早先的进度报告会议上他们都过于乐观了。

　　当项目进度走下坡路的时候，要好好想一想原因。这可能是由于新的项目要求所导致的，也可能是早期的进度汇报不真实的结果。通常，你所看到的下降比率可能并不会很低，因为项目团队出于主观愿望，会对进度报告进行一些修饰。所以问题可能远比报告上所显示的要严重得多。

　　症状之五：一切正常的假象

　　所有项目，只要不是太过微不足道，都会时不时碰到这样或那样的阻碍和问题。虽然其中的许多困难也许很容易被克服，但还是会出现。如果这些困难没有上报，就说明项目团队要么是对项目探究得不够深入，要么就是没有就相关信息进行沟通。

　　项目经理也许需要仔细研究当前的项目进展和可交付的成果，以确保所提出的问题正是要旨所在。如果项目真的进展得非常顺利，那么在到达某个阶段性里程碑时则理应庆祝一番。

　　症状之六：没有设定阶段性目标

　　项目的关键可交付成果，有时也被称作阶段性目标，不仅仅指的是项目的最终成果，还包括用以确保项目顺利进展的阶段性可交付成果。

　　没有阶段性或者最终可交付成果的目标预示着麻烦将至。如果要求提交阶段性或者最终可交付成果会造成混乱，那么就必须借助项目救助方案了。

　　当项目正处于下滑状态时，项目救助方案是一项旨在迅速改变其方向的阶段性的应对措施。这要求项目团队必须为实现某些利益而做出相应的妥协。同时救助方案还须为项目设定发展的步调及氛围，从而使得团队成员能够兴奋起来并做到人尽其才。

　　症状之七：人际纷争四起

　　在推进项目的过程中，人际关系问题不可避免会发生。然而，对人际关系处理不当，会导致难以挽留员工、员工扬言离职，造成员工间的不愉快、士气低下，出现恃强凌弱、自保反抗的局面，甚至引发无谓的口水战，以及各个层面上的政治纷争。

　　人际关系问题的出现警示我们应该探寻更为深层次的原因。由此而引发的其他问题将会浮出水面，包括质量不过关及贻误最终期限等。

　　症状之八：过多的质量问题

　　质量问题在项目的正常发展阶段也许并不明显，因为现在还尚未交付或尚未实现正常运作的成果可在日后另行交付。然而，质量问题的数量也不能超过一定的界限。质量问题诚然是困难的一种，但是你也可以在出现质量问题时决定是按下求救的按钮，还是认为这尚在可接受的范围之内而予以承受。

　　我们应在项目的各个阶段通过回答下列问题，对质量期望值及质量保证流程进行界定：何种类型的错误是可以接受的?错误孰轻孰重，如何解决?应进行怎样的测试，从而发现错误?

　　症状之九：面临未知因素

　　从项目管理的角度来说，在不显著增加项目成本或延长项目周期的情况下，试图预测或缓和项目的每一个风险变量是不可能的。

　　然而，利用有效的风险管理流程对概率较高、影响较大的风险进行定期的评估，将有助于让整个项目团队的成员了解，在风险真正来临之时应做出何种预期行为。项目计划无法解决的风险则需要借助项目救助方案来解决。

　　症状之十：缺乏项目报告工具

　　你肯定曾经多次听到过这种言论：“别把时间浪费在什么进度报告上了，实实在在地干活才是最重要的。”这种言论背后的观点都是非常高尚的，也可以被运用到任何项目管理工具或程序上。然而，在宣布进度报告完全无用武之地之前，我们还须从以下几个方面多加考虑。首先，如果出了问题，必须依靠这些报告工具来解决。其次，如果没有这些工具，当你知道有问题出现的时候已经悔之晚矣了。

　　由于缺乏项目报告工具，在那些没有向项目团队进行过汇报或沟通的领域内，铁定会出现问题。如能较早发现这些问题，也许能够将其克服。但是，缺乏报告工具通常意味着这些征兆将被忽视，直到已经太迟。

　　项目细节也许有所不同，然而项目出现磕磕绊绊、停滞不前，甚至完全短路的原因却是一致的。找出那些预示着问题的征兆，那么解决方案也就唾手可得了。这也就是为什么一个准确、及时的“诊断”是成功复苏和走向深渊之间的区别所在。诊断包括与管理层和团队成员进行面谈，以及对所有文件，包括进度安排、资源、业务和市场要求等进行深入而全面的分析。

　　“有大量的信息等着你去分析，”PRTM管理咨询公司的合伙人洛(Joe Lo)说道，“对那些刚起步的公司来说也许只是几天，而对大公司来说可能意味着几个星期。这取决于项目的大小。”

　　一旦发现了核心问题，就可以实施补救措施。“让一个项目获得新生这本身就是一个新的项目，”Project Corps.的总裁加迪(Shelley Gaddie)说道，“最重要的一步就是讲出事实，并尽快把事实摆到桌面上。”

　　原文经许可摘自Joseph Zucchero和Sanjiv Purba发表在Projects@Work杂志(http://www.projectsatwork.com)上的Symptoms & Sources一文(2005年3月24日)。Projects@Work登记2005年版权。魏力译。

　　Joseph Zucchero和Sanjiv Purba是Project Rescue: Avoiding a Project Management Disaster一书的作者。Zucchero是Casey Group Project Turnaround Practice的执行副总裁和总监。他在项目管理方面有着24年的经验。Purba是Purba Computer Solutions公司的首席执行官，并有着20多年的项目管理经验，曾管理过多个不同行业、规模和复杂程度的项目。