项目管理杂谈

项目管理杂谈

文章有不妥之处，请指教。

(1)项目管理说起来很复杂，最关键的一点是控制。当然，要实现有效的控制，你需要事先明确很多东西。项目，就是在有限的时间内，有限的资源下，完毕一个明确的目的的过程。这些，是作为一个项目经理必须要了解的，也是每一个团队成员应当要了解的。同时，沟通也是非常重要的，没有对项目各个进程的明了，要做到有效的控制，就是天方夜谭。

控制的依据，就是所作的项目计划，计划应当是按照目的安排的，并根据情况及时调整，项目经理的职责就是协调手里的资源，使项目进度按照计划完毕（说说容易做起来难），并在这一过程中，实现资源的最优化配置，使得项目可以在有限的时间内，有限的资源下完毕。

从事项目管理工作，其中酸甜苦辣滋味，一言难尽。乐旨在这里跟大家交流一下这些年的体会，我想以杂谈的方式，一次一个题目，也希望大家多鼓励交流，我也有点动力。我不想讲太多理论，毕竟非我所长，并且项目管理是一门实践性非常强的学科，这也是为什么认证考试都规定申请者要有几千小时的经验的因素。可以这样说，即使有人通过了认证考试，而没有真正做过项目，他决不会是一个合格的项目经理。

第一次，就从项目的定义说起。所谓项目，就是在有限的时间，有限的资源内，完毕一个或一些特定目的的过程。（不是从书上抄的，也许会略有差异，差不多吧）。

先说目的，明确的目的是一个项目可以成功实行的前提，但在现实中目的的拟定并不容易。在不同类型的项目中，目的的拟定各有不同。在工程项目里，相对容易些，有协议作为依据，什麽时候完毕，完毕什麽样算合格在协议里都有明拟定义，（不要跟我说没有，那就是另一回事了），这些都是硬性的，基本上不能改，那末项目的目的就很明确了。

但是在研发的项目中，就不容易了，一方面，客户经常并不知道他们到底要什麽（记得上学时讲软件工程的老师讲过一个笑话就是这样的），所以结果就是在开发过程中他们不断在变主意，这样就意味着项目的目的一直无法拟定，结果可想而知。所以说，在进行软件研发的项目中，目的的明确是非常重要的，重要到经常近一半的时间是在做可行性研究，拟定目的，而这一过程绝对必要。错误的目的会给项目带来极大伤害，也许导致项目半途而废，或是结束遥遥无期，结果经常是不断减少对目的的规定，以结束这一痛苦过程。相信大家会有这方面的体会。

再说时间，一个项目必然要有时间规定，对于工程项目特别如此，并且经常是个硬指标，没有时间限制的无限期项目是不可想象的，不能称之为项目。

最后说到资源，资源涉及很多方面，资金，人力，材料，设备，场地等等都是资源，而资源也是有限的，如何运用有限的资源完毕项目，是项目经理存在的一个重要因素。项目经理应当在项目开始前做好预算，明确需要多少资源，所谓巧妇难为无米之炊，假如这一点无法由项目经理控制，这个项目经理还是别当的好，日子太伤心了。

时间与资源之间是有互动关系的，在目的拟定后，通常情况下，要想时间更短，在单位时间内资源需要的更多，但也不是无限的，需要具体情况具体分析。举例来说，有些特定的项目（经常是政治任务），时间是最重要的，那就不能再考虑花多少钱，要多少人，必须完毕，才干在某天完毕，为。。。献礼。另一例子，几个人攒了个工作室要开发游戏，人就这麽几个，机器就这麽几台，只能以时间为代价了，要是目的再不明确，时间就更长了，这样的例子比比皆是，不再多说。

关于目的补充一句，目的是否认义合适有一个简朴的衡量标准，简称SMART，含义如下，

S-specific

M-measurable

A-accepted

R-realistic

T-timebased

(2)通常来说，项目可以分为四个阶段，准备立项，可行性研究，执行，总结。

这里有个概念，称为TOLLGATE，我一直不知道该怎没翻译这个词，原意是关口，收费站等。

每一个阶段结束时都有一个TOLLGATE，目的是进行分析总结，是否将项目进行下去，在这一过程中项目组的职责是提供相关的信息和数据，以及分析，预测等，供决策参考，而是否进行下去的决定权在于STEERINGGROUP，大约是指项目的资助者及监督者，这个概念以后还会提到。准备立项，没什么好说的，就是有个意向，准备要搞个项目，关于目的，时间，预算有个大约的想法。

可行性研究，在这一阶段要做的事很多，如拟定项目目的，作出预算，时间表，所需资源预测，风险分析，应对手段等等。。。前文曾经提及，这一阶段非常重要，毫不夸张的说，这时候把工作做好，项目就成功了一半。

在研发的项目中，一般不会省略这一步，虽然有时做的很不够。但在工程项目里，特别是扩容的工程中，经常会忽略其中某些必要的环节。我第一次接手一个特大型项目时，有过这样的教训。当时我们准备给一个省的客户做系统扩容，涉及协议金额大约有一亿多美元，习惯上在协议谈判时（从项目管理角度来说，可以视为可行性研究的重要部分）项目经理介入不多，特别是关于设备采购数量，协议签了，第一次与客户研究技术实行方案时，问题发生了。

问题可以这样描述，客户原有1套系统在用，扩容到2套，为了节省投资，里面涉及到很多系统设备的利旧，由于没有经验，设备定购时考虑数量只是单纯的用扩容后的规模减去现有数量，但事实上在施工过程中必然存在这样一种状态，新的系统建成后，才干把在用系统的用户割接到新系统上，旧系统的一部分才干拆下来。而按照协议里的设备采购情况，只能把旧系统停下来，把设备拆下，再和定购的新设备一起组成新系统，由于客户所处的行业，系统运营决不能停，记得当时我的冷汗一下子就下来了，这个问题假如不能解决，我们就得向用户免费提供一套系统供周转，那对公司将导致极大损失。后来我们与客户一起苦干了两星期，终于拿出了一份可行的技术方案，代价是工作量是原计划的3倍，而时间比原计划晚了4周，我运气不错，总是解决了，这很有也许是个解不开的死结的，不是每一次都能这样幸运的。

在又一次的扩容前，在我的坚持下，技术谈判时我们就开始介入，在协议签署之前，我与公司的技术人员以就所有也许的发生的问题拟定了解决方案，虽然新的扩容规模大了几倍，比前期复杂了很多，实行时却很顺利。

执行，简朴的说就是按照在前一阶段制定的计划控制监督项目进展，直至完毕。

总结，项目执行完后，对项目的回顾和总结。这一阶段很重要，但容易让人忽略，很多人都认为干都干完了，也还不错，有什麽必要写这些长篇大论。即使在我们这样的国际化大公司，同样如此，我每次写的FINALREPORT就基本上没人看，更别说提意见了。事实上，对项目各方面的回顾，如预算，时间表，人力资源，风险分析等，对下次的项目执行有非常重要的意义。记得刚进公司时做工程，办公室里贴着这样一句话，"Remeber,youhavenotfinishedtheworkuntilyoufinishthepaperwork".

(3)谢谢SPRING的鼓励，就你提出的问题，这涉及到项目的计划，我是准备作为一个专题以后要讲到的，这里我简朴说几句。一方面澄清一个观点，从理论上来说，项目经理和项目所涉及的专业完全没有关系，即使对相关专业一窍不通，仍可以进行项目管理。从我的经验来说，这个说法不错，但在实际工作中，具有一定的专业背景是非常有帮助的，可以节省很多时间，避免一些不必要的风险。记得我的一个师傅（我有过四个师傅，一个马来西亚华人，一个挪威人，一个芬兰人，一个英国人，跟他们共事很故意思，以后再讲）曾经说过，你不知道并不可怕，可怕的是你不知道你不知道！而对所涉及专业的不了解，就意味着你不知道你不知道，就意味着你无从知道有也许存在的危险。那末怎没才干知道哪？只有实践，在第一次的实践中要多问，弯路是肯定要走的，时间也会多花，这个代价是值得的。同时，对项目经理的规定也不会太高，能满足你知道你不知道就足够了，毕竟很多专业问题应当由技术人员去解决，而不是项目经理，你所要做的就是当问题出现时，知道属于哪一类的问题，该由谁来负责，就足够了。否则的话，以做个游戏为例，就规定一个人既要做策划，又要做引擎，还要做美工，音乐，也许有这样的天才，我是没怎么见过。至于另一个问题，仍是由目的开始，先明确要做的产品，性能，外观，成本等等，再把要做的工作逐步细化，并对每一项进行时间和资源的量化，即使对没做过的也要如此，不准确可以及时调整，但从一开始就要有个预计的数字，而这一部分，理所当然在风险分析中应当占据很大比重。只能简朴说到这里，可以给我发MAIL，提供更具体的情况，希望能给你更多帮助。此外提一句，我发现这里很多求助的人的问题太抽象，拿这个做题目可以写本书了，很难在这里回答，所以，越具体越好。

言归正传，下面说说项目的组织。说到组织结构，可以分为两种，一种称为LINEORGANIZATION，一种称为PROJECTORGANIZATION，它们有着本质的区别。LINEORGANIZATION通常是按职能划分的，较稳定，长期存在，我们常称其为RESOURCEPOOL，为项目提供所需人力资源；而PROJECTORGANIZATION是按项目划分的，因项目而生，随项目结束而解散，人员来自不同的LINEORGANIZATION，为同一个项目而聚会到一起，而项目经理，就是这个临时团队的领导者。

在一个项目组织里，可以分为三个层次，第一层，是项目的资助者，我们称其为STEERINGGROUP，职责是负责批准项目的立项，提供项目所需资金，在每一个TOLLGATE时审查项目经理的报告，决定项目是否继续，同时也是定期的项目进度报告的接受者。

第二层，是项目管理层，涉及项目经理，助理项目经理，也许的话，尚有对各个部门的协调人，这个集体由项目经理领导，负责整个项目的协调，控制，进度，报告，同时也是对客户（假如有的话）的重要接口。

第三层，是由各部门参与项目的人员构成的项目组成员，由各职能部门的不同，负责项目中的不同部分，做具体工作。他们应当按项目计划规定完毕自己的任务，并有义务对项目经理定期报告所负责领域的进展情况，提醒项目经理也许存在的问题。

值得一提的是，这个结构只是个大约的轮廓，由于项目的不同，会有很多变化，但从逻辑上来说，都应有这三个层次的存在。对于很小的项目，有也许第一，第二层合二为一，对于大型项目，会有更多的层次存在，比如说，对于每一个参与项目的职能部门，他们的任务也是一个项目，那末其协调人就是一个子项目的项目经理，依此类推。在这种情况下，结构一定要在事先明确，以避免在进行中的职责，权利不明，沟通渠道不畅。

(4)项目管理是一项重要与人打交道的工作，与人打交道是最难的，这样领导能力就成为项目经理的必须。

LEADERSHIP，我将其称为领导艺术，是一门专门的学问，我没有时间，也没有能力在这里专门讲述，希望每一个项目经理都有机会能参与这方面的培训，至少要找本书自己读读，在这里我只提跟项目管理直接相关的几个方面，以理解在项目管理中领导艺术的重要性。

先说说团队合作，一个项目组织就是一个团队，而项目经理就是这个临时团队的领导者。是团队就必然要经历团队的几个过程，初创期，磨合期，生产期，结束期。一个项目成立，成员来自不同的部门，彼此或结识或不结识，对于大多数人来说是不熟悉的，接着开始干活，慢慢的彼此熟悉，其间会有冲突，争论，甚至争夺领导权，自然而然某些人在团队里成为大家信赖的人，建立起领导权威，大家逐渐熟悉了对方的工作方式，建立了互相信任，工作效率明显提高，然后，大家已成为配合默契的伙伴，一切都在井然有序的高速运转，效率达成最高，终于有一天，项目结束了，团队解散，大家回到各自部门。

好的项目经理可以使前两个阶段尽量缩短，使整个团队迅速进入第三个阶段，而做到这一点并不容易。一个经验丰富的项目经理在团队成立之初，通过项目目的的拟定，项目的范围，各个相关部门的责任等讨论及定案的过程中，就可以树立自己的威信，建立起团队成员对自己的信任。

再说一下对自己下属的领导，在这里举两个例子。在一个省内扩容项目中，我有3个助理，同时尚有3个工程项目经理作为工程公司的接口，工作范围大约是按照地区划分的，我对我的助理们的工作通常但是问，除了定期的报告，他们积极来找我请示外，一般不介入他们的具体工作。因素有几个，一是在我到任之前，他们都已经至少做过一年的助理了；二是考虑到我将来总要离开，他们要作为项目经理而独立工作，我故意不作具体的介入；三是他们的年龄都比我大，总要给人留几分面子。终于有一次出了问题，一个工程师到了现场，发现有些设备未到，打了报告给工程项目经理，工程项目经理报告给了我的负责该地区的助理，他告诉了我，这一地区的后续工作因此推迟。而事实上，在工程师发现缺货两天后，他发现这是一个由于自己经验局限性产生的错误，他没有撤回自己的报告，只是打了个电话给工程项目经理，工程项目经理转头就把这个事情给忘了，所以在我的记录里，这里一直不能进行后续工作直到我们发现了这个错误，结果是工期推迟了一个月。作为项目的总负责人，我当然要为此负责任，而我的错误不在于没发现这个问题，而在于对于我的这个助理用错了领导方式。

对于下属的领导方式可以分为四种，第一种称为教练，对于新手来说，你需要告诉他每一件事该怎没做，有时还要自己做示范；第二种称为后座驾驶，意即坐在司机后面告诉他怎麽开（我最讨厌的方式）；第三种，对不起，忘了，大约是只用简朴指导；第四种是只交代任务即可。我自己习惯的是最后一种，对助理们大约是第三种，而事实上因人而异，对其中两个可以，对这一个，不行。现在想想，我当时才到那里两个月，还谈不上对他们有多了解，就敢如此，只有一个给我惹祸，运气还是不错的。尚有一次，是项目组里的货运协调，那是一个年轻的女孩，性格活泼，讨人喜欢，和我平时关系不错。有一次，她犯了一个明显的错误，她把报告交给我时让我发现了，当着别人的面我指了出来，还开了几句玩笑，当时她脸就红了，下班时约我去吃饭，然后很严厉的对我说，下次能不能私下告诉她，我当即意识到我犯了个错误。当众表扬，私下批评，永远是对的地。说到这里，忍不住想说几句项目经理的素质规定，有一个笑话，是我的一个师傅讲的，“有一个项目经理休假出去玩，把身上的东西不小心都丢了，天晚了，无奈下找个农家求助，老大爷说住下可以，但要他帮忙干活，先是铲粪，一会就干完了，然后让他挑土豆，大的一边，小的一边，挑了一夜，一个也没挑出来”，讽刺当项目经理的非常善于把责任推给别人（putshittoothers),但永远不会做决定。

由于项目经理工作的性质，他永远不会做什么具体的工作（理论上），所以一个不负责任的项目经理总能找到借口把责任推给负责具体工作的人，假如这样的一个人作为团队的领导者，可以想象项目成员们的感受。一个优秀的项目经理必然具有以下几种特点，敢于承担责任，敢于下决定，责任心强，工作细致，坚韧不拔（在巨大的压力下能保持镇定，领导团队前进）。关于项目经理应当具有的素质，感觉尚有很多东西可以讲，以后有机会再说。需要说明的是，素质和知识，经验无关，而是和个人的性格，品德修养有关，一个经验丰富的项目经理同样也许是个不负责任的人，每到关键时刻总是把自己摘得干干净净。（我的一个师傅就是如此，正好给我做了反面教材）

(5)项目的计划项目的计划应当在第二阶段进行，其重要性就不再强调了。在项目的目的拟定后，通过项目的计划可以拟定项目的时间表，所需资源，成本，以及重要风险等重要内容。举例来说，以做一把椅子为例，目的是一把木质的椅子，有扶手，刷红漆。工作细化后，可以发现，有这样一些工作要做（是我想当然的，我可没做过椅子）：

1，打出椅面，椅腿，靠背，扶手；

2，刷清漆；

3，晾干；

4，装配；

5，刷红漆；

6，晾干。再进一步细化，把所需时间加进去，得到下面的表格，

制作刷漆晾干

椅面412椅腿10.50.5靠背21.51扶手1.511装配需要2小时，椅腿是4个，扶手是2个。考虑先后顺序，显然制作之后才干刷漆，晾干后才干装配，然后才干上红漆（2），最后再晾干（2），完毕。制成图表后会发现，在人力充足的情况下，所有工作在也许的前提下都可以同时进行，最长的一条线是制作椅面－》刷漆－》晾干－》装配。。。总共需要4＋1＋2＋2＋2＋2＝13个小时，这就是所有完毕所需的最短时间，我们称其为关键途径（CriticalPath)。关键途径的意义在于，在关键途径上的任何工作假如被延误，整个项目的完毕将会延误，不管其它工作做的再好也没有用。所以在关键途径上的工作的风险要引起高度重视，由于对全局有重大影响。

再考虑假如人力局限性时，比如说只有3个人，制作不能同时进行，怎么分派人力？分析后可以发现，让1个人负责靠背和扶手是最省时间的，这时关键途径改变了，所需总时间增长为16.5小时。

上面考虑的是比较简朴的情况，假设一个工人既可以干木活，也可以油漆，考虑到不同工种，每个工种的人力情况，会更复杂，但原理是同样的。实际工作中项目会复杂得多，但是可以依照这个原则来做，一方面确立项目目的，然后将工作逐步细化，给每个工作一个预测的时间值，找到关键途径，根据现有人力资源情况进行调整，重新拟定关键途径，得到总的时间表，所需总的劳动时间（可据此做预算），重要风险，相应对策。很多时候，最困难的是将工作细化，特别是项目经理对项目涉及的技术不了解的时候，我的办法是把所有的相关部门经理们召集起来，让他们说，他们都需要做些什麽来完毕任务，你会发现这象是一个网络，左边的起点是你的项目成立，右边的终点是项目的目的，部门经理们告诉你的每个任务是网络的节点，它们之间的关系是网络的连线，而每个任务所需的时间和资源是连线的权值。一旦你将这个网络对的的建立起来，剩下的只是时间问题。项目计划的另一重要部分是项目的风险分析。

一方面要做的是把所有有也许发生的风险所有列出来，然后依据它们发生的几率和对项目的影响赋予一定的值，举个例子，用5代表最高，1代表最底，货品晚到的几率是5，而对工程影响也是5，相乘后这一风险的值是25；人员短缺的几率是3，影响也是5，相乘后是15。。。依此类推，你会得到一张表，而表内所有结果是25的，作为项目经理，必须要采用行动，假如此时不予理睬，届时候你就等着晦气吧！

(6)项目的财务管理对项目而言，与其说是财务管理，不如说是成本管理，或是成本控制。说复杂也复杂，说简朴其实就是省钱，但省在什没地方，怎麽省，就是学问了。就我的经验，有几个原则是一定要遵守的。

一方面，不能为省钱而省，不能本末倒置。项目，就是在一定期间，一定的预算内完毕特定的任务。这一点一定要记住，完毕任务是最重要的，假如由于成本问题影响了最终目的的达成，就是本末倒置，通常会导致项目的失败。同时时间也是一个极具约束力的因素，很多时候项目的时间规定很紧，压力很重，解决的办法通常是规定更多的资源，即意味着成本增长，这是必须付出的代价。举个例子，前段时间我们拿到了一个协议，是在一个我们新进入的业务范围，对于我们来说，把项目按质量规定准时完毕是最重要的，由于要靠这个项目坚定客户对我们在这一领域业务能力的信心，不能给竞争对手任何口实把我们从好不容易进入的这一市场赶出去，所以这个时候，花多少钱就是次要的了，只要我们在这个新市场站稳脚跟，花多少代价都是值得的。所以说，该省的钱要省，该花的一定要花，一切以目的为重。

另一方面，一个事先通过充足准备制作的预算是非常重要的。由于预算事实上是一个衡量标准，一个藉以实行成本控制的依据。这里有一个关于预算的概念需要澄清，我认为预算是要完毕一个特定任务所需要的成本。通常会有两种误解，一是认为项目结束时实际开销比预算越低越好，显得项目经理管理水平高，给公司省了更多的钱，错误！要做到这一点并不难，做预算时做得高高得就是了，事实上能把预算和最后得实际开销做得几乎相差无几，非常准确的才是一个有经验的项目经理，而事实上要做到这一点非常不容易，由于项目中总会故意外情况发生，是项目经理无法预测，也就无法做进预算里的；尚有一个就是误认为预算就是协议里相关部分的报价，错误！你做这件事花多少钱和客户为此付多少钱绝对是两回事！任务定了，真正的所需开销就已经在那里了，你也许需要一百万来做，但销售人员把这部分卖两百万，还是免费送给客户与你无关，那是他们需要从其他角度需要考虑的，你要做的就是要来一百万做你的项目而已。

预算怎麽做，也是一个很复杂的问题，个人认为，目前没有一个完美的办法。从前我们是这样做的，把也许要做的所有工作细化，比如说现场勘查，需要一个人，做8个小时，旅行时间来回4小时，共12小时。这样每一项工作都有一个时间的权值，而每一个工时，都有一个费率，费率的制定是由相应的部门拟定的。举例来说，部门A，总共12个人，一年总开销为一百万（涉及一切，房租，家具，水电，培训，薪水。。。），其中有10个工程师，每个人每年工作2023小时，那末他们的费率就是1000000/10/2023=50,而部门B由于技术性更强，同样人数一年开销2百万，那末他们的费率就是100。这样做预算的好处是很容易，我们有个软件，把基本数据输入，一下就算好了，自己在根据实际情况编辑修正一下就差不多了，坏处是难以控制，工程部门是按工程师花在项目上的时间来找我要钱的，这样就产生了一个怪现象。一个预计花100小时的工作，一个杰出的工程师50小时就完毕了，而一个新手也许要150小时，而对于他们部门来说，这个新手的奉献是老手的3倍，SHIT！你要是老板你用谁？答案是显而易见的，而我就惨了，花钱多不说，进度还慢，而我无从知道这延误的50小时是由于出了困难情况还是在现场的是个笨蛋！我经常在月末收到工程部门的时

间报告后和他们打架，为这个得罪了很多部门经理。

后来老板们也发现这样有问题，改成了特定的任务一个固定打包的价格，这样做我无须再控制，反正就这麽多，但有此外一个问题存在，就是如何界定工作的范围。这样做以后经理们经常来找我，说这个那个不在范围之内，规定加钱，同样让我头痛。目前能做的只能是以前一个方法为依据做固定价格，尽量细化工作范围，同时手里留一部分预算，留作真故意外发生时追加用。

最后就是抓住成本的重要方面，严格控制。对于我做过的大部分项目来说，重要部分在两个方面，一个是硬件，一个是人力成本。有一个例子，我接手一个大项目时，鉴于前一期的经验，加强了对损坏部件更换的控制，效果是惊人的。前一期协议额约5000多万美元，这部分的开销按LISTPRICE算达400万美元之巨，而这一期协议额约1亿1千万美元，控制后的结果是不到50万美元。（可惜没人给我发奖金，让我倍感挫折）另一个例子是关于人力成本控制的。通常情况下，把一些简朴工作外包是个好主意。以设备的清点为例，以前是自己的工程师做，后来包给客户指定的清关公司，一箱货付5元，总共不到1万元，而我们自己的工程师来做，我得花几十倍得代价（在按工时付费的模式时），而工程师们也很不乐意，觉得让他们干这种活简直是在欺侮他们。

另一个需要注意的是客户的额外需求。客户经常在项目中间提出这样或那样的规定，我一般根据协议判断，是否是我们的义务，假如不是，需要向老板们报告，规定追加预算，并且应当让客户承诺如何作出补偿。额外的规定总是随着着预算之外的硬件和人力资源规定，且经常会影响计划的顺利进行。最佳的方法是不让它发生，在计划阶段做好工作，不给客户机会提出额外需求。

个人的精力毕竟有限，把重要方面抓住，其它就无所谓了。在我管的项目里，这两方面的比重加起来一般在整个预算的95％以上，只要把这两方面控制好，足够了。所以我历来不管助理们请客户吃饭HAPPY花了多少钱，闭着眼睛签字，实在是毛毛雨啦！

(7)项目的执行项目的执行无疑是项目管理中非常重要的一个阶段，从协议签订或项目计划任务书批准开始，到整个项目结束都是项目的执行期。对于工程项目来说，重要是到PAC（初验）为止。项目经理在这一阶段的重要职责就是依照拟定的计划监督项目的执行，并根据具体情况对计划随时做调整，以适应实际情况的需要，协调各方面的资源，保证项目可以准时按质完毕。

就本阶段而言，经验是非常重要的，并且与项目经理的个人能力有很大关系，这个能力通常是指在压力下解决问题的能力。对于从未经历过这一阶段的人来说，项目的执行很难解释，我个人认为，有几个要点一定要时刻铭记在心，也可称为原则吧。

第一条，永远不会有一个项目没故意外；就是说不管在做计划时有多认真，多全面，总会有一些事情你预见不到，或是没有充足估计其危害限度，认真的计划会减少问题的发生，但不大也许完全避免，所以总会有问题出现，需要你去解决，这也是项目经理在项目执行阶段存在的意义。结识到这一点很有用，它能帮助你保持安静的心态，同时通过你的表现稳定团队的情绪，并可以积极的去解决问题，毕竟问题总会有的，某种意义上来说，你应当感谢它，若没有问题的出现，项目经理的存在就没有了价值，你也就没了这份差使。

第二条，充足理解协议中的相关部分，假如没有协议，就把项目计划任务书作为目的，要是项目计划任务书都没有，且住，你尚有工作没做完，不能开始执行！理解项目的目的，要做的工作，工作的范围，你所拥有的权限等等，这样在碰到问题时，你可以迅速判断问题的性质，是可以你自己解决的，还是必须要报告。刚开始做项目时，有过一次给别人“擦屁股”的经历，有经验的人都知道，这种事时最讨厌的，由于当时的记录，经手人都也许不存在了，问题解决起来很棘手。当时的问题是用户抱怨很多材料短缺，致使部分系统不能满负荷工作，因此拒绝初验。与公司内当时经办人查询，因素是材料没有按照规定包装，导致使用时管理混乱，且没有任何原始记录可供查询，我只好带着工程师把所有站点跑了一遍，把现场情况所有登记了，给客户补足了所有短缺的材料，耗时6个月，材料费几百万。得到的经验是，材料一定要按照规定包装运送，工程中的文字记录必不可少，不能图省事。尚有一个收获是，凡是不能明确是谁的责任时，就是你的责任，假如想要客户负责任，可以，拿出证据来。

此外一次，在项目中发现少订了几千米电缆，经与设计工程师核对，他认可是个错误，恰好客户有该型号的电缆，向领导请示后，买了几千米解决