项目管理基础知识学习笔记L3

在实际工作中，我学会罗列项目中的关键角色，并为每类角色想一想他们关心什么：

项目客户（需求方）：提出问题或需求的人或团队，他们提供项目资金，对项目范围有发言权，并参与验收。例如，一个酒店会议中心升级项目的客户可能是会议中心部门的总监，由他出资并审核项目成果。
项目发起人（Sponsor）：希望项目成功并有权力推动项目的人，通常是高管。发起人可以帮助设定目标优先级、协调资源，甚至说服其他不支持项目的利益相关者。
部门经理/直线经理：各职能部门的负责人，他们管理着项目所需的人力资源，并关注项目如何影响其部门目标。例如，IT部门经理可能关注项目对现有系统的影响。
项目团队成员：参与项目执行的成员，本身也是利益相关者。他们关心自身任务分配和绩效评价，与项目成败也有直接关系。
其他受影响部门或个人：任何能够影响项目或受到项目影响的人。例如市场部可能不是直接参与项目，却因为项目产出需要他们后续推广，也是利益相关者的一种。

识别完“谁”是干系人后，我会进一步了解“他们有什么诉求”和“能带来什么影响”。为此，我常使用利益相关者登记表（或分析文档）来记录每个干系人的详细信息。这个登记表通常包括：干系人所属部门及职位、对项目的期望目标、关注的优先事项、对项目的利益点和潜在影响力等。通过登记表，我可以按干系人的利益和影响对他们分类，识别出哪些人对项目成败最关键。同时也记录他们将提供的支持或资源。这个过程让我清楚应该将主要精力放在哪些人身上，如何定制沟通策略。例如，对于高影响高利益的干系人，要高频沟通、重点满足需求；对于影响小的，则定期告知进展即可。总之，清晰识别并登记利益相关者的信息是项目沟通和管理的基础，它帮助我建立良好的关系网，平衡不同干系人的期望，促进项目顺利推进。

如何启动项目

在识别完主要干系人后，我会着手启动项目。项目启动阶段的一项关键工作是指定项目经理——也就是明确由谁来负责这个项目的推进。我在实际中体会到，尽早确定项目经理非常重要，因为后续很多决策和沟通都需要项目经理拍板。我通常会和领导确认我的职责权限，比如对资源的调配权等，确保在后续过程中有足够的授权开展工作。

项目初步定义也是启动阶段的任务之一。我会先弄清楚项目要解决的痛点或抓住的机会（这部分下一节详述），然后给项目下个简单的定义：这个项目打算做什么、不做什么，为什么做。这种初步定义通常体现在一个纲领性文件中，那就是项目章程。我理解项目章程就像项目的“立项说明书”，它概括了项目概况，并赋予项目正式启动的权力。根据课程内容和我查阅的资料，一个规范的项目章程通常包含：

项目目的和必要性：为什么要做这个项目，它要实现什么价值。比如“为了在不断增长的会议市场中重拾份额，提升会议中心竞争力”。
项目范围的初步描述：项目大概要做哪些事，包括的主要可交付成果和关键工作内容。
初步里程碑和时间表：大概的项目进度安排，如主要阶段的完成时间。
粗略的成本预算：预估项目所需投入的资金或资源规模。
主要项目利益相关者清单：列出项目的客户、发起人、核心团队等。
项目经理的任命和权限：正式确认项目经理人选，并说明其在项目中的授权范围。

项目章程通常由项目发起人起草或批准，一旦签署，就意味着项目被正式批准启动，项目经理也获得了“尚方宝剑”。在我看来，章程的作用有两个：一是统一大家对项目“大方向”的认识——让所有相关方都清楚项目要做什么、为何做；二是赋予项目经理正式权力——在组织内部为项目调配资源、进行跨部门沟通有了依据。启动项目时，我习惯召开一次启动会，向主要干系人介绍项目章程的内容。这相当于项目的开球仪式，让所有人对项目的愿景、目标和基本范围达成共识，也明确各自的角色和责任。之后，项目就算正式进入执行准备阶段了。

明确问题或机会

项目之所以存在，通常是为了解决一个问题或者抓住一个机会。老师在课上强调，正确定义项目要解决的根本问题非常关键，因为它会指导项目后续的每个决策。为此，我会先写一份问题陈述 (Problem Statement)。问题陈述要求我用简洁的一两句话清楚地说明：“我们面临的具体问题是什么，或我们想要利用的机会是什么” 。

撰写问题陈述听起来简单，其实暗藏门道。我一开始经常犯的错误是把解决方案当成问题。举个例子吧，以前在一个办公系统升级项目中，我们的陈述写成：“我们需要开发一个新系统来提升员工协作效率。”后来发现这其实是解决方案（开发新系统），而没有说清原始问题（现有协作效率低下的原因）。课程举了几个典型反例：“我们需要新建一栋大楼”“我们需要一个新网站”等等 ——这些都是直接跳到“要做什么解决方案”，而没有解释“为什么要做”。正确的做法是先追问背后的“为什么” 。我现在养成了习惯，当听到诸如“要上新系统”这样的表述时，就不停地问：“为什么要上？是想解决什么痛点？” 多问几个为什么，层层剥茧才能找出问题的根源。在刚才的例子中，我们继续问下去，可能会发现真正的问题是“现有协作平台功能落后，导致跨部门沟通效率低下”。于是，正确的问题陈述可以表述为：“目前公司的跨部门协作效率低，影响了项目交付速度，在竞争中处于劣势。”一句话道出症结所在，这就是一个好的问题陈述：简明、聚焦于现状痛点，不预含解决方案。

课上老师也提供了酒店会议中心的案例：附近出现了多家新建的商务酒店，自己的酒店客房入住率直线下降，会议室预订率降低，而整个城市的会议市场需求却在上升。据此，他们的问题陈述是：“我们在不断增长的会议设施市场中正在失去市场份额” 。这个陈述言简意赅地点出了问题——市场需求在涨，我们份额在跌。这为项目指明了要解决的核心问题。

我体会到，写问题陈述有两个注意事项：一是尽量简洁，能一句话说明白绝不用一段话；二是明确区分问题和方案，杜绝把想要的方案错当成了问题。如果实在拿不准，我就反复检查：“我写的这句到底是在描述现状困境，还是已经假定了解决办法？”只有聚焦于现状困境的表述才是问题陈述。最后，不要怕麻烦，多向相关干系人验证这个陈述是否准确。通过与客户和团队讨论，我常会对问题陈述做一些调整，让大家都认同“是的，这正是我们需要解决的问题”。当根本问题或机会说清楚了，我们就打下了一个良好的开端，之后制订目标、方案都会更加有针对性。

项目目的与目标

明确了问题后，接下来就是确定项目的目的和目标。起初我对这两个词有些混淆，觉得好像都是说“想达到什么”。后来明白，项目目的和项目目标既有区别又有关联，可以这么理解：

项目目的（Goal）：项目最终想实现的大方向、大效果，是对预期成果的高度概括。通常只用一两句话描述，不一定量化，但要指明一种期望的改善。例如，“提升会议中心的市场竞争力”或者“改善客户满意度”。项目目的回答的是“我们为何做这个项目、希望带来什么长期效益”。
项目目标（Objectives）：为实现目的而设定的一系列具体可衡量的指标或里程碑。目标是对目的的细化和补充。它明确了成功的判断标准，以及项目需要达到哪些具体成果。例如，“会议中心改造后客户满意度提升至80%以上”或“改造后一年内会议室预订率提高20%”。目标往往有多条，共同支撑最终的项目目的。

简单来说，目的指明方向，目标设定里程碑。我现在习惯先想清楚项目的目的是什么，然后列出几个主要目标去定义成功的具体含义。课程里提到，明确目标非常重要，因为它有助于确定项目范围、实施方案，以及日后评判成功与否的标准。

在制定项目目标时，我还了解到目标可以分成几种常见类型，每一类关注不同的绩效方面：

业务目标：支持公司战略或战术的目标。例如提升市场份额、提高品牌知名度、客户留存率等。这类目标体现项目对业务发展的贡献，如“会议中心年预订场次增加15%”。
财务目标：与金钱直接相关的目标。例如增加收入、降低成本、提高投资回报率等。比如“项目完成后年收入提高100万，ROI达到15% ”。
质量目标：对成果质量提出要求的目标。例如降低缺陷率、提高客户满意度等。如果项目目的是提高客户满意度，那么质量目标可以是“客户满意度评分提升到80%以上” 。
技术目标：涉及技术性能或技术选型的目标。例如采用新技术平台、提高系统性能参数等。会议中心项目里的技术目标是“使用最新一代计算机和视听设备” 。
绩效（进度）目标：对时间进度或性能指标的要求，很多时候是广义的“绩效”概念。例如“项目必须在明年旺季开始前完成改造” ，这就是一个进度方面的绩效目标。

列出这些目标后，我还需要确保目标本身定义得合理、清晰。这里就用到著名的SMART原则：Specific（具体明确）、Measurable（可衡量）、Achievable（可实现）、Relevant（相关性强）、Time-bound（有时限）。SMART原则是目标设定的黄金准则，我在实践中深有体会：

具体：目标要清晰不含糊，不能笼统模糊，否则团队会迷失方向。例如，不要说“提高客户满意度”，而要说“将客户满意度提升到80%以上” 。
可衡量：目标必须量化或有客观指标，这样才能判断是否达成。比如用调查问卷评分作为满意度指标，这样达到80%就是清楚的衡量标准。
可实现：目标应在可用资源和条件下能够实现。过于激进的目标会打击团队信心。目标可以有挑战性，但我会评估资源后确保它切合实际。
相关性：目标要与项目目的和组织战略密切相关。设定无关紧要的目标只会浪费资源。所以我会检查每个目标是否确实支撑了总体目的。
有时限：目标要有明确的截止日期或时间框架。有了时间约束，团队才知道努力的节奏。例如“在明年3月底前完成改造” 就是给目标加上了期限。

遵循SMART原则，我把项目目标写出来后，基本上就勾勒出了项目成功的图景。此时我还会回头看看这些目标和项目的初衷（问题陈述、项目目的）是否一致。课程中建议我们将目的和目标与公司使命和战略进行对照，确保项目确实能带来预期的业务价值。我觉得这是画龙点睛的一步：如果发现目标跟公司大方向不符，那项目可能要调整甚至喊停；如果吻合，那就更有信心推动下去。

最后，我通常会把项目目的和目标整理成书面的形式，与主要干系人再次沟通确认。这既让大家对项目成果有了统一期望，也为后续的范围定义、方案选择打下基础。项目目的和目标为项目提供了清晰的方向，有了它们，我们就知道这条路要通向哪里。在这个方向指引下，我们才能继续规划实现路径。

制定战略

当项目的目的和目标都明确后，我发现往往实现这些目标的路径不止一条。也就是说，可以有不同的方案或战略来完成项目。那么选哪种方案最好呢？第三课介绍了一个理性选择策略的方法，我也在工作中应用过，就是头脑风暴 + 决策矩阵的组合。

第一步，头脑风暴产生选项。我会召集一群对项目比较熟悉的小伙伴一起开头脑风暴会议，大家根据之前写好的问题陈述、目的和目标各抒己见，想出可能的实现战略。头脑风暴强调的是不设限制，尽量发散思维。我通常在会上说：“现在不用管可行性，也先不评价好坏，想到啥方案都可以提。”这样的氛围下，经常会蹦出一些有创意的想法。比如针对“提升会议中心竞争力”，可能有人提“升级所有设备”，有人提“主推高科技会议套餐”，还有人提“与大型会展合作打包促销”等等。重点是先罗列出尽可能多的想法，然后再逐一评估。

第二步，使用决策矩阵评估选项。在有了一堆备选战略后，就进入评估和筛选阶段。这里课程推荐使用“决策矩阵”，我尝试过，确实很有帮助。决策矩阵简而言之就是列出选项和评价标准的表格，通过打分来比较方案优劣。我们小组一般会针对每个方案提出几个关键提问，作为评估标准：

目标匹配度：这个战略在多大程度上满足项目设定的各项目标？这是最重要的衡量标准。快速淘汰方案的办法之一，就是看某方案能否满足所有必须达成的目标。如果有哪个关键目标此方案完全办不到，那我通常直接放弃这个方案，不再浪费精力深究它其它方面。这一步骤常常一下就刷掉了一些不靠谱的选项，留下的都是“有希望全面达标”的方案。
评分和权重：对于剩下的方案，我们会对照每一项目标打分，看它达到该目标的程度强弱。如果项目有多个目标，且重要性不同，我们还会给目标设定权重。比如“提高收入”可能比“提升知名度”更重要，那前者权重大一些。然后计算每个方案的综合得分，得分最高的自然就脱颖而出了。
可行性：除了看“想不想要”，还得看“能不能做到”。小组会问：“这个战略技术上、资源上可行吗？” 如果某方案需要采用从未检验的新技术或者严重依赖外部条件，那可行性就存疑。遇到这种情况，我会考虑做可行性研究（哪怕是小范围试验），以弄清方案行不行得通，以及大概要花多少时间和成本。可行性有疑问的方案往往伴随高风险，需要慎重对待。
风险评估：再牛的方案也可能暗藏风险。所以我们也初步分析：“方案实施过程中可能出现哪些重大风险？这些风险我们能接受吗？” 在项目早期不可能识别所有风险，但至少可以看看有没有显而易见的高危风险。如果某个方案潜在风险非常大，比如涉及政策不确定性或者供应链单点失败，那我会谨慎考虑是否放弃它。策略选择就像下棋，走一步看三步，不能只盯着眼前利益忽视长远隐患。
文化契合度：这一点常被忽略，但老师特别提到要问：“该战略是否符合公司的文化和现状？” 我深有同感。一个方案再完美，如果不符合组织文化，实施起来也会阻力重重。比如公司文化保守，却硬推激进颠覆式的变革方案，多半团队和管理层都难以接受，成功几率不大。所以方案一定要考虑执行环境，争取选择大家发自内心支持、愿意投入的路线。

通过上述多维度的评估，我们就能比较客观地找出最优战略了。通常综合评分最高、同时在可行性、风险和文化方面也过关的方案，就是值得推进的选择。在我的经验中，有时候决策矩阵的结果会支持两三个差不多的方案，这时候可能需要进一步讨论，或者结合领导偏好、资源机会来拍板。但不管怎样，这个过程可以保证我们考虑周全，而不是拍脑门决定。

当最终方案选定后，我感觉项目一下进入了一个新阶段。此时，我们就对“要做什么”和“怎么做”有了一个清晰的蓝图。接下来很多细节（例如分解具体任务、安排资源等）都会以此为基础逐步展开。课程中建议我们把这个决策矩阵工具应用到自己的项目中去评估战略，我已经实践过，效果不错。未来我会继续用这种理性的方式来制定项目战略，毕竟前期把路选对了，后面走起来才会轻松顺利。

如何发现需求

有了明确的战略后，下一步我通常会深入到需求层面。课程强调：“项目的目的、目标和解决方案告诉了我们要完成什么，以及大致怎么做，而需求则进一步详述了最终交付成果需要实现的具体功能和条件” 。通俗来说，需求（Requirements）就是项目需满足的详细用户需求或业务需求清单，它回答的是“项目交付物具体应该是什么样子”。这一部分工作非常关键，因为如果需求没搞对，最终成果很可能无法让利益相关者满意；反之，如果加了一堆不必要的需求，就会无端增加项目时间和成本。

为了更好地理解，我会将目标和需求的关系举个例子来说明：在会议中心升级项目中，有一个目标是“使用最新型的计算机和视听设备来提升会议体验” 。围绕这个目标，我们可以进一步明确出几个具体需求，比如：“在所有会议展示厅安装超高清（4K）显示屏” ，“在整个酒店及会议区域提供高速802.11n无线网络覆盖” 。这些需求就比目标更具体、更具可操作性：它们规定了具体要交付什么。目标只是说要用最新技术设备，需求则细化为“什么设备、多高级别”。当然，我们还可以把需求写得更详细，比如“每个展示厅配备不小于100寸的4K显示屏，支持HDMI和无线投屏”等等。这就是需求定义在向下展开细化。

我在工作中发现，获取正确的需求往往充满挑战，常见的难点包括：

干系人表达不准确：用户或客户有时说不清楚自己到底想要什么，或者用模糊的语言描述需求。甚至不同干系人各说各话，给出不一致甚至矛盾的需求。这种情况下需要我们去梳理、澄清。
遗漏需求：有些关键需求可能没人提及，可能因为想当然地以为不必说，或者干脆忘了。这些遗漏如果不及时发现，后期会变成大问题。
超出范围的需求：也叫“需求蔓延”或“愿望清单”。有时干系人会提出一些nice-to-have的想法，其实并非项目成败所必需。如果统统接受，项目范围就不受控地扩大了。
非干系人插入需求：有趣的是，现实中常会碰到不是这个项目利益相关者的人，硬要往项目里加需求的情况。比如别的部门听说你这项目不错，也想搭车实现他们的某个想法。对此我现在会非常谨慎，确保每条需求都对应真实的项目干系人和项目目标。
干系人不愿配合：最后一个难点是，一些干系人（尤其高层或客户）可能不愿投入时间来深入讨论需求。他们可能觉得“我提了要做X就行了，细节你们看着办吧”。这种情况下，需求搜集更需要我们主动引导。

面对这些挑战，我一般分三个步骤来“发现需求”：

第一步：收集需求信息。这一步就是想方设法把需求挖掘出来。课上介绍了几种常见的方法，我结合自身经验，总结如下几种有效的需求获取手段：

访谈：这是我最常用的方法之一。找到合适的干系人一对一深度访谈，听取他们对需求的看法。关键在于找对人、问对问题。我会事先列出一套问题清单，确保覆盖各方面。通过访谈，可以获得很多一手信息和隐含需求。
研讨会/头脑风暴会：如果项目涉及多个部门或用户群，我喜欢组织跨部门的需求研讨会。把各方代表召集起来开会讨论需求，这种集中讨论不仅能碰撞出更多需求，还能让各部门对项目更有认同感。比如在会议中心项目里，我可能让IT部、运营部、市场部的人坐在一起，各自提他们认为需要的功能。大家边提边讨论，有分歧的当场对质，往往能明确哪些需求是共识，哪些存争议。
观察：有时候干系人自己说不清需求，这时我会采用“实地观察”的方法。亲自去看用户是如何工作、如何使用现有系统，从他们日常行为中发现痛点。例如，观察酒店会议销售人员接单流程，也许能发现一些系统改进需求。这种方法特别适合理清业务流程类的需求。
问卷调查：当干系人众多、分散时，可以用问卷或在线调查来收集需求。设计问卷要非常仔细，问题措辞要客观中立，避免引导或暗示答案。比如“您觉得现有会议设备哪里需要改进？”就比“您是不是觉得需要更好的投影仪？”更开放中立。问卷能一次获取很多人意见，但深度不如访谈，需要后续跟进。
文件研究：如果有历史的文档或已有产品，我也会进行文档分析或逆向工程。比如查阅之前类似项目的报告，或者分析现有系统的功能清单，可能会揭示出需求线索。这种方法可以作为其他手段的补充，提供背景信息。

第二步：分析和澄清需求。当第一轮收集到一堆需求后，工作还远没完——其实才刚开始。接下来我会对原始需求进行整理和分析。首先检查有没有不合理或缺失的地方：有时候干系人提的需求可能前后矛盾，或者讲得含糊不清，需要澄清。我会把这些疑点标出来，再去一一追问。还有些需求之间可能有重复，或者属于同一类，我会进行合并归类。分析的过程通常是反复迭代的——往返沟通几次才能把问题说透。课程里提示我们可能需要经过几轮才能真正弄清项目的真实需求。这在我经验中太常见了：每当我以为搞定了，拿给用户确认，他们又会想起新的点子或者否定之前的想法。所以要有耐心，通过多轮问答和验证，逐渐把需求雕琢得一致、无遗漏。

第三步：记录和确认需求。当感觉需求信息已经相对稳定、合理，我就会开始编写需求文档。记录需求时，我遵循几个原则：一是用清晰、无歧义的语言描述。尽量避免行话和模棱两可的词，确保不同的人读起来理解相同。二是结构化分类：把需求按类别整理，比如功能需求、性能需求、界面需求、培训需求等。这有助于检查是否有遗漏，也方便日后查找。三是对每条需求最好指明来源（是谁提的）和优先级，以便后续权衡取舍。需求文档初稿写好后，我一定会请主要干系人过目，进行确认（sign-off）。只有大家一致点头说“是的，我们需要的就是这些”，项目才算真正有了明确的蓝图。后续设计、开发、测试都将严格对照这些需求来进行。

总的来说，需求阶段是项目计划中最磨人的环节之一，但也是决定项目成败的基础。我在实践中越来越体会到，花时间把需求搞清楚是值得的：与其等项目后期发现偏离了客户期待，不如一开始就把事情问明白、想清楚。毕竟项目最终要交付的东西，都是在需求里事先写明了的。只有当需求扎实明确，项目团队才能对准正确的靶子努力，不会做了很多“无用功”或者错事重做。

明确可交付成果与成功标准

项目搞清楚要交付什么和如何评判成功，对我而言是一件安心的事。课程第三课谈到了可交付成果（Deliverables）和成功标准（Success Criteria），我觉得这个概念很实用。我理解可交付成果就是项目应当交付的具体结果，可以是有形的产品，也可以是无形的成果。例如一栋新楼、一款软件、一次培训服务，甚至“销售额提高15%”这种业务指标，也可以视为一种成果。而成功标准则是用来衡量可交付成果是否达到预期的方法或指标 ——换句话说，就是对“成功”的定义。

在第三课中，讲师强调了几点让我印象深刻：

明确最终和中间可交付成果：我现在列计划时，喜欢先写下项目的最终可交付成果是什么，也就是项目结束时要交出什么。然后，再列出中间可交付成果。中间可交付成果是项目过程中交付的阶段性成果，用于逐步迈向最终成果。例如，在会议中心升级项目中，最终交付成果可能是“完成焕然一新的高科技会议中心”；而中间交付成果可以有很多，比如“完成设备需求清单”“签署施工承包合同”“完成设备安装调试”等。区分这两者的意义在于：最终成果直接对应项目目标，中间成果则帮助衡量项目进度。通过定义中间成果，我可以在每次状态报告时，根据完成了哪些可交付成果来评估项目进展。如果我们不设置这些里程碑交付件，项目可能过了好几个月都看不到明显产出，大家会对进度没概念。适当拆解大的交付物，用工作分解结构（WBS）的方法把它们分成小块，可以更好地管理和跟踪。
范围说明：有趣的是，可交付成果和项目范围还有紧密联系。项目范围其实由要交付的内容决定——包括什么，不包括什么。当我明确了要交付哪些成果，自然而然就确定了范围边界。在编写范围陈述（下一节详细谈）时，就需要列出项目要交付的成果以及不交付的事项。所以搞清交付物清单，有助于防止项目范围蔓延。
客户未必关心中间成果：这里课程里提示说，中间可交付成果不一定要直接交给客户。这点我理解，比如“内部测试报告”可能是我们项目团队的中间成果，但客户最终只看正式发布的软件。因此，中间成果更多是团队内部用于过程管理的，不用每项都向客户交付或解释。不过在阶段评审会上，我还是会和客户沟通我们完成了哪些里程碑成果，以增强信心。
设定可衡量的成功标准：这是重中之重。写下交付清单后，更关键的是如何判断“我们交付的是不是客户真正想要的？” 这里就需要给每个交付成果定义验收/成功标准。成功标准往往是量化的，越具体越好，比如“一栋新建成的大楼要通过政府验收取得使用许可证”就是很明确的标准；或者“开发的软件通过了所有用户验收测试，用例通过率95%以上” 。对一些抽象的成果也可以想办法量化标准，比如课程举例：目标是“提高客户满意度”，那成功标准可以定义为“在特定旅游网站和客户调查中评分达到4星或以上（满分5星）” 。这个标准清晰描述了达到满意度提升的衡量方法。成功标准=成功的定义，有了它，我们在项目结束时就能客观评估交付成果是不是达标了。
确保标准清晰可量化：有些成功标准容易确定，比如“签署了供应商合同”或“取得了建筑完工证书”这种一看就知道是否完成的。但也有一些标准比较主观、不易衡量，这时就要想办法转化为量化指标。否则团队和客户可能对是否达成有不同解读，日后容易扯皮。我个人现在喜欢在项目早期就和客户确认验收标准，把模糊要求尽量具体数字化。这和SMART原则一脉相承：可衡量才能可管理。

为清晰起见，我常把可交付成果及成功标准整理成一个表格或清单。例如：

最终交付成果：改造后的会议中心全面投入运营

成功标准：通过全部设备验收和安全检查；实际客户满意度评分≥4/5 ；首月会议室预订率同比提升X%（等等）。
中间交付成果1：完成方案设计并获得管理层批准

成功标准：方案评审会议纪要记录高层签字批准。
中间交付成果2：与建筑公司签署施工合同

成功标准：合同盖章生效，施工方进场准备。
…（其他中间成果略）

通过这样的清单，我对整个项目要交付的东西和衡量标准一目了然。这也方便和干系人沟通他们关心的结果。可交付成果清单告诉我们项目应该交付哪些结果，成功标准则帮助判断这些结果是否达到了我们想要的品质。在执行过程中，我们就按这个清单逐项去实现、去验收。每完成一个交付物，就意味着项目向成功又迈进一步。可以说，明确交付物和标准就像给项目制定了“完赛条件”，而我的任务就是带领团队逐一满足这些条件。

明确假设与风险

在项目规划阶段，我还会特别注意列出项目的假设和风险。起初我对这部分不太重视，觉得有些“想太多”。后来踩过坑才意识到：假设和风险如果不提前说清，日后可能给项目带来大麻烦。第三课中讲到，项目成功的关键因素之一就是尽早明确项目的假设和风险。听完后我马上应用到自己的项目中，效果很好。

假设（Assumptions）可以理解为那些我们暂时认为为真的前提。因为项目在启动时很多情况还不确定，我们往往会假定一些条件来进行规划。例如假设“关键技术人员一直可用”“供应商能按期交货”“市场环境保持稳定”等。然而，假设毕竟只是主观认定，未被确认就拿来当基础，如果将来事实并非如此，那项目就会受到影响。举个例子：我们假设“设备供应商负责布线安装”，结果对方以为“布线应该由我们内部IT部门做” 。双方各怀假设，最后可能导致布线没人做，墙都封起来才发现出纰漏。类似情况在现实中不少见。因此，我学到的教训是：一定要把各方的隐性假设显性化。很多时候人们自己都没意识到他们在假定什么，所以需要项目经理像侦探一样不停问问题，把那些“没说出口的假设”挖出来。我在讨论会上会反复确认：“这个任务到底是谁负责？”“你预期某某会做好哪件事，对吗？”不怕啰嗦，多问几次，直到确认所有人认知一致。只有把假设亮出来公开讨论，我们才能避免日后互相埋怨“我以为你会做”“我以为不用做”之类的问题。

风险（Risks）则是项目中可能发生的不确定事件，分为威胁（负面影响）和机会（正面影响）两类，不过多数时候我们更关注负面风险。风险的特点在于不确定：也许会发生也许不会，但一旦发生就会影响项目目标。所以识别风险就是在给项目做“未卜先知”的功课。我以前总嫌在项目前期讨论各种风险太悲观，后来发现及早识别风险有两个好处：一是可以帮助管理层决策。如果一开始就发现项目存在许多重大风险点，让高层知道项目成功概率不高，也许干脆就不投这个项目了。与其中途失败，不如一开始慎重。二是对于继续进行的项目，我们提前知道了风险，就能制定应对预案或加入缓冲，提高项目抗风险能力。课程建议我们在项目早期花点时间明确可能影响项目的风险，这一点我强烈认同。尤其是那种毁灭性风险，比如政策变化、资金断裂之类，如果前期识别到了，可以在章程决策时就提出，引导高层考虑是否要上马这个项目。

在实践中，我通常会在项目章程或范围说明书里，加一个章节列出关键假设和风险。具体做法是：

头脑风暴假设清单：和团队一起回顾项目计划，想想有哪些我们理所当然认为是真的东西，其实值得打个问号。把这些都列出来作为假设条件。然后我会努力验证这些假设是否成立，比如给相关方发邮件确认责任归属等。如果不能立即验证，那至少在文件中注明“假设A：假设XX负责YY任务”之类，让大家都知道这里有个前提。
识别主要风险：用SWOT分析或者直接问团队“最担心什么”，列出风险项。我会描述风险事件、可能造成的影响，评估一下发生概率和冲击大小。然后重要的风险会制定初步的应对策略，比如规避、缓解、应急计划等。对那些概率极低或者影响很小的琐碎风险，我们记录在案即可，不用花太多精力。
公开讨论并获取共识：假设和风险列表我都会拿到项目启动会上分享，或者通过邮件发给干系人，请大家知情并补充。这个举动有两方面好处：一是万一遗漏了什么，别人可以提醒补充；二是让所有人有心理准备，知道项目有哪些前提和坑，避免日后出了问题相互指责“没人告诉我”。课程中说“只要能预先明确，假设和风险都属于可管理范畴” 。深以为然——曝光在阳光下的风险就不可怕，怕只怕那些埋伏在暗处我们没意识到的。

在课程练习中，老师让我们记录自己项目的假设和风险。当我动手去列的时候，才意识到每个项目真的都有不少假设和风险，以前很多都疏忽掉了。现在把它们写出来管理后，项目的不确定性反而降低了。我也养成一个习惯：定期监控这些假设和风险。假设有的后来被证实不成立了，那就赶紧调整计划；风险如果临近发生就触发应对措施。通过不断跟踪，我们可以确保假设和风险始终在掌控范围内。

总之，假设和风险管理让我对项目的底牌更心中有数。明确假设可以防止沟通误区，明确风险可以未雨绸缪。虽然我们无法消除所有不确定性，但至少可以提前想到并做好准备。说到底，项目管理很大程度上就是管理不确定性，而假设与风险就是不确定性的两种体现形式。把它们处理好，项目成功的几率也就大大提高了。

编写范围陈述

在完成了上述步骤（干系人、目标、需求、可交付成果、假设和风险）之后，最后要做的一件重要工作是编写项目范围陈述。项目范围陈述（Project Scope Statement）是一个用来清晰描述项目边界的文档：说明项目包含哪些工作内容，不包含哪些内容。可以说它划定了项目的领地，告诉团队和干系人“我们的责任到此为止，超过这个界限就不归我们管”。我个人觉得范围陈述对控制项目边界、防止范围蔓延有极大的作用。

编写范围陈述时，我通常提炼前面已经明确的信息：

包含的范围：根据之前确定的需求和可交付成果，我会在范围陈述里列出项目团队将要完成的主要工作和产出。这部分可以看作项目的“包括项”。例如，对于会议中心升级项目，范围陈述可能写：“本项目包括会议室多媒体设备升级、网络基础设施升级、会议预订系统软件更新、相关员工培训”等等。这些都是团队需要做的事，属于项目范围之内。
排除的范围：这一项很关键，也常被忽略。范围陈述里我一定会写明不在本项目范围内的事项。为什么要强调不做什么呢？因为有些事情乍一看好像相关，但实际上并不包含在本项目里，提前说清可以避免日后产生误解和额外要求。课程举的例子是酒店会议中心升级项目中，酒店客房家具升级不在范围内，因为客房家具几年前刚更新过，不在此次技术改造项目里。又比如，“本项目不负责改造完成后的市场宣传推广，那将由市场部另立项目负责” 。像这样，把边界以外的内容明确列出来。我自己的经验是，排除项最好针对那些容易被认为应该做但我们其实不做的工作，或者可能在界限处模糊的事项。例如，实施新软件系统项目中，可能要声明“不包括旧数据的历史清洗”之类。不写出来，别人可能以为你会做。
范围描述：有时我还会在范围陈述开头用一两句话概括项目的整体范围，等于是给包含项和排除项做个总结。比如：“本项目旨在改造提升会议中心的硬件和软件设施，以提供更好的客户体验。项目聚焦于技术升级，不涉及土建扩建和市场运营活动。” 这样的描述读起来一目了然。

在写范围陈述时，我发现一个好方法是对照先前列出的假设再过一遍。看看有无新的范围内或范围外内容需要补充。比如我们假设家具可以兼容新技术，那么家具更新就明确排除在范围外；假设市场宣传另做打算，那我们就把市场宣传列为范围外。通过核对假设，我可以确保范围陈述没有遗漏关键点。

完成初稿后，我会请主要干系人（客户、发起人等）审阅确认范围陈述。这就像画了一条大家都能看见的“楚河汉界”，确认过后谁也不能轻易越界。如果后续有人提出新需求或任务，我就可以拿出范围陈述来对照：“这个在我们的排除列表里呢，如果一定要做，就意味着范围变更，我们需要启动变更流程。” 这让需求和范围的讨论有据可依，而不会演变成无原则地增减工作。

项目范围陈述实际上定义了项目的边界。有了清晰边界，我们才能判断项目有没有跑题，是不是做多了或做少了。每当项目进行中发生争议时，我都会回到范围陈述，看事情是否在当初约定的范围之内。如果不在，那就按变更流程处理，而不会稀里糊涂把所有要求都接下来。可以说，范围陈述既保护了团队防止过度承诺，也确保了客户得到该得的成果，不会少交付东西。它是项目计划阶段非常重要的基准文件。

总之，在项目规划启动的过程中，编写范围陈述是最后把所有信息收拢成一个清晰定义的步骤。我通常在完成它之后，感觉项目的“框架”已经扎实搭好——干系人清单、目标、需求、可交付成果、成功标准、假设、风险、范围边界，这些内容相互关联，形成一个整体的项目蓝图。拿着这份蓝图去汇报、沟通，别人很快就明白我们项目要做什么、不做什么了。作为项目经理，我也心里有数，接下来可以带领团队按图施工。回顾第三课所学，这一系列步骤让我认识到：只有前期规划想清楚、说清楚，项目后期执行才能少走弯路。