1.在对客户的访谈还没有完成之前就开始计划和行动

　　由于巨大的压力，项目团队面临着在一个详细的项目计划没有完成之前就开始项目活动。这将导致大量的困难和错误，不仅花费了时间和金钱，而且还使整个项目团队都感到沮丧。

　　原因分析在没有对客户和项目赞助商有一个详尽的访谈就开始计划和行动的原因，主要体现在以下三点。

　　第一，在美国文化中我们已经用持续计划替代了活动这个词，这就意味着为了表示我们已经开始执行项目，我们期望我们的所有发生的活动都是有记录的，即使当时还没有开始计划。除非项目经理和赞助人能够意识到计划之前必须完成对客户的详细访谈，并且制定精确的目标，否则我们将持续的进行着模糊的计划，而这样的结果就是导致大量的返工。

　　第二，没有人愿意花时间来了解商业目标和项目目标。这就意味着项目团队面临着还美元理解项目真正目标就不得不在项目执行中才开始计划。在项目执行过程中不断的计划这种方式决定不是一种能够充分利益人力和其它资源的高效方法。在大多数情况下，都会导致项目延期，预算超支和大量无法达成期望事情。

　　第三，项目经理和项目赞助人没有真正看到在项目开始前搞获取到所有客户需求信息的益处。一些项目经理经常受到喜欢把各种信息分解成相互孤立和分散的小块，而不是整合的一大块来看待的文化熏陶，这就意味着，大多数的项目都是仅仅为了实现短期或片面的项目目标而计划和执行，而理解到整个项目最终完成应该达到如何目标。

　　访谈和调研的必要性为了完整的理解整个项目的目标和愿景，访谈客户是最佳的方式。除非项目经理或赞助人在这个领域有充足的经验和知识，否则将导致项目的周期或成本都超过预算，而且导致大量的返工。在项目正式开始前，提前做充足的客户访谈和调研将确保我们真正理解项目的目标和客户预期。

　　2.依据少得可怜得项目信息进行至上而下的计划

　　项目计划的责任始终都是每次研讨会的热点讨论话题。这里似乎达成了一个共识，就是似乎个体就能够计划项目，设置最后期限，建立预算而不需要或很少需要前线人员的输入。很多人忘记了高层管理通常是哪些控制和了解资源的个体，正如他们控制和了解组织的伟大使命一样。

　　当我们由上而下的进行项目规划的时候，有三个方面需要主要考虑。而不管是哪方面的考虑，都需要依据个体和他们在分解项目工作的经验上。这里有一股强大的力量能够同时借助高层管理和项目成员，将项目机会，预算，周期等内容整合到一起。

　　至上而下的计划已经过时至上而下的计划是一种过时的管理风格，这种计划方式流行在19世纪50年代到80年代。自上而下的计划假设上层管理有最好的流程和思路使项目能够顺利进行。在许多情况下，当管理层在特定的政府机构项目中积累了大量的经验的时候，这往往是事实。但是，自上而下的规划可以伤害一个项目，而且在许多情况下注定会导致严重问题，因为员工都没有获取到足够多输入的机会。

　　至上而下的计划更加体现了彼得原理上个世纪70年代，管理学出现了彼得原理原理这个名词，称职的员工被提升到更高一级职位；其后，如果继续胜任则将进一步被提升，直至到达他所不能胜任的职位。由此导出的彼得推论是，“每一个职位最终都将被一个不能胜任其工作的职工所占据。在你所处的机构中，这一原则是否已经体现？你们的项目计划是否是在由不称职的项目经理在编写？他们做的项目计划是否根本不合项目中有项目经验的一线员工的口味？

　　并不是所有的项目经理都符合彼得原理而不称职，多数的项目经理仍然是努力的工作，他们为了履行项目任务，完成组织目标而做出正确的决定。当时上面讲的类似彼得原理的例子也并非罕见，项目经理因为自身所拥有的权力误用而伤害了整个项目组和组织。

　　至上而下的计划必须似乎团队高度认同项目和任务得到了项目组员的承诺是否对于项目成功至关重要？你是否期望你的项目成员自己拿注意和解决问题？如果两个答案都是的话，那么至上而下的计划可能会限制了承诺和来自团队的输入。当一个组织经历了大量的从上而下的计划的时候，对前线员工缺乏信任的文化就会建立。这样将导致一线的员工停止做任何有意义的决定和思考，他们仅仅是奉命执行高层的所有指令。这些方式延缓了项目，并且阻止了项目成员主动承担责任。

　　最后，项目经理和赞助人在项目计划阶段最重要的事情就是要设定项目参数指标，然后和项目组员一起拿出一个可行的项目周期和预期值。当需要协助高层管理和控制结果的时候，这将加强来自团队成员的输入和对项目的认同。

　　3.组建的团队没有适当的技能

　　你是否曾经在一个运转低效或项目成员没有适当技能的项目团队呆过？在这种团队中项目成员和客户都会感到沮丧，而且会损害到项目进程和大家对项目的信心。这些事情是如何发生的？如果项目团队没有完成项目工作的适当技能，我们需要如何做？所有这些问题都非常重要，必须加以审查，以使该项目能够以有效的方式进行。

　　有很多原因会导致项目团队没有完成项目所必须的技能。多数情况下，项目团队会提前拥有80%的技能，然后需要缩小遗留20%技能的差距。这种差距的弥补可以通过利用其它项目有经验的人员，外包，内部培训以提高技能等多种方式来解决。

　　项目团队技能不能满足首要原因是在项目需求发生已经变化的情况下，技能水平没有适应改变。一些项目需求和目标不断在变化，因此也需要项目成员的技能水平能够改变以适应这种解决新问题和进行革新的需求。

　　技能缺乏的另外一个原因是项目成员缺少适当和必要的项目培训。许多项目团队有执行项目的最基础的培训，但是在执行一段时间后大家都会懒惰下来，让这些技能进入到休眠期。这就意味这他们必须在小组会议上时刻提醒，是否需要通过培训提升自己的技能水平。

　　项目团队从来不把培训放在首位，他们试图使用他人已经积累的知识技能。一些做得好得项目团队就变成了规范和模板，但是这些规范和模板并不会告诉你如何采用适当得技能来运行项目，虽然使用了新模板但项目管理和执行仍然是原来的水平。

　　项目团队需要时刻的保持他们的技能水平强力和高效。这很容易做到，你只需要在每次项目例会后花一小段时间来进行培训。在多数场景下，培训仅仅需要15-30分钟，目的就是保持我们已经有的技能得到更新，同时把新的技能带到项目。

　　4.生产率低确没人承担责任

　　项目团队的运转将特别困难，特别是当你不是团队的直接上司而且没有被赋予足够的权力的时候。当项目团队没有正规的方式来评价项目成员已经完成的工作，或者不能将成员信息反馈给他们的部门领导的时候，情况将变得更加糟糕。导致的结果就是工作在项目中的成员工作效率低下，但他们却在部门领导那里得到了很好的绩效评价。

　　我们正在研究这种现象发生的原因，在你们的文化中改变这种责任感的方式，最后是如何搭建一个反馈会议机制以跟踪整个项目团队，并且能够使项目成员更加负有责任感。

　　责任感不强的原因组织的管理方式可能还是一种行政型或弱矩阵，项目成员都来自于不同的部门并向不同部门的领导汇报。当沟通破裂以及缺陷很好的关于项目成员绩效的反馈机制的时候，问题浮出水面。项目成员很清楚这种差距，他们往往利用这种差距和沟通的缺陷，转变为对他们自己有利的好处。

　　由于缺乏对于项目成员工作输出的恰当评价标准，项目成员基本不需要承担任何责任。在项目团队开发过程中，我们为了达到质量，进度，沟通和其它项目目标，必须要形成大家能够理解和认同的团队规则和工作评价方法。如果没有很好的质量评价方法，项目成员可能将对质量问题的检查延期到项目完成才进行，这个时候才采取的纠正行动将增加大量项目的周期和预算。

　　项目团队设定了不恰当的行为规范是第三个原因。项目成员在项目中工作能够得到的价值和成长并没有得到明确的声明。没有这种声明，许多团队都发现他们在没有积极的可以行驶的权力的情况下，却期望项目团队成员负起责任。既然没有标准，那项目成员都会用他们自己定义的对他们有利的标准。

　　5.不切合实际的进度确定

　　项目最后期限和进度往往是项目团队和高层领导或发起人间的一场战争。每个组织或结构都有他们自己的计算项目周期的政策。时间期限的确定可以是项目发起人，项目经理，也可以是通过整个项目团队成员的仔细估算。

　　当项目开始的时候，由于项目进行无法实际知道，由诸多情况将导致对于时间期限都是一种估计和猜测，这种情况特别是在项目刚开始的时候很普遍。实际上，随着项目的不断进行，很多不确定的因素逐渐确定，我们可以得到一个更加精确的项目期限。

　　项目团队或高层管理缩减项目时间的另外一个因素是要强迫项目成员更加努力的工作。当一个项目周期被估算出来以后，高层管理往往会再削减10- 30%的项目周期，以保证所有的应急进度储备都预留到项目之外（管理储备）。那是否意味着项目发起人就绝对不能改变项目周期和期限呢？当然不是。当一个项目团队的项目进度计划都是以一种极端且无任何储备的方式计算出来的，项目发起人有责任和项目团队讨论计划的可行性，甚至有可能主动缩减项目范围。

　　6.工作分解结构WBS

　　任何成功的项目都必须有一个详尽的工作分解结构WBS.通过工作分解结构将项目需要进行的工作分解成可以进行进度跟踪，成本控制和安排责任和人员的工作包或任务。许多项目的WBS分解往往肤浅和表面化，这种粗粒度的分解往往根本无法来跟踪进度，估算成本和安排任务。

　　WBS没有分解到足够详细的级别，是根本无法进行成本估算和进度跟踪的，或者说我们进行的估算和跟踪粒度太粗而根本无法达到项目目标的要求。通过一个项目工作分解结构会包含主任务->子任务->任务活动。或者将在WBS工作包下还会存在工作任务和任务活动的层次。分解的越细，我们越容易发现进度和成本上存在的差距。

　　每一个项目在计划过程中都会存在诸多假设。这些假设可能来源于以往历史项目的经验数据，假设就是你为了成功的完成项目，假定的一些安装预想应该发生的事情。假设如果不能实现，将直接影响到项目计划执行，而且往往假设也是我们项目面临的风险，对于这些风险我们必须制定相关的减轻措施和应急方案，这些内容都应该做为WBS的重要组成部分。