工期一拖再拖、要求不断改变、决策摇摆不定……这些项目“病症”你遇到过没？流程君今天推送的这篇文章，提供一些治病良方。
项目的最后期限总是一延再延，其原因也各式各样，其中包括计划不周、意外频发及业务复杂等。你也可以下一道死命令，要求项目必须赶在最后期限内完成，但是这无异于自欺欺人。
不能遵循项目的进度安排或者不断将项目延期，将会导致项目团队成员的行为变得非常糟糕。如果你的团队总是一而再再而三地贻误项目期限，你凭什么认为他们会改变这种行为？这些问题是贯穿于整个项目，还是仅局限于项目早期的几个阶段？谁应该为此负责？没有项目最终期限也意味着纪律涣散，缺乏约束。
项目经理可以将可交付成果分解开来，要求项目团队每两个星期就要完成一部分有价值且可衡量的成果。这样成果会逐渐越积越多。对于风险较高的项目来说，这个时间可以设定得更短一些。对可交付成果进行管理使得项目监管变得更加容易，同时也能在连贯的基础上进行风险管理。
即使大家都尽了最大的努力，还是有很多因素会导致项目要求经常发生变化。例如，提出新的想法；原计划考虑不周；业务的利益相关者改弦更张等。关键是要搞清楚，是要求发生变化了、被修改了，还是有所补充和完善，抑或是被其他要求所取代。
如果某人一直在改变主意，那你就要怀疑他是否真的知道自己要的是什么。这种症状是项目出现问题的征兆，预示着在项目预备阶段就有可能蕴藏着深层次的矛盾和问题。也许是对项目的预期不明朗，或者真正的决策者没有参与项目的决策，或者真正的利益相关者并没有被识别出来。
要求不断发生变化，背后的动机是为了让客户和用户满意。在项目启动之初，即应明确变更流程是如何操作的，以及何时需要应用这一流程。让相关方了解，未来的要求变更将要求项目团队再次发布项目信息。在要求发生改变之初，就应该让相关方了解它将对成本、利益和项目本身造成的影响。让用户或利益相关者在这些事实的基础上做出决策。
业务决策有始无终、摇摆不定是风雨欲来的征兆。许多项目，不论是二人小组还是价值五千万美金的大型项目，都有可能是建立在某个高层的业务愿景之上，而该愿景则是由若干尚未完成的“故事”大纲和业务章程组成的半成品。这样的愿景只能带着项目团队前进一小段，直到你发现由于项目缺乏清晰的目标而必须不断返工为止。
在项目生命周期之初，我们就应该确定以下几项关键业务决策：
●谁是企业的所有者，谁决定最终的项目验收条件？
●项目的最终产品应该是怎样的？
●缺陷率为多少是可以接受的？
●最终解决方案的绩效以及运作指标有哪些？
●业务准则有哪些？哪些是关键？
●在剩下的准则中，优先次序如何？哪些将会被用户所接受？
当某位项目经理第一次听到项目已经完成了90%，肯定会异常兴奋和开心。项目完成到这个程度是不断累积的成果，而且其成果应该是在定期的进度报告或进度会议上予以汇报的。然而进度报告可能会存在若干问题。该数据通常都是建立在对项目的不精确评估之上，或出自于项目经理、项目协调员的直觉。剩下10%有多复杂依然是个未知数，而且这个看起来较小的百分比还有可能让人掉以轻心。
项目倾向于滞留在这个阶段。当项目进度在相连的进度报告期间内停滞不前时，要好好想一想原因。这可能是由于新的项目要求所导致的，也可能是早期的进度汇报不真实的结果。通常，你所看到的下降比率可能并不会很低，因为项目团队出于主观愿望，会对进度报告进行一些修饰。所以问题可能远比报告上所显示的要严重得多。
所有项目，只要不是太过微不足道，都会时不时碰到这样或那样的阻碍和问题。虽然其中的许多困难也许很容易被克服，但还是会出现。如果这些困难没有上报，就说明项目团队要么是对项目探究得不够深入，要么就是没有就相关信息进行沟通。
项目经理也许需要仔细研究当前的项目进展和可交付的成果，以确保所提出的问题正是要旨所在。如果项目真的进展得非常顺利，那么在到达某个阶段性里程碑时则理应庆祝一番。
项目的关键可交付成果，有时也被称作阶段性目标，不仅仅指的是项目的最终成果，还包括用以确保项目顺利进展的阶段性可交付成果。没有阶段性或者最终可交付成果的目标预示着麻烦将至。如果要求提交阶段性或者最终可交付成果会造成混乱，那么就必须借助项目救助方案了。
当项目正处于下滑状态时，项目救助方案是一项旨在迅速改变其方向的阶段性的应对措施。这要求项目团队必须为实现某些利益而做出相应的妥协。同时救助方案还须为项目设定发展的步调及氛围，从而使得团队成员能够兴奋起来并做到人尽其才。
在推进项目的过程中，人际关系问题不可避免会发生。然而，对人际关系处理不当，会导致难以挽留员工、员工扬言离职，造成员工间的不愉快、士气低下，出现恃强凌弱、自保反抗的局面，甚至引发无谓的口水战，以及各个层面上的政治纷争。
人际关系问题的出现警示我们应该探寻更为深层次的原因。由此而引发的其他问题将会浮出水面，包括质量不过关及贻误最终期限等。
质量问题在项目的正常发展阶段也许并不明显，因为现在还尚未交付或尚未实现正常运作的成果可在日后另行交付。然而，质量问题的数量也不能超过一定的界限。质量问题诚然是困难的一种，但是你也可以在出现质量问题时决定是按下求救的按钮，还是认为这尚在可接受的范围之内而予以承受。
我们应在项目的各个阶段通过回答下列问题，对质量期望值及质量保证流程进行界定：
▲何种类型的错误是可以接受的？
▲错误孰轻孰重，如何解决？
▲应进行怎样的测试，从而发现错误？
你肯定曾经多次听到过这种言论：“别把时间浪费在什么进度报告上了，实实在在地干活才是最重要的。”这种言论背后的观点都是非常高尚的，也可以被运用到任何项目管理工具或程序上。然而，在宣布进度报告完全无用武之地之前，我们还须从以下几个方面多加考虑。首先，如果出了问题，必须依靠这些报告工具来解决。其次，如果没有这些工具，当你知道有问题出现的时候已经悔之晚矣了。
由于缺乏项目报告工具，在那些没有向项目团队进行过汇报或沟通的领域内，铁定会出现问题。如能较早发现这些问题，也许能够将其克服。但是，缺乏报告工具通常意味着这些征兆将被忽视，直到已经太迟。
（有个人观点，请在页面底部留言评论）
