项目经理原则

项目经理原则

http://blog.csdn.net/liaomin416100569/article/details/5583358

项目经理原则

第一章沟通

员工与管理者互相沟通

企业忽视沟通管理就会造就无所谓的企业文化

第二章 技术出身项目经理易犯的一个错误

问题剖析

怎么解决

第三章 项目经理如何组建项目团队

第四章 项目经理开门七件事

一、 确定项目目标

二、 明确职责权限

三、 熟悉工作流程

四、 掌握技术要点

五、 了解人力状况

六、 把握内外资源

七、 制定项目计划

第五章 错误的思维导向，导致IT项目管理问题多多

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

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

错误三：“忘记”项目目标

错误四：计划不能变

错误五：项目一定要盈利

错误六：记住了“科学”，忘记了“有效”

 

第一章沟通

员工与管理者互相沟通

企业内部良好的沟通文化可以使所有员工真实地感受到沟通的快乐和绩效，加强企业内部的沟通管理，既可以使管理层工作更加轻松，也可以使普通员工大幅度提高工作绩效

优秀管理者必备技能之一就是高效沟通技巧一方面管理者要善于向更上一级沟通，另一方面管理者还必须重视与部属沟通

对于管理者说，“挑毛病”尽管在人力资源管理中有着独特的作用，但是必须讲求方式方法，切不可走极端，“鸡蛋里挑骨头”，无事找事就会适得其反，挑毛病必须实事求是

在责备的过程中要告知员工改进的方法及奋斗的目标，在“鞭打快牛”的过程中又不致挫伤人才开拓进取的锐气。从这个故事中，管理者首先要学到的就是身为主管有权利也有义务主动和部属沟通，而不能只是高高在上简单布置任务!

 

企业忽视沟通管理就会造就无所谓的企业文化

任何企业中都有可能存在无所谓文化，员工对什么都无所谓，既不找领导，也不去消除心中的愤恨;管理者也对什么都无所谓，不去主动地发现问题和解决问题，因此大家共同造就了企业内部的“无所谓文化”的企业文化，在无所谓文化中，员工更注重行动而不是结果，管理者更注重布置任务而不是发现解决问题

第二章 技术出身项目经理易犯的一个错误

从技术出身的项目经理，很容易犯这样一个错误：把自以为简单的问题分配任务给成员时，会夹带技术细节并表露出问题的简单性。

问题剖析

　　譬如X项目经理接到客户的新需求，要求更改页面上的某个字符串。于是立刻把成员A叫过来，“这个需求只要把对应页面的字符串改一下就OK了，5分钟搞定，你赶快去改一下吧”。姑且不论这个问题是否真的简单，首先的问题是，X混淆了项目经理和开发人员的界线。具体实现细节是开发人员的事，项目经理不需要关心，即使开发人员不懂如何实现，那也是技术经理的事。此外，“5分钟搞定”这种话，对开发人员来说往往是一种伤害。最常见的一种结果是，成员A下去后发现问题没这么简单，不光要修改页面文件中的字符串，还涉及到数据库中某个字段的修改，更麻烦的是，修改后单元测试一片红。5分钟的问题，最后花了一天才搞定。

怎么解决　　

项目经理一般不参与具体编码工作，凭借以往的开发经验得到当前项目中“某个问题很简单”的结论往往经不住推敲。因此，项目经理最好绝口不提技术细节，分配任务就OK，譬如“目前接到一个新需求，客户要求更改某个页面上的某个字符串，你下去分析解决一下。问题比较急，相信你能尽快完成。”首先把需求描叙清楚，然后说明一下紧急性，剩下的放心大胆的交给开发成员就行。

套用一句古话结尾：项目经理当有所为，有所不为。

 

 

 

第三章 项目经理如何组建项目团队

团 队组建处于团队的形成阶段，在这个阶段中，团队成员一般而言会有一个积极的心态，急于施展身手，开展工作。另一方面，团队成员对未来的工作应如何进展还不 明确，团队规范尚未建立，团队成员不了解自己的职责及其他成员的角色，成员的相互关系还很模糊，成员心中充满疑问，如，我们的目的是什么，其他成员是谁， 他们怎么样，我能和他们合得来吗……他们会怀疑自己能否被其他成员承认，担心自己的角色是否与自己的发展和职业兴趣一致。成员往往会很激动，充满希望，也 会因为对目标的未知而表现出怀疑、焦虑和犹豫。

　　在这个阶段，项目经理要做好以下事情：

　　◇自我调整，给自己一个全新的定位;

　　◇把自己的信念和对团队文化的设想传达给成员，确立自己的管理风格;

　　◇抓住人心：与成员主动沟通，了解成员对团队、自身和未来工作的期望，消除他们的疑虑;

　　◇组织一些活动增进成员间的了解;

　　◇向团队说明项目目标，并设想成功的美好前景和成功所带来的益处，要求成员准备参与团队阶段计划的制定;

　　◇说明选择团队成员的原则，以及每个人为完成目标所应承担的角色;

　　◇初步进行组织构建工作，包括确立团队工作的初始操作规程，规范诸如沟通渠道、审批和文件记录工作等，并随着项目进程不断改进这些规范，将其制度化;

　　◇组织团队着手一些起始工作。

　　有的项目经理上任后只顾着和一堆资料、文件打交道，或是紧盯着眼前的一些工作，没有明显的工作作风和风格，难以控制大局。项目经理是团队的领导者和管理者，项目经理的工作重心是计划、组织、协调和控制。对这些工作，项目经理需要通盘考虑，抓住人心;塑造管理风格，培养团队个性。总之，项目经理需要Smartwork(聪明地工作)，而不仅仅是Hardwork(努力地工作)。

　　有些新上任的项目经理忽视自己新的角色和定位，往往按原来的经验和角色行事，如显示权威，对团队成员发号施令，这会不利于团队的协作和成员积极性的发挥。所以，项目经理一定要了解团队特点，选择恰当的领导风格和管理方式。

第四章 项目经理开门七件事

一、 确定项目目标

　　项目怎么可能没有目标呢?仔细想一下吧，你的项目目标明确吗?会不会有好几个目标?是否大家都有一致的认同?

　　项目应该只有一个主要的目标，过多的目标会分散注意力。超过两个的主要目标，将会使项目组在以后的工作中难以分清工作重点，并且在某些目标不能实现时产生失落感。

　 　如果有些目标是大家认为可以在项目过程中顺便产生的，那么就让它自然产生好了，不要一开始把它定为项目的目标。有时公司可能需要在项目中建立规范或其他 尝试性的工作 ——最好把这些工作作为独立的项目——如果一定要在项目中进行，那么请注意计划出这部分工作需要的投入。将目标尽可能的细分为明细的任务(子目标)，这与多个目标不同，每个任务都是围绕一个中心服从统一的原则的，不会互相抵触。

　　更重要的一点是，大家眼中的目标是否一致。在项目开始前一定要与公司领导和客户(如果与客户有关)就该问题达成绝对一致的看法，然后将这个信息传达到所有相关的人员。如何描述不是主要问题，可以直接交流、提交专门的报告，当然最好在正式的计划中作出阐述。

二、 明确职责权限

　　是否有岗位职责书、项目任命书?有，那最好，仔细研读一下，明确管理的职责和权限。

　　有些事是你能做的，有些是你愿做的，这里要明确哪些是你负责做的——具体的事情可能需要其他人协助或者授权给别人，但是责任还是你的。

　　作为管理者一定要明确你有哪些权利，而且要清楚如何利用职权(可不是滥用职权)，这样才能清楚可以采取的策略。权利很大，可以更威严，但是要公证;权利很小，试试多一些的感情投资。

　　明确的文档也好，直接的交流也好，总之最好在项目开始前确定该做和能做的事。

三、 熟悉工作流程

　　通常公司会有对项目管理的规范，如ISO9000或CMM或其他即定的规范，应该使自己的项目过程符合规定。

　　项目开始前就应该弄清楚你的一些习惯是否与公司规范有冲突。如果确实有些好的操作是规范以外的，可以在项目中将它们结合起来，或者提出来并修改规范，但不能作为违反规范的理由。

　　有时规范可以在许可的情况下进行裁减或调整，但前题也是你要先清楚规范是什么。你所理解的流程会在项目中一般规范中都规定了需要产生的文档和其他提交项，建议在项目开始的时候就将各环节需要的文档建立好(当然只有名字和目录)，这样在需要用时就不用到处找，也不会遗漏。

四、 掌握技术要点

　　如果项目是在需求明确后才确定实现的技术，那么现在可以不考虑这个问题。不过大多数情况在项目开始时就已决定使用某种技术了。

　　通常项目经理可以不需要非常娴熟的技术能力，因为可以在项目组或公司层面配置技术专家，但是项目经理还是应该对需要使用的技术有一定的理解——这样可以理解其他专家或资深技术人员所描述的问题和解决方案，然后作出决策。

　　项目经理可 以根据实际情况制定一个自己的学习计划，不需要公布，但是最好有一个明确的计划，并按照计划执行，否则日后忙于各种事务时就会总觉得没时间补课——这很正 常，因为开始就没有给这件事安排时间。总是用可能剩余的零星时间来做的事是很难有成效的，所以要对应该做的事有个计划。

五、 了解人力状况

　　人员其实也是一种可用资源，之所以与其他资源分开考虑，是觉得这是最重要的要素。一般项目中人员的使用是分阶段的，但是需要什么样的人应该是开始就确定的，除非使用什么技术还没确定，那人员确定也必定是阶段性的。

　　确定项目需要的人员技能，了解所有可用的人员信息，根据需求选择合适的人员组建项目组——这是理想状况，几乎没见过。不过这作为一个原则还是适用的。

　　首先对项目组进行角色组织，应综合考虑公司的规定、目前的技术能力、项目的时间要求等因数设计项目组的角色，确定各角色的职责和能力要求。实际上这也是凭经验而定，没有什么公式可用。

　　然后从人力资源部，各项目组了解可用人员的情况，如果人员是既定的，也可以在了解已定人员的信息后，多了解一些其他人员，毕竟你可能还有其他的选择。

　　最后就是看人员是否能适用于项目组，这颇有些“按图索骥”的味道，不过不尽然，很多时候，不可能直接找到所有合适的人，所以现在不“完全合适”的人，不一定是不可用的。如果有差距那么相应的培训计划，招聘计划就该列入考虑了。

　　当然，实际上远没有这么简单，人不同于零件——按照设计要求组装之后就可以用了，要使一个团队合理运做，发挥效益，是另外专门的话题了。

得以贯彻，所以一开始就要让它是合乎要求的。

六、 把握内外资源

　　尽可能在项目早期明确需要的资源，除了刚才提到的人力，还有资金，设备等等。仅仅清楚资源需求是不够的，要明确这些资源的提供者。不可能指望提交一份“资源需求清单”，就可以等着你要的资源在计划的时候出现，项目经理必须清楚通过什么途径可以获得这些资源。

　　特别注意，一般总是认为客户总是对项目提出要求的人，但是客户也往往是能够提供各种资源的人，比如测试环境，特殊设备等。

七、 制定项目计划

　　以上工作都完成后，可以开始完成项目计划了，实际项目计划就是这些信息的固化表示。之所以让每项工作都做为独立的任务去完成，而不包括在制定计划这一个工作中，是希望避免出现还没有完全了解状况就急于完成计划的状况。

　　就是因为计划很重要，所以更不要急于写出项目计划。

　　制定项目计划的 第一个重要原则是实际：计划要合理和可行，写出一个大家都感觉良好的计划，不一定是好事，应该充分考虑目前的运做能力，项目风险等因素后制定出可操作的计 划。计划第二个原则是分步明细：很难在一开始就将所有的阶段计划细化，可以先定出阶段性的计划和细化计划的时机，然后只细化最近步骤的内容。计划第三个原 则是描述清晰，没有歧异。

　　项目计划最好不是一个人定出(当然可以由一个人执笔)，否则一定要与主要的相关人员充分交流讨论后得出。最后计划一定要通过认真的评审，得到所有相关部门、人员的认可。

 

 

第五章 错误的思维导向，导致IT项目管理问题多多

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

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

　　而在我们所学的软件工程概念模型中，这是三个阶段：需求调研、需求分析、概要设计。在客户把他们想要管理的业务模块以及与之相关的业务数据，流程，表单交付你的时候，你千万不要把这个阶段定性为需要调研结束，写出《需要规格说明书》就可以了。大量的实践证明，在概要设计阶段所衍生出来的需求工作量是之前的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的“渐进明细”，也是项目必须完成的任务之一，所有任务的持续时间都是要估算的，即使不够准确，至少可以作为经验累积，为今后的准确估算做了准备。因此，项目的任何阶段都一定要有计划。

错误五：项目一定要盈利

　　“项目一定要盈利”，这句话被无数IT项目经理奉为真理，也就注定了要创造很多悲剧!为了达到这个目的，很多IT项目经理甚至都在悉心研究厚黑学，学习用什么办法把小弟搞得热情高涨，比“民工”累，从而用最低的成本创造最大的利润。

　　项目管理作为“战术”层次的管理手 段，一定要服务于“战略”层次的大方向。商场如战场，有胜利就会有失败。为了战略胜利，很多战役要“诱敌深入”，必须打败仗。败仗不要紧，关键要弄清楚败 到什么层次，损失到何种地步，明确本次战役的真实目标，再去打这场战役，就会做到驾轻就熟，从而不至于到最后形成“不仅损兵折将，还未能诱敌深入”的局 面。项目管理者联盟，项目管理问题。

　　开拓市场、占领市场、站稳市场、挖掘市场，这是每个公司发展必不可少的步骤。很多项目，对公司来说都是为了占领市场，甚至“虎口夺食”。这样的项目，公司从战略层面首先要求的绝对不是盈利，而是如何能把市场占领，继而站稳，项目经理必须明白这个战略意图。

　　“平衡”是项目管理最为重要的一个思想，从过去的做好“质量、时间、成本”项目三要素的平衡，到现在“满足相关干系人的需求”，所有的最佳实践和理论研究成果，都绝不会提倡走极端，“杀机取卵”!利润只是项目的一个目标，并且一定要明白有“短期利润”和“长期利润”之分，过分单一追求利润的项目注定要失败，过分追求利润的公司也不会长久。

　　该花的钱不能省，不该花的钱一分也不要花，项目经理把 成本控制在合理的“预算”范围内，就是成本控制的成功。万万不可为了把一个注定要“赔钱”的项目做得盈利而想尽办法、绞尽脑汁压缩成本，从而让组员加班加 点，玩命干活，到最后，项目干完了，人也走光了，还极有可能因为赶工导致项目质量不合格，客户不满意，那就真的“赔了夫人又折兵”!

　　项目组要能保持激情高效，不能懒散拖沓，项目经理一定要把握好这个度，绝不能走极端。平衡是一门艺术，也是展示项目经理能力水平的一个重要标尺! 

错误六：记住了“科学”，忘记了“有效”

　　学以致用，就怕乱用。无论是产品、技术还是管理方法，都存在为了更“先进”、更“科学”而罔顾现实，盲目乱用的现象，结果“先进”和“科学”的技术、工具不仅未提高生产效率，却成了累赘，这样的情况到处都是，在IT项目中也为数不少。

　　国内大量失败的ERP项目就是这类错误的典型。有人把ERP项目归结为“一把手”工程，意思是只有领导重视并推动才能成功。领导支持是项目成功很重要的一个条件，但绝不是有领导支持就一定能够成功。有些项目就是领导决策失误盲目上的，从开始就注定项目要失败。一个信息化项目的实施，对很多企业来说就是一场大的改革，对所有员工从思维、技能到工作习惯等多方面都需要进行调整。如果企业的员工素质不能跟上，纵然有各种各样的培训，但不顾员工基础和“学习曲线”，用户不能真正掌握全新的系统，结果就只能增加用户负担，而产生不了期望的效果。

　　很多IT项目经理在学习了一些新的技术后，总想立刻在项目中实践，而不去仔细分析这些技术在这个项目中是否需要，是否适合。IT技术日新月异，不断有新的理论被提出来，被翻译引进到国内。有些项目经理在一知半解，对这些技术还不是很熟悉的情况下，就敢向人吹嘘他所“掌握”技术的“科学性”、“先进性”，进而强制要求在项目中实践。这可能是甲方的项目经理，也可能是乙方的项目经理。因为技术选择错误导致项目失败的例子在国内过去有，现在也还有!绝对不可准备不足，大范围引入全新的技术，待到项目时间过去一半了，才发现选择的技术不适用，那时候一切都晚了。掌握任何新东西都有“学习曲线”，项目的时间限制是项目经理必须时刻牢记的要素，把握不好就会给项目带来极大风险。

　　涉及到具体的IT项目管理，PMBOK的知识体系可谓博大，还有一些其他新的项目管理工具，不能说不先进，但是哪些知识、工具、方法适合本项目，需要项目经理根据实情，认真分析后进行筛选使用。“科学”、“先进”、“好用”等等修饰头衔这些都不是要选择的首要理由，“需要”、“适用”和“有效”才是首要考虑的事情。很多IT项目经理因为年轻，“初生牛犊不怕虎”，胆量大，勇气足，敢于在实践中引入新的工具、方法。敢于尝试不是坏事，但试验的风险一定要控制好。对于项目经理来说，所有的决策都要围绕项目目标进行。项目经理的首要任务是保证项目成功，如果同时能引入新的技术、工具，增加组员的知识技能，提升项目组工作效率，提高产品的质量和可靠性，绝对是“锦上添花”，但绝对不能为了“锦上添花”而导致项目失控甚至失败，“捡了芝麻，丢了西瓜”!