修建一个水电站，是一个项目，做一顿饭，也是一个项目，虽然它们复杂程度天壤之别，但它们都具有项目很多共性。项目复杂程度不同，项目管理起来难易程度也大相径庭。一般项目，只有项目实施后，才认识到实际比想象的要难，甚至难得更多，除非有真正的项目管理专家亲自主导。之所以强调是真正的，大都负责项目的，都认为自己很懂项目管理，不就是定好目标，做好规划，执行到位么。懂也许真的懂，但不一定专业，就像看别人杂技表演，看得简单，但自己却做不到，这就是所谓眼高手低吧。
项目开始，大家热情很高，双方关系也非常融洽和谐，甚至憧憬到喝庆功酒了。甲方公司高层领导希望项目越快越好，乙方公司项目经理不知是碍于情面还是胸有成竹，就爽快答应到年底5个月保证完成。很快，一张壮观的实施里程碑线路图就呈现到领导面前，完整的详细计划至少让领导觉得还是很满意的。尽管有专业人士提醒，那也只是些杂音，终抵不过大家激情和乐观。加上领导动员鼓舞：目标明确、全力以赴，大家觉得项目更有保障了。乙方公司是专业的，而且还有很多所谓的专家坐镇，再有异议，可能就要犯众怒了。
有人把项目共性的内容梳理出来，编写出PMBOK知识体系，其在国际上都具有权威性。那问题来了，用这个知识体系如何指导建造水电站和做一顿饭呢？PMBOK知识体系的内容非常丰富、全面，对于大项目，好像都适用，但对于一些小项目，就显得非常笨重了，特别对于那些了解PMBOK不够深的人，感觉里面全是对的，却又无从下手。其实，PMBOK一开始就强调，在具体应用中，要学会裁剪。听起来很明白，就是自由选择、按需所取，感觉也很容易，自己能掌握了主动权。简单的表象，往往蕴含着深刻的道理。就像画画一样，画，大家都会，小孩涂鸦也是画，画得像、画得逼真、画得传神，就是不同的境界了，其背后的技能水平也是大相径庭的。只有高级的画家，我们才尊称为大师。大师之所以为大师，能够化繁为简，把复杂的问题简单化。师者，谙熟表象和本质之道，行走其间游刃有余。
（图片来自网络侵删）来的都是专家，大家都对乙方公司关键人员这样称呼的。甲方公司可能出于尊重，乙方公司更可能向甲方公司表达一种重视的态度。的确，乙方公司提供给甲方公司关键人员的简历，确实有一定份量，无论学历和项目经历，都是无可挑剔。
项目监控
（图片来自网络侵删）按PMBOK说明，项目分为启动、规划、执行、监控和收尾五个阶段，其中项目监控对其他阶段都起作用，这也是甲方的重点工作内容之一。项目监控点串联起来，构成了PDCA。P指项目计划，D指项目执行，C指项目监控，A指变更管理。项目计划颗粒度大小和变更管理方式，决定了项目敏捷程度。
乙方公司本来有一套信息化实施项目管理方法论，在行业中，多被其他公司拿来学习使用。但是，在甲方公司的项目中，感觉仍是一个方法论，在实践中落地得好像不实在，执行过程明显紊乱。当然，客观的说，其中很多点还是是相似或重合的，是否纯属巧合，不得而知。方法论本身可能没有问题，问题出现在对方法论的应用上。就像一把剑，本来是一把好宝剑，就怕半懂不懂的人大胆耍起来，一不小心反而伤了自己。
在项目启动阶段，甲方公司关注重点是项目章程合理性，这也是监控项目的总的抓手。项目章程是由主导项目的负责人或分管项目领导主持制定的，相当于项目的“宪法”，其从顶层确定了项目目标、准备做什么、由哪些人做、怎样做等。制定项目章程，听起来很正统，而有时正统的东西往往又被贬为死板、教条，其实不然，章程不是事无巨细的条条框框规定，而是对项目整体骨架的描述。章程可粗可细，甚至可有可“无”。对于很小的项目，可“无”指形式可以没有，或换种表述形式，但心中一定要有。制定项目章程可能并不困难，如何把章程内容合理分解和落实，确实需要专业知识和技能管理，也是项目成败的关键。项目章程应该是一篇实验论文，不仅需要论点明确，还需要有实实在在的实践论据支持，而不应该是一篇说明文。
乙方公司提供给甲方公司的项目章程是从模版修改而成，整体描述还比较全面、详尽，但从后面项目执行的结果和出现的问题来看，可能很少有人，包括项目经理，经常关注它。说一套，做一套，部分就回归到凭经验管理模式，这可能也是项目管理的通病，其根源是执行力弱，不能坚持。很奇怪的是，当甲方公司的项目经理强调项目章程严肃性的时候，领导却说不要管得太死，怕破坏了项目的和谐气氛。
项目规划阶段主要制定项目战略和一系列管理计划，这些计划也不是一成不变，但也不是随意改变的，要统筹考虑项目的稳定性和灵活性。很多因素都可能导致实际执行的和计划不一致，计划订的越详细，考虑的因素越多，计划的精准性可能就越差，而且，耗费资源也越大。但是，如果计划是合理的，执行起来则更有序，也更轻松。不过，一旦出现偏差，纠正起来也不容易。如果计划太粗，计划的控制力度就不实在，执行起来就有点忙乱。这就需要权衡利弊，确定计划任务颗粒度大小。权衡也是一门技能，甚至是高级技能，需要一定的经验历练，才能玩到恰到好处。
乙方公司进入甲方公司后，立马展开需求调研，着手制定详细计划，斗争非常高昂，甲方公司领导看到也是满意的，这可能也是一般项目开始的场景吧。
项目章程从某种意义上说，是一份项目顶层计划方案，据此再制定相应的详细计划方案。在所有的计划中，进度计划是核心，它是连接开始和结束节点的主干道，其他计划归根结底都是为进度计划服务的，或者从属于进度计划。 在方法论上，进度计划按WBS分解成树形结构，分解到对时间估计有把握为止，再往下的计划分解，可以通过双周滚动计划迭代推进。进度计划关键要明确责任人和产出物，这是项目监控的抓物。目标可以看做进度计划的起点，从目标开始分解，直到最小的可执行的任务包，要时刻保持线索的连续性。一部分计划中没有考虑到的，或在计划的行动中新产生的问题和风险，可以通过问题行动清单来管理，这里，风险作为未来可能出现的问题对待。问题的产生更多来源于会议讨论，做好会议纪要，并把问题行动记入问题行动清单，便于进行跟踪。问题的解决方案可能转化为行动任务，行动任务可以记入双周计划中落实，对于只需要确认类问题，可以直接反映到项目周报中。如果把计划内外的任务都记录了，对任务管理至少在逻辑上是全面的。这样，进度计划和问题行动清单珠联璧合，便成了项目监控的一双有力抓手。
乙方公司计划很快制定出来，大的计划任务描述应该没有什么问题，毕竟实施方法论都把这些固化了。但是，任务安排就有点不专业了，很明显的父子任务起始时间都不一致，有些任务是有先后顺序的，起止时间也都被拉齐，甚至不同子项目的格式风格也有很大差异。当甲方公司提出异议，乙方公司百般解释，还强调他们做过很多项目都是这样，关键看执行结果。当然，结果也不是他们预想的，实际执行大都偏离了计划。
项目沟通是项目过程中最普遍的现象，会议讨论、评审又是沟通的主要形式。会议讨论一般是团队协同的一种高效方式，用不好，反而成为耗费资源的老旧机器。会议纪要是对会议讨论场景一次速写，记录下关键要点，以后可以再现会议的轮廓和本质特点。会议开始应明确会议主题和时间，方便会议主持人把控节奏，防止话题发散。主持人最好不要参与讨论，防止变成自己演讲。当然，还需一个人记录会议纪要，必要时对会议录音。会议纪要可以把结论性东西和下一步行动记录下来，问题体现在结论中。记录会议纪要，形成了一定的共识，最多完成会议目标一半，会议纪要里待解决问题的行动跟踪则是完成会议目标另一半。会议跟踪需要耐心和坚持，当然，借助于信息化的自动化方式，可以事半功倍。
乙方项目经理几乎整天看不到在座位上，他更多时间用在参与大大小小的会议讨论上，几乎不能静下心来钻研项目的事情，以至于项目积累的问题越来越多，都不忍心说他不是。项目章程也明确规定展开高效会的方式，或者没有宣贯到位，或者早被遗忘了，很多会议主题不聚焦，有的变成持久争论甚至指责，同一个问题有的竟讨论半年之久。
双周计划是一种敏捷迭代的滚动计划，主要对近一二周计划进行详细呈现。敏捷管理方式主要适应于变化的环境，但也是基于能对最近要做的事，相对有把握的。所以，在制定计划时，越接近当前时间的任务，越详细，反之，渐远渐粗。双周计划向上衔接进度计划和问题行动清单，向下连接项目执行和项目周报。进度计划的颗粒度大小，至少分配大于双周时间任务量，问题行动清单中行动任务颗粒度大小正好相反，最好小于二周任务量。项目执行和项目周报，是计划转化为实际成果的过程和结果。
乙方公司也使用双周计划，各子项目描述相对本周时间来说，任务颗粒度还是较粗的，或描述得比较笼统。比如，连续几周都描述编制业务方案，只是通过进度百分比区别，而大多进度百分比，都是拍脑袋拍出来的。编制方案本来可以属于进度计划中的任务，在双周计划中，可以体现具体编制了哪些业务方案，这样上下线索就能衔接了。
项目执行类似企业生产过程，只不过前者是一次性活动，后者是持续的、重复性活动。项目执行主要按项目章程规定和项目计划要求进行的，把输入的资源要素，转化为客户需要的结果，这个过程应该是专业技术应用的主场。项目管理者对产品领域的生产专业技能不一定非常了解，有可能受制于技术强势，对技术方面计划没有深入探究，技术进度成为项目执行的瓶颈，技术却能找出各种条理由说明都不是他们的问题，他们永远坚信，只要客户把需求表达清楚，他们就能做到，质疑他们技术无疑是否定他们能力，一般不会被接受的。项目经理应该懂点专业技术，并邀请技术专家参与技术评审，对项目监控，重点关注阶段成果和项目最终验收。
乙方公司开始是由一个技术负责的来管理客开，技术负责不一定能承担起技术架构职责。项目后期出现问题的时候，乙方公司安排了一个技术架构师过来，但仍好像只是一个形式，导致开发问题严重影响了项目进度。乙方公司开始认为自己产品比较成熟，对接甲方公司系统最多做一些接口微调，没有考虑到甲方公司原有系统的特殊性，原乐观估计一个月时间可以完成，最后三四个月才完成。
项目周报连接着过去、现在和将来，它呈现给项目利益相关者一个视窗，让利益相关者能够相对充分了解项目情况，评估项目结果是否符合自已的预期，如发现问题，及时反馈给项目组纠正、改进。因为利益相关者众多，视角不同，关注内容也不同，所以周报的设计也是非常讲究的。周报设计时至少考虑：周报应首先满足重要的利益相关者口味；周报应该能呈现项目全貌和进展情况，不要太复杂，最好一目了然；周报不要忌讳暴露问题，相反，应让部分利益相关者重视和关注问题，甚至可以提出要他们给于支持和协助。
乙方公司和甲方公司每周召开一次周会，主要汇报上周工作总结和下周工作计划，给人感觉波澜不惊。因为涉及的项目内容较多，大家听久没有感觉了，以致到最后，甲方一些重要的业务利益相关者都不愿参加了。到一定阶段，乙方公司突然宣布不能如期完成计划，甲方公司很生气，也不知道问题出在哪，也不知道如何配合。
产出物是项目执行的结果，也是项目管理好坏的最好凭据。产出物不仅是项目最终交付的项目产品，还包括中间过程任务成果，以及和项目主产品相关的附加产品。有产出物，才好判断和评估某个阶段，或某个任务是否完成，以及完成得怎样。完成的怎样和项目的质量标准有关系，质量标准一般在项目章程约定和项目规划中规定。因为项目是独特的，项目生产的是“一次性”产品，不像工业制品那样有明确的型号规格标准，特别对于那些开发建设的项目，更没有体系性标准，所以，对项目质量的制定和监控，一定要专业技术人员参与，要求他们应该具有裁判的专业和精神。很多利益相关者其实不是很清楚一些产出物细节，却又被要求参与项目阶段评审，结果只能靠评审员自有的专业性和个人感觉了，这也为以后的扯皮留下很大隐患。其实，从目标制定开始，就包含质量管理问题。如果目标定的很笼统、很抽象，以后目标是否完成，就很难评估。如果按OKR方式制定目标，目标包含一系列指标属性，这些指标属性又可以继续分解，最终落实到产出物上，那么，对项目了解即使不是非常专业，也能做到按图索骥。
到一个阶段，乙方公司也有产出物，有的需要甲方公司评审或验收，这时甲方公司很犯难，不知乙方交付的东西是否真的满足需求。比如业务方案，洋洋洒洒写了很多张PPT，听起来好像都没问题，不过总觉得少了点什么，或担心少了点什么，但又说不上来。
变更管理的内容是项目过程中最不稳定的因素，也是项目管理的难点，当然，这个难点也是其他活动造成的。变更不都是消极的，也有迭代改进完善的。当然，项目中最大变更还是需求变更。但是，需求变更也不是任意的，需要先确定基准线，保留在基准线上下一定的浮动，才启动变更程序，否则会造成项目不稳定。除了需求变更导致计划变更，还有计划开始制定的不合理，也能造成后续任务严重延迟，进而导致不得不变更。剔除惩罚的因素，减少消极的变更，需加强项目监控预警能力。
甲方公司管理规范性也有些问题，这也是甲方公司想引入外部良好经验，提升管理水平的初衷。然而，乙方公司总是希望客户把需求充分、准确表达清楚，这样才能规划出完整方案。听起来没问题，但是乙方公司要求甲方公司对需求很专业，这就有点强为所难了。乙方公司把项目延迟的主要原因归结为甲方公司需求老是变动，双方不断扯皮，和谐的气氛逐渐有点尴尬，甚至有翻脸的倾向。一般来说，甲方公司有责任表达需求，但不能保证就是真正的需求，真正的需求，应该由乙方公司的需求分析师或产品经理进行引导、挖掘、提炼出来。
项目管理很重要，直接关系到目标和价值实现。中国第一次认识到现代项目管理的威力是在鲁布革水电站项目上，该项目成功实现了成本和时间双降40%左右，给我们启示是：项目核心领导团队和科学的管理方法非常关键，项目经理是项目核心领导团队的灵魂人物，对项目成败与否起到至关重要作用。项目经理应具有三种核心能力，包括管理力、专业力和沟通力，这三种力需要耗费精力，合理的精力分配才能产生更大的合力。好的项目经理能把三个臭皮匠变成一个诸葛亮，糟糕的项目经理会把三个诸葛亮变成一个臭皮匠。
乙方公司的项目经理换了几茬，每人烧完三把火后，就没劲烧了。乙方公司派的项目经理多少有点随意，也没有项目经理资质认定。过来的项目经理更多在实施方面有点经验，在实际工作中，更多精力还是放在业务沟通上，这就导致未顾此却失彼。很明显，项目管理问题导致项目延期好几个月，这几个月的人员成本是很大的，很奇怪为什么乙方公司能容忍？甲方公司实在忍受不了，给乙方公司发了严重警告函。
