错误一：错误的需求调研阶段，导致很多项目永远无法结束!

在软件行业，在界面设计没有正式展现给客户之前，所有的工作都处于需求调研阶段。其实建筑行业已经给我们做好了先例：客户买房子之前是先要看看样板房和模型的，什么都看不到这房子你敢买么?除非你不是自己住!

而在我们所学的软件工程概念模型中，这是三个阶段：需求调研、需求分析、概要设计。在客户把他们想要管理的业务模块以及与之相关的业务数据，流程，表单交付你的时候，你千万不要把这个阶段定性为需要调研结束，写出《需要规格说明书》可以了。大量的实践证明，在概要设计阶段所衍生出来的需求工作量是之前的5~10倍，甚至更多，因为这要看设计人员的业务沟通能力和建模水平。

有实施经验比较丰富的项目管理人员总结说，在中国实施软件项目，必须以咨询方式展开：要推出自己的方案，而不能完全按照客户来提需求作项目。这是一种很好的解决思路，但无法解决所有实施项目的难题。这种解决方案的前提，要么项目实施者有成熟的业务模型，要么有成熟的产品(包含了成熟的业务模型)，否则是不可能做到的。但如果没有3~5年在同一行业，同一领域的实施经验和理论总结，没有哪家IT企业能达到这样的前提要求。

其实得出这样结论的深层原因，是因为国内多数企业管理思想不成熟，更谈不上完善的业务模型，所以客户的思维一定程度是发散的，还未形成系统。甚至还有些客户的领导，脑子中有很多新鲜的点子，他都有可能想在企业信息化的实施过程中加进来，这对把控项目范围和项目实施效果来说，都可能是灾难的开始。

所以，要做好实施项目，实施者必须有很好的业务建模能力，快速的给客户展示合理的软件原型——软件Demo。

请记住：软件实施项目，一定要给用户看到样板房——软件Demo，才算需求调研结束!

错误二：IT技术人员不需要掌握项目管理

有这种看法的人不在少数。根据观察，之所以形成这种看法，一是对项目的真正概念不清晰，二是对管理的概念“神话”了，把管理理解成了高深莫测，非一般人能做的事情。首先有必要普及一下项目的概念。

对“项目”有很多人下过定义，项目管理“圣经”PMBOK第三版(2004版)的定义是：“为创造某个独特的产品或服务，或完成某独特的任务所做的临时性努力”。围绕这句话PMBOK做了详细的解释和举例说明，很严谨，想了解的请学习PMBOK。因为都是翻译过来的定义，翻译得过于术语化很容易把人绕进去，在国内不排除已经拿到PMP认证证书的专业人士还搞不清楚项目究竟是什么。笔者在这里只想用汉语通俗的语言来说明什么是项目和项目管理。

项目，是在限定的时间要人完成的事。记住三个关键字即可把握：人、时、事。

项目管理是参与者用什么(知识、技能、工具、方法)来圆满地干好这件事。

明白了这些，你会明白从日常生活的吃喝拉撒到管理，处处都是项目，处处都需要项目管理，也能明白每个人都需要项目管理，也能理解学会了项目管理将会多么受益无穷，娴熟运用项目管理思维将无往不胜!

但需要提醒大家一点，现在的PMBOK是把传统制造行业、建筑行业、IT行业等多个行业领域的项目管理知识糅合到了一起，大而全，但针对性不够好，所以很多人觉得PMBOK理论化太强，学完了觉得很多东西没用。现在国际知名的另外一套项目管理认证，IPMP是按照工作岗位能力进行了分级，也没有针对行业进行分解。所以，无论拿到PMP或者IPMP，很多人都会有同样的困惑。据了解，PMI已经准备做这样的改进，这是一个很好的消息。

错误三：“忘记”项目目标项目管理培训

你看到这个题目什么感觉?很多人会觉得这样的错误怎么会发生?几乎没有人会认为自己犯这个错误!“忘记”项目目标有两种情形：一是从开始接手项目没弄清楚项目的目标是什么;二是虽然清楚项目的目标是什么，但却干着跟完成项目目标无关、甚至有害的事。

“时刻铭记项目目标”是项目管理很重要的一个思维，项目所有的活动都围绕这个展开。可是随着项目的逐步开展，尤其是复杂项目：人多、事多、周期长，很多项目经理会逐渐因为个人喜好而忘记了项目的大目标，比较典型的有：技术出身的项目经理会沉迷于技术细节，大量时间花在学习新技术或者一头闷在解决技术难题上;脾气火爆的项目经理会因为很多不值当的事情大发脾气，把团队搞得乌烟瘴气;小心眼、爱面子的项目经理会因为某个组员无意的顶撞而怀恨在心，从此总给其穿小鞋，搞得团队拉帮结派，毫不团结;还有更糟糕的，比如爱玩游戏的，爱喝小酒的等等。所有这些，无论原因是自身不成熟，还是管理经验、管理能力不足，结果都一样，那是项目出问题，甚至失败。

项目经理重要的一项任务是“跟踪与控制”，时刻把握项目方向，保证项目计划得以顺利执行，偏差控制在可控风险范围内。但项目总是有太多意外因素，尤其是周期长的项目，人们常用“夜长梦多”来形容风险会随时间的延长而增加，所以项目经理一定时刻都要保持头脑清醒，对项目无益的事情不做，对项目有风险的事情更不能做。

任何项目在开展过程中都会不断面对“机会”和“诱惑”，项目经理一定要能明确项目大目标，才能清晰地识别哪些是使项目成功的“机会”，哪些是会给项目带来风险的“诱惑”，才会少走弯路，早日成功。

“人是需要不断被提醒的”，这由人性决定。智慧的人能够不断的反省从而自我提醒，愚笨的人会被挫折、外界的“警示”不断提醒，这形成了“成功”与“失败”的差异。

错误四：计划不能变项目经理圈子

怎样才能保证项目成功?“计划，计划，再计划”，这是项目管理的佳实践!所以，做项目管理的一般都知道如何编制项目计划，并且很多人能熟练的使用 Project工具，知道“80小时”或者“40小时”法则、WBS和关键路径的概念。每个项目经理都会记住“计划一旦形成，严格按照计划去执行，而不受某个人、某件事的影响”这个原则，也明白“这样做不仅能够减少大量资源的浪费，产品的质量也能得到保障。”所以，很多项目经理排斥，甚至拒绝改变计划。坚持原则，这貌似没什么错，但真的这样么?

要弄清楚一件事是否有必要做，首先得弄清楚两个问题：一、这件事为什么要做?二、做了有什么好处?

那我们首先问一下编制计划的目的是什么?我们知道计划是项目管理的佳实践，计划是保证项目成功的一种手段和方法，做这件事只有一个目的，那是为了“保证项目成功”，但前提是，这份计划是“周密的、可行的”。严格执行一份周密可行的项目计划才能保证项目成功。很多项目经理记住了上面的“严格执行”原则，但忘记了这个大前提。

第二个问题，计划有什么好处?项目管理的计划方法，把项目活动、持续时间、所需资源有机地结合在一起，并且有严格的先后次序、里程碑和关键路径，可以清晰地提醒项目所有成员在什么时间，做什么事情，保证每个项目任务都得以执行;通过对计划的执行跟踪，项目经理可以清晰地了解项目进展情况和偏差情况，评估并及时有效的控制项目风险，从而保证项目的成功。

明白了这两点，我们再来看IT项目。对多数IT项目，尤其是软件实施项目，启动时都存在范围不够明晰，需求不确定的情况。只有到软件Demo产生，才可能需求清晰，范围确定，这些情况决定了IT项目计划需要根据项目的实际情况及时进行修正。如何压缩范围确定的时间，早日制定出周密可行的计划，是软件项目的一个重要课题。

制定一份周密可行的计划是项目经理能力的体现，尤其是WBS的制定，对复杂项目有很大难度。在谈2008奥运项目的管理体会时，项目专家曹蕾提到奥运会项目难的一点是WBS的制定(参见PMU网站对2008奥运项目的访谈)。要保证项目的成功，要保证项目的每个活动都能得以顺利执行。所以，在项目情况发生变化，在原有的计划基础上有需求变更时，要把新的任务补充到计划中，修正计划，确保WBS的完整，确保计划周密可行，之后的工作才是严格执行。

顺便提一句，有些项目经理会走另外一个极端：因为需求不确定，所以不制定项目计划。这同样是对计划的错误理解。即使计划不够周密，但它可以提醒我们项目的大目标是什么，保证项目团队所采取的行动不偏离大方向。任何一项大的项目，都可以拆分成很多小项目，WBS的“渐进明细”，也是项目必须完成的任务之一，所有任务的持续时间都是要估算的，即使不够准确，至少可以作为经验累积，为今后的准确估算做了准备。因此，项目的任何阶段都一定要有计划。