月初参加了一个西门子管理学院的项目风险管理研讨会，期间对于“美国飞利浦芯片厂着火”案例的分析得到几个在座同事的认同。因为几天的时间里也确实感觉到了很多项目管理人员知识系统的不完整，索性于空闲间回忆一下很久工作中管理项目的心得并结合这些年做商务管理的体会，供刚刚从事项目管理的朋友们借鉴。
　　另，本文不谈SWOT、定量分析、菲尔德法等国外引进的种种定量分析方法，但这并不不是说我个人对这些方法排斥，而是在工作中我发现在不了解什么是项目风险管理的情况下空用并盲信定量分析，有时不但不能达到预期效果有时反而会增加项目运作风险。我在外企工作的时间较长，所读书籍中接触的也多为国外的管理模式，因此懂得并理解依靠公司制度、流程管理、定量分析方法等确实在一定程度降低人为因素对项目、公司的影响，但实现这个科学方法的前提是实行此方法的人须对这种方法的原理及相关联的各个专业知识有一定了解，否则的话恐怕只能管理些简单、单一的项目了。项目运作是如此之复杂，况且一切事物又处于不断的变化之中，怎是几个公式就能概括的?!
　　项目风险管理不是某一个人的事情。同时也不仅仅是人的事情。我们在与项目经理讨论项目的时候，有一些项目经理明显讲自身定位于经理上，总想如领袖般指点江山，带领各部门完成项目的执行、规避项目中的风险。这些人容易犯的毛病是：在职责划分清楚的情况下，确总是有意无意间对相关部门的职责“指手画脚”。这类项目经理往往是比较年轻，又参与过几个大项目管理的。有一定的激情和项目管理的经验。但追其根由，是对项目经理究竟干什么不清楚、同时不知道如何根据项目实际情况调整自己的工作。我并不是反对项目经理站的高、看的远。而是希望同时能脚踏实地。在现实中，真正需要建立“项目式”组织形式去管理的项目毕竟是少数(至少在西门子例如京津铁路项目等需要建立项目式组织形式的项目也不常见。在工程土建项目比较常见，但是从我了解的情况来看其项目经理更多的是政治及礼仪方面的，总工程师担负起了TPM及项目总经理的部分职责。对于此类项目我了解不多，没有发言资格)，大部分还是以职能式或者混合式或者矩阵式组织形式出现并已经试用的。况且，即使是项目式的组织架构，一般成熟公司也有模式遵循，而绝非项目经理渗入项目管理的各个方面。某种程度上说其意义已经超出了项目经理的范畴(虽然他仍可被称做项目经理)。比如说他为此项目注册法人的话，他也可以被称做CEO。能有此眼光与能力的，虽是项目经理，但早已无人称其为项目经理了。因此我们在此仅讨论中小型项目的项目经理职责及在自己的职权范围内如何规避项目风险。
　　有关“指手画脚”一事，我觉得有必要把那天讨论开始前在“破冰船(Ice-breaker)”中大家的痛苦再回忆一下。我很惊异并理解在场有百分之八十以上的朋友认为因为西门子内部部门分工及职责划分不清晰给大家的工作带来了诸多不便(暗含之意是流程管理妨碍了各个项目经理按照自己的想法全面管理项目)。我们姑且不去评论西门子的管理模式有何弊端(百年老店能够存活自有其存活的道理，况且也不是我等水平的人就可以妄加评论的)，但具有讽刺意味的是参与讨论的几个分组均出现了两个问题：一是忽略了自己责任范围内的事儿，二是不该自己做的事儿替别人操了不少心。“攘外必先安内”，我想从这儿并以当时的精简模型开始风险管理的讨论。并且此风险管理主要指在项目经理职权范围内可以预见并规避的风险。
　　我们常指责公司架构的弊端和其它部门没有做或没有做好自己职责范围内的事情，却常常不想想自己是否已经做好自己份内的事情并宽容地理解一下其它部门。因此，我们首先以那天的模型为基础分析一下各个部门的分工，尤其是项目经理的职责范围。
　　我们将项目管理精简成：技术支持-项目经理-商务，三个主要部门。而对于采购、财务、物流、产品、市场、销售等各个部门姑且不做考虑。(这样做的目的是为了论述起来比较清楚，而绝非这几个部门在项目管理中不重要。)如果非要解释一下，我以西门子架构为例加以简述。为了合归并确保采购安全，采购部往往门是独立于项目的，项目经理除对产品性能等建议外实际价格和供应商干涉很少。其中确实存在项目风险管理问题，但不在此讨论范围。财务在西门子架构中(扩大来讲是欧洲企业)实际上主要负责公司的账务处理，业务上的事情一般不直接介入。会计分类上我们称其为财务会计。物流也是相对独立并且固定的部门。在一定程度上物流的工作具有规律性，且在一段时间内不会发生太多改变。除非供应商或者运输公司发生大的变故，一般不会对项目有所影响。产品部实际上和技术部门的联系较为直接。一旦项目开始，我们就不必在产品、尤其是公司内部产品质量上耗费精力。市场与具体项目很少有直接的联系。销售部虽然在具体项目中自始至终不会中断与项目的联系，但其作用比较“特殊”。除去这些部门，与项目管理联系最为密切的三个部门即为技术部门-项目执行及管理部门-商务部门。而项目经理主要负责第二个部门的管理及其余两个部门间的协调。
　　在分别阐述完各个部门的职责之后，我们可以开始说“项目经理管什么?”这个问题直接回到了我们刚才讨论的部门间的职责划分问题，并首先提出了由于内部权责不清引发的项目风险规避问题。只有在明确此问题的基础上项目经理才可以全力执行项目，规避外部风险。在上面模型里，我总结的项目经理或者项目管理的主要职责应该是“在技术部门确认产品功能及方案无问题的前提下，在商务部门签署合同约束及价格下确保项目在规定时间内完成并得到客户认可，同时保证公司在此项目中及时收款且实现预期利润。”此种定义对于中小型中项目经理的工作有很好的权责规定并在一定程度上帮助项目经理将精力集中到项目中最重要的部分，并可在一定程度上规避由于内部分工不清带来的项目执行风险。让我们再细分析一下这个定义，看看它究竟给项目经理明确了什么。“在技术部门确认产品功能及方案无问题的前提下”的意思是在项目经理不应在项目执行过程中置疑或是过分关注产品本身及技术解决方案的问题。由于历史原因及国内项目的特殊性，国内很多项目经理都是技术出身(其实只能说是项目经理下设的TPM，即技术项目经理，这也是国内项目完成的很好，但是经常亏损或不能保证预期利润的原因之一)，在项目执行过程中往往自觉不自觉地对技术操心(事实上，我还见到过不光为技术方案操心的，甚至经常赶赴第一线把现场工程师的活都干了的)。这里并不是说技术不重要。实际上项目经理如果一点技术都不懂，我很难相信他能运作好一个项目。它是在讲：项目经理应该对自己职责范围内、并且专长的事情付主要责任并尽可能专注。项目经理正式接手项目应该是从PM080(Start of project)到PM070(End of warranty)。由于项目情况不同，他可能会工作前延或后推。但不管怎样，他必须首先明确自己的职责范围。事实上，不经意间多做的工作往往适得其反。项目经理可能无意间害了同事也给项目带来风险。怎么说呢?项目经理的专长不会长过专门的技术人员(如果是的话属于公司用人问题)，万一指导错误，技术支持部门的人将要为此错误承担责任(因为职责划分原因)同理，在现场的话项目经理也不会比现场工程师熟悉(虽然很可能他以前也是在现场开始自己职业生涯的，并想借此回忆或者嘚瑟一下)，质量问题也容易出现隐患。再换个角度讲，如果我见到一个项目经理每天有时间验证技术部门方案或者帮助现场施工，我只能猜测他目前还不够项目经理资格，或者够格但是工作量远远不够。“在商务部门签署合同约束及价格下”的意思是说项目经理可以合同签订前建议，在合同签订后查阅。但必须清楚合同一旦签订，就意味着公司已经认可这个条款及价格。项目经理必须在此前提下尽可能好的执行项目。我曾接触过项目经理由于经历和经验丰富，加之熟悉合同签订过程中的方方面面，因此在合同签订后仍然四处议论或采购价格高、或公司太黑、或风险太大……但又有什么用呢?项目经理的责任或者说是价值就是在目前既有条件下如何通过自己的经验最大化的实现公司价值并提高客户满意度。“确保项目在规定时间内完成并得到客户认可”是项目管理中两个重要任务之一。项目经理是项目实施的灵魂，是联系公司与客户的纽带。一个优秀的项目经理不但能按部就班、保质保量的完成项目，而且有时能够给公司带来新的项目。完成项目实施并得到用户认可是优秀项目管理的先决条件。“同时保证公司在此项目中及时收款且实现预期利润”是项目管理的目的。这是目前为止我所看到项目经理最为缺失的能力以及在实际工作中和其它部门分歧最大的部分(同样是由于前面提到到目前很多项目经理是做技术起家的原因)。我先举一个在我所在公司的项目经理的例子。此项目经理花费了很长时间协助销售拿到项目(副作用您猜)并在担任本项目项目期间协助用户在第一时间几近完美的完成了项目，在用户那里得到了很好的口碑。结果呢?公司收不到钱导致项目亏损。我们内部称之为由我们付费的客户安插在我们公司内部的奸细!但事实上，我没看到其他哪一个项目经理那两年比他辛苦、认真。为什么会发展成这样呢?因为他没有想到一个项目经理除了要保证项目技术无风险实施(TPM)外还要保证商务盈利(CPM)。这两部分缺一不可。否则，做了项目不赚钱大家吃什么?总不能做了越多赔的越多吧?刚才提到了就收款等容易与相关部门出现摩擦的问题。那么这些事情究竟由谁来负责比较合适呢?下面我们就来谈谈这个问题。
　　这个问题只有在“职能式”或者“混合式”项目组织架构里出现。因为如果是大项目式组织形式，CPM和TPM实际上是在项目总经理下平行并设的。职责分工相对比较清楚。然而当项目经理更多地介入工程实施，而又和商务(或者财务、或者CPM……)平行(有时甚至行政上还低一等，毕竟项目经理名字上判断只管项目)时，这种问题就出现了。我将从两个角度来阐述这个问题。首先，我刚才谈到了职责划分不清容易从内部给项目执行带来风险。但现实中，有些事情是不可能分清楚的。开始部门同事提出的“痛苦”就是受西方哲学的毒害试图证明“不是一就是二”的论题。而项目经理在项目中特殊的地位造成了他不得不和各个不同的部门联系(模型中只有两个，现实中包含前面被简化掉的各个部门)。在交叉问题上，我主张以多为他人着想的原则在良好沟通的基础上尽可能多做一点。这里又包含两方面意思。第一通过此种行为可以建立良好的人际关系，在其它事情上可以得到弥补，第二
　　刚才是好些事情是分工清楚的角度讲的。我们还可以从项目经理的地位这个角度分析那些分歧工作是否应该由项目经理负责。我也从两个方面来谈，第一项目经理是公司和用户的重要纽带，他多项目的了解以及和客户的关系比其它部门同事都有优势。以他为窗口可以同时缩减本公司和客户很多时间并降低由于不熟悉的人间的沟通容易引发的风险。第二项目经理以项目执行情况考核工作业绩，职能部门不会因为本项目亏损而拿不到奖金。项目经理由于直接对客户有时候日子不好过，而职能部门一般对内，他/她无所谓。这时项目经理不得不自己亲自去做。因此无论是主观还是客观我都认为项目经理处理这些事情比较合适。