给项目“发起人”和“干系人”正名
2022-05-18
企企科技
移动报销 事项会计 项目管理 协同办公
在学习项目管理知识的过程中，任何项目经理都明白Project Sponsor(翻译为项目发起人Stakeholder（翻译为项目联系人）的重要性。然而，从我过去20年的项目管理经验中，我对两者的理解和项目过程中需要建立的重点，让我感受到对项目管理应用的重大误解。
我曾在5月份发表过一篇文章，主要解释了中国软件工程师对需求的误解，导致软件行业未能有效地把握客户的需求，使中国的软件缺乏创新。出乎意料的是，它与目前有关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（翻译为项目联系人）的重要性。然而，从我过去20年的项目管理经验中，我对两者的理解和项目过程中需要建立的重点，让我感受到对项目管理应用的重大误解。
赞助商和发起人
所谓“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。我们的焦点错了，项目便会失败。
我曾在5月份发表过一篇文章，主要解释了中国软件工程师对需求的误解，导致软件行业未能有效地把握客户的需求，使中国的软件缺乏创新。出乎意料的是，它与目前有关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（翻译为项目联系人）的重要性。然而，从我过去20年的项目管理经验中，我对两者的理解和项目过程中需要建立的重点，让我感受到对项目管理应用的重大误解。
赞助商和发起人
所谓“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。我们的焦点错了，项目便会失败。
企企科技第二届用户大会
相关文章
