回想1997年被调派回国负责当时原邮电部的“绿卡工程”(即现邮政储蓄系统)建设的时候，当时有三家供应商负责提供全国各省的系统安装，这个项目的资金安排是原邮电部负责支付各项目的大部分资金，各省及市单位负责支付当地系统的小部分资金。当时很多地区的项目在建设完成后都需要进行变动及返工，经过很长的试运行期才能够完成验收过程。只有我们一家是当时最快得到验收文档的供应商，因为我们在各地执行项目的时候，严格执行部的要求，对地方单位所提出的功能变动采取严格的范围变动管理方法，任何变动必须得到部的同意才进行变动，所以我们的交付比较顺利。当然，在过程中我们不像其他供应商一样按照地方的需求增加或修改系统架构，虽然常会与地方的官员发生争议，但多能够通过协调解决。我们能够比其他供应商更顺利地完成验收过程是因为我们能够明确理解部是负责大部分资金的单位，他们的意见才是最重要的，部是整个项目的主要“赞助人”，而其他供应商均未能有效把握“Sponsor”的定义，让项目延误了多月才能够完成。
当项目发起人建议项目的概念时，往往在经过可行性研究后对项目的范围及功能会有很多不一样的地方，不管是实际应用需求或资金问题，发起人的概念可能在项目立项时只保留下一部分的概念，只有负责项目费用的人才知道他投资这个项目的最终目标。如果按照项目发起人的要求执行项目，不一定能够得到投资者的认同，让项目走上冤枉路。
由此可以看到，当一个项目在实施过程中，往往项目发起人并不是项目赞助人，当然也有可能两者是同一个人，但明确体会“赞助人”及“发起人”的差异，让我们能够把握项目的焦点，降低项目延误的风险，减少交付时进行修改及返工的机会，降低项目的成本。项目经理对“Sponsor”(赞助人)及“Initiator”(发起人)的理解对项目能否如期完成有着重大的影响。
2.赌注
“Stake”的直接翻译是“筹码”或“赌注”，所以“Stakeholder”可以直接翻译成为“拿着筹码的人”。但中文翻译为“项目干系人”，这更让人感觉莫名其妙。
什么才的直接翻译是“筹码”或“赌注”，所以“Stakeholder”可以直接翻译成为“拿着筹码的人”。但中文翻译为“项目干系人”，这更让人感觉莫名其妙。 http://bbs.mypm.net
什么才算是“拿着筹码的人”呢?那就是在赌局完的时候(即系统开始运行的时候)，最终是“输”还是“赢”是看这个人在过程中投注的决定。在系统建设的过程中，是那个人“初步”决定哪些功能需要增加，哪些功能可以减少，明确理解系统在运行时能否提升部门的能力和效率，这个人便是系统应用部门的主管。这个主管及他的属下是系统使用者(User)，是项目干系人，但只有这个部门的主管才是Stakeholder。
我说那个“‘初步’决定哪些功能需要增加，哪些功能可以减少”的人，是因为做最终决定的不是这个Stakeholder，而是项目的Sponsor。Stakeholder有可能是项目发起人，但也可能不是。他需要说服赞助人对项目进行投资，让系统提供他所需要的功能来完成他的部门的工作。所以在项目过程中我们需要Stakeholder对项目的认同。一些中小型项目可能有数十个使用者，但可能只有一个Stakeholder，一些大型的项目可能有数万名使用者，但可能只有二三十个Stakeholders。我们的焦点错了，项目便会失败。
当我们在2003年负责实施澳门政府一个信息平台的建设项目时，我们面对的是数万名政府公务员，这数万名公务员都会因为这个信息平台的建设使他们的应用受到影响。如果我们需要这数万名“项目干系人”认同我们的设计，那么这个项目便没有办法如期完成。所以这个项目的Stakeholders只是部门的主管级人员(视系统本身的应用范围，一些供应数个部门使用的大型系统的Stakeholders是部长，一些只提供一个署或处应用的小型系统的Stakeholders是署长或处长)，整个项目的Stakeholders只有二十来人。我们只需要说服这些主管，让他们认同整个信息平台的设计便可以实施，而不是要说服数万个项目干系人的公务员去认同我们的设计方案。
MBO与MBE
项目管理本身的意义是MBA课程的Management By Objectives (MBO)与Management by Exception (MBE)的混合体。MBO在项目管理中是范围管理，成本管理，质量管理，沟通管理，采购管理和时间管理。MBE在项目管理中是进度管理，范围变动管理，争议管理和风险管理。如何适当应用这些知识，那便需要企业本身提供一套体系，或者需要项目经理本身为企业建立一套体系，同时改正翻译的错误。只有这样才能够推动我国的项目管理应用。
文章来源于领测软件测试网 https://www.ltesting.net/
