该帖子同步发自：(子墨的博客  访问该博客)

　　任何项目经理在学习项目管理知识的过程中，都明白“Project Sponsor”(翻译为“项目发起人”)及“Stakeholder”(翻译为“项目干系人”)的重要性。但从我过去二十多年的项目管理经验中，对这两者的认识和在项目过程中需要建立的焦点，让我感觉到一个项目管理应用的重大误区。

　　我曾经在五月发表了一篇文章，内容主要说明我国软件工程人员对需求的误解，导致软件行业未能有效把握客户的“需求”，使我国的软件缺乏创新。不期然，联想到目前IT项目管理的应用，也因为一些错误的观点，让项目管理在IT企业中走上另一段冤枉路。

　　过去数年，项目管理在科技企业中渐渐被重视，企业希望利用项目管理的理念来强化项目的交付质量，最起码也希望能够让项目可以如期完成交付，降低企业的交付成本，提升利润。所以，很多从业人员误以为只要考取了一个专业资格，便可以成为一个项目经理，有效执行项目管理的工作。

　　知识与体系的分别

　　要知道美国PMI项目管理的考试内容环绕着项目管理知识(PMBoK)的范围，PMBoK不是一套体系(Methodology)，它提供的是项目管理知识，但我们把Body of Knowledge 翻译成为“知识体系”，让我们误会只要完成有关知识的学习，便可以有系统地直接实施。但往往在实际应用这些知识的时候，才发现无从入手。

　　“知识”让我们知道“该做什么”(What)，而“体系”告诉我们“如何去做”(How)。缺乏一个体系，所有的知识只是理论，这也是为什么国内的新进项目经理感叹“不知如何把学习到的理论在实践中应用”的主要原因。

　　为什么一些基建项目，如盖房子、修路、建水坝等项目，能够有效利用项目管理的知识?那是因为这些项目的管理机制和实施流程比较成熟。项目在设计阶段已经把建设的方法(Construction Processes)有效地融合到项目交付的流程和机制(体系)中。

　　科技项目所需的时间往往比较短，范围变动也比较大，加上没有一个实施的流程和管理机制，所以科技项目往往未能有效地把项目管理知识应用到实际的过程中。

　　国内企业缺乏自建管理体系

　　一些比较成熟的管理体系，包括欧洲国家单位及企业所选择的Prince2 (Project in Control Environment 第二版)，美国MacDonnell Douglas 公司的STRADIS (Structured Analysis and Design of Information Systems), Ernst & Young 咨询集团的Navigator，或者是Agile的Method123等，都是一些常用的体系。

　　有了一套管理体系，才能够发挥知识的应用。欧美国家的企业大部分有本身的体系，按企业本身的项目特色及业务方向建立的管理流程和机制，让企业的项目能够按照这个体系实施。

　　要能有效地应用项目管理的知识，企业必须建立本身的管理体系。这是我们国内企业所最缺乏的。

　　其他项目管理误区

　　任何项目经理在学习项目管理知识的过程中，都明白“Project Sponsor”(翻译为“项目发起人”)及“Stakeholder”(翻译为“项目干系人”)的重要性。但从我过去二十多年的项目管理经验中，对这两者的认识和在项目过程中需要建立的焦点，让我感觉到一个项目管理应用的重大误区。

　　赞助人与发起人

　　所谓“Sponsor”，直接翻译应该是“赞助人”，但如何会变成“发起人”(Initiator)呢?假设A君有一个商业计划，可以让A君赚大钱，但因为缺乏资金，所以到处找寻投资者，最后B君对这计划感觉兴趣，愿意投资A君的商业计划，让A君这个“发起人”可以进行有关的计划，把计划成为事实。

　　这里谈到的是两个人， 一个A君是项目“发起人”，而B君是项目“赞助人”，A君的计划能够成为项目，完全是B君的投资才能够立项。但如何在项目管理的翻译中把B君翻译成为A君呢?唯一的解释便是这个负责翻译的“外人”在翻译的时候，由于对项目管理缺乏认识，错把“冯京”作“马凉”了。

　　项目赞助人

　　回想我1997年被调派负责当时“邮电部”的“绿卡工程”(即现邮政储蓄系统)建设的时候，当时有三家供应商负责提供全国各省的系统安装，这个项目的资金安排是“邮电部”负责支付各项目的大部分资金，各“省”及“市”单位负责支付当地系统的小部分资金。

　　当时很多地区的项目在建设完成后，都需要进行变动及返工，经过很长的试运行期才能够完成验收过程。我们一家是当时最快得到验收文档的供应商，因为我们在各地执行项目的时候，严格执行“部”的要求，对“地方”单位所提出的功能变动采取严格的范围变动管理方法，任何变动必须得到“部”的同意下才进行变动，所以我们的交付比较顺利。

　　当然，在过程中，我们不像其他供应商一样按照“地方”的需求增加或修改系统架构，常会与“地方”的官员发生争议，但多能够透过协调解决。我们能够比其他供应商更顺利完成验收过程，是因为我们能够明确理解到“部”是负责大部分资金的单位，他们的意见才是最重要的，“部”是整个项目的主要“赞助人”，而其他供应商均未能有效把握“Sponsor”的定义，让项目延误了多月才能够完成。

　　当项目发起人建议项目的概念时，往往在经过“可行性研究”后对项目的范围及功能会有很多不一样的地方，不管实际应用需求或资金问题。发起人的概念可能在项目立项时只保留了一部份的概念，只有负责项目费用的人才知道他投资这个项目的最终目标。如果按照项目发起人的要求执行项目，不一定能够得到投资者的认同，让项目走上冤枉路。

　　由此可以看到，当一个项目在实施过程中，往往项目发起人并不是项目赞助人，当然也有可能两者是同一个人，但明确体会“赞助人”及“发起人”的差异，让我们能够把握项目的焦点，降低项目延误的风险，减少交付时进行修改及返工的机会，降低项目的成本。项目经理对“Sponsor”(赞助人)及“Initiator”(发起人)的理解对项目能否如期完成起了重大的影响。

　　项目干系人

　　“Stake”的直接翻译是“筹码”或“赌注”，所以“Stakeholder”可以直接翻译成为“拿着筹码的人”。但中文翻译为“项目干系人”，这更让人感觉莫名其妙。

　　什么才算是“拿着筹码的人”呢?那就是在赌局完的时候(既系统开始运行的时候)，最终是“输”还是“赢”,是看这个人在过程中投注的决定。在系统建设的过程中，是那个“初步”决定哪些功能需要增加，哪些功能可以减少，明确理解系统在运行时，能否提升部门的能力和效率，这个人便是系统应用部门的主管。这个主管及他的属下是系统使用者(Users)，是项目干系人，但只有这个部门的主管才是Stakeholder。

　　我说那个“‘初步'决定哪些功能需要增加，哪些功能可以减少”的人，是因为最终决定不是这个Stakeholder， 是项目的Sponsor。Stakeholder有可能是项目发起人，但也可能不是。他需要说服赞助人对项目进行投资，让系统提供他所需要的功能来完成他部门的工作。所以在项目过程中，我们需要Stakeholder对项目的认同。一些中小型项目可能有数十个使用者，但可能只有一个Stakeholder，一些大型的项目可能有数万名使用者，但可能只有二三十个Stakeholders。我们的焦点错了，项目便会失败。

　　当我们在2003年负责实施澳门政府一个信息平台的建设项目时，我们面对的是数万政府公务员，这数万名公务员都会因为这个信息平台的建设使他们的应用受到影响。如果我们需要这数万名“项目干系人”认同我们的设计，那么这个项目便没有办法如期完成。所以这个项目的Stakeholders只是部门的主管级人员(视乎系统本身的应用范围，一些大型系统供应数个部门使用的Stakeholders是部长，一些小型系统只提供一个“署”或“处”应用的Stakeholders是署长或处长)，整个项目的Stakeholders只有二十来人。我们只需要说服这些主管，让他们认同整个信息平台的设计便可以实施，而不是要说服数万个项目干系人的公务员，去认同我们的设计方案。

　　项目管理本身的意义是MBA课程的Management By Objectives (MBO)与Management by Exception (MBE)的混合体。MBO在项目管理中是范围管理、成本管理、质量管理、沟通管理、采购管理和时间管理。MBE在项目管理中是进度管理、范围变动管理，争议管理和风险管理。

　　如何适当应用这些知识，那便需要企业本身提供一套体系，或者需要项目经理本身为企业建立一套体系，同时改正翻译的错误。只有这样才能够推动我国的项目管理应用。