文/荆泽峰
|
文/荆泽峰 说明：本案例为某外资咨询公司为国内某行业的隐形冠军企业编制的公司级项目的项目管理手册。该手册共分分为十四个章节，分别是1-概述、2-项目组织、3-项目管理流程、4-项目整合管理、5-项目范围管理、6-项目时间管理、7-项目成本管理、8-项目质量管理、9-项目人力资源管理、10-项目沟通管理、11-项目风险管理、12-项目采购管理、13-项目管理模板清单、14-手册附录。 项目范围管理 项目范围管理包括确保项目做且只做成功完成项目所需的全部工作的各活动。管理项目范围主要在于定义和控制哪些工作应包括在项目内，哪些不应包括在项目内。 项目范围管理主要包括以下这些活动： - 定义目标与范围 - 选择项目解决方案 - 定义项目关键里程碑 - 确认目标与范围 - 细化项目解决方案 - 确认完工标准 - 创建工作分解结构 - 核实范围 - 控制范围 这些范围管理活动不仅彼此相互作用，而且还与其他项目管理领域中的活动相互作用。每个活动在每个项目中至少进行一次，并可在项目的一个或多个阶段（如果项目被划分为多个阶段）中进行。虽然在本章中，各活动以界限线分明、相互独立的形式出现，但在实践中它们可能相互交叠、相互作用。 5.1 定义目标与范围 依据公司战略与公司级项目群实施路线图，同时以项目解决方案为重要输入，进一步清晰定义项目目标与项目范围的活动。 公司级项目群项目规划是以公司战略为主要输入，并以支持公司战略实施为目的。在项目策划阶段，定义了初步的项目目标与项目范围，在策划阶段中需要进一步清晰化项目目标与项目范围。项目目标与项目范围和项目解决方案互为输入输出，项目解决方案的制定，也是项目目标与范围清晰化的重要输入。 所属流程：项目策划流程 5.1.1 输入 - 公司战略 - 公司级项目群实施路线图 - 项目解决方案（见5.2 选择项目解决方案）：项目目标与项目范围的定义与项目解决方案的选择互为补充。项目目标和范围的初步定义指导项目方案的选择，在项目方案选定后，再对项目范围进行重新修订。 - 关键干系人列表（见10.3 分析项目干系人） 5.1.2 工具与技术 - 专家判断：项目经理组织项目关键干系人及项目主题专家对项目目标及范围进行进一步清晰化。成为项目组下一步行动的指导。 - 访谈：依据公司级管理项目群实施路线图中定义的基本项目目标与项目范围，访谈项目发起人或关键干系人，进一步明确项目目标与项目范围。访谈是一种通过与干系人直接交谈来获得信息的正式或非正式方法。访谈有经验的项目参与者、干系人和主题专家，有助于识别和定义项目交付成果的特征和功能。 - 研讨会：把项目规划过程中的项目干系人和主题专家集中在一起，了解他们对项目的期望和态度。 5.1.3 输出 - 项目目标与项目范围：项目范围是定义哪些工作在项目内，哪些工作不应包括在项目内。详细描述项目的交付成果，以及为交付这些成果需要开展的工作。例如：项目的实施部门、涉及的流程模块等。当项目团队认为无法清晰定义什么工作应该包括在项目范围内时，可以先定义什么工作不包括在项目内。关于项目目标与项目范围需要项目关键干系人达成共识。 5.1.4 相关模板 - 访谈提纲 - 访谈纪要 - 项目启动申请 5.1.5 注意事项 - 暂无 5.2 选择项目解决方案 选择项目方案是依据项目的目标与范围，寻找相应解决方案进行对标，并从中进行选择的活动。 当项目解决方案在公司内部无法找到，或者公司内部不具备提供可选项目解决方案的能力时，需要启动项目采购来引进外部资源参与选择过程。 所属流程：项目策划流程 5.2.1 输入 - 项目目标与项目范围（见5.1 定义目标与范围） - 项目可选解决方案（见5.2选择项目解决方案）：公司通过自己研讨或外部咨询，选定项目可选解决方案。 5.2.2 工具与技术 - 专家判断：专家判断通常来自具有专门知识和经验或经过专门培训的任何个人或团队，可从多种渠道获得专家的意见和建议，其中包括：公司内部专家、外部顾问、项目干系人、主题专家、项目管理办公室（PMO）、专业与技术协会等。在内部团队不具备提供项目解决方案的情况下，启动项目采购流程，引进外部专家提供可选解决方案。 - 研讨会：召集项目关键干系人及主题专家（内部或外部）围绕项目目标与项目范围研讨项目的可行性可选方案，并作出决定。 - 项目管理知识库：从中参考类似项目解决方案或者解决方案提供方信息，为选择项目可选解决方案的参考来源。 5.2.3 输出 - 项目解决方案 5.2.4 相关模板 - 项目启动申请 5.2.5 注意事项 - 在保证项目目标达成的情况下，选择项目方案时需要考虑公司资源、能力的匹配，项目风险及应对措施。 5.3 定义项目关键里程碑 依据项目目标与范围、项目解决方案，将项目划分为阶段，定义项目关键节点的活动。 为有效完成某些重要的交付成果，而在需要特别控制的位置将项目分界，就形成项目阶段。在项目阶段结束时，需要对项目阶段进行评估，对相应的交付成果进行阶段验收。这个节点就是项目里程碑。里程碑的定义主要是为了项目管控和阶段项目交付验收制定的。项目阶段大部分是按顺序完成的，但在某些情况下也可以重叠。项目阶段不同于项目管理流程（项目策划、项目启动、项目计划、项目执行与监控、项目结束）。采用项目阶段结构，把项目划分为合乎逻辑的子集，有助于项目的管理、计划和控制。阶段划分的数量和必要性以及每个阶段所需的控制程度，取决于项目的规模、复杂程度和潜在影响。 每个阶段的启动经常需要由管理层来审查和决定。每个阶段的起点也是一个重新验证先前的假设和评估风险的机会，并可借机进一步明确为实现阶段性交付成果所需的过程。项目阶段终止或正式收尾时，通常要对交付成果进行审查，以决定其完整性和可接受性。 所属流程：项目策划流程 5.3.1 输入 - 项目目标与项目范围（见5.1 定义目标与范围） - 项目解决方案（见5.2 选择项目解决方案） - 项目管理知识库：参考以往项目划分项目阶段、确定关键里程碑的方法。 5.3.2 工具与技术 - 专家判断：项目经理或者项目管理团队依据项目目标和项目解决方案，决定项目管控重点，参考以往项目的管控点，进行项目关键里程碑定义。 - 研讨会：项目经理组织项目关键干系人或主题专家依据项目解决方案及参考以往项目案例，对项目关键里程碑进行定义。 5.3.3 输出 - 项目关键里程碑：依据项目管控需求及项目交付划分项目阶段，确立关键项目节点。项目关键里程碑是关键阶段交付结果验收的节点。 5.3.4 相关模板 - 项目启动申请 5.3.5 注意事项 - 对公司级管理类项目来说，项目里程碑之间的时间间隔最好控制在3-4个月以内，把项目风险尽量在控制在可更正的时间范围内。 5.4 确认目标与范围 确认目标与范围是指项目正式启动时，与项目关键干系人、核心团队共同确认项目目标与范围的活动。 由于公司级项目在策划工作完成后项目经理要协同项目管理办公室（PMO）进行项目准备度检查，项目管理办公室（PMO）与项目管理委员会对项目策划工作的结果给予反馈，包括对项目的目标与范围方面的反馈意见。因此在项目启动流程中，需要参考项目准备度检查的结果对项目目标与范围进行确认，并考虑是否需要进行调整或细化。更重要的是，在关键干系人与项目核心团队中，就项目目标与范围达成一致的理解和认识。 所属流程：项目启动流程 5.4.1 输入 - 项目目标与项目范围（见5.1 定义项目目标与范围） - 项目解决方案（见5.2 选择项目解决方案） - 项目准备度检查表（见4.1 检查项目准备度）：参考项目目标与范围相关的检查和评估意见。 5.4.2 工具与技术 - 内部会议：由项目经理召集项目核心团队及关键干系人确认项目的目标和范围，并将会议确认的结果形成书面记录。此会议可以与项目解决方案的内部确认会议一并召开。 5.4.3 输出 - 项目目标与项目范围（确认） 5.4.4 相关模板 - 项目章程 5.4.5 注意事项 - 暂无 5.5 确认项目解决方案 确认项目解决方案是指根据确认的项目目标与范围，与项目关键干系人、核心团队共同确认项目解决方案、并细化解决方案的活动。 可参考在项目准备度检查中项目管理办公室（PMO）与项目管理委员会对项目解决方案方面的反馈意见，与关键干系人和核心团队就解决方案达成共识，并且由项目经理带领核心团队完成项目解决方案的细化，作为确认完工标准的重要输入。 所属流程：项目启动流程 5.5.1 输入 - 项目目标与项目范围（见5.1 定义项目目标与范围） - 项目解决方案（见5.2 选择项目解决方案） - 项目准备度检查表（见4.1 检查项目准备度）：参考项目解决方案相关的检查和评估意见。 5.5.2 工具与技术 - 内部会议：由项目经理召集项目核心团队及关键干系人确认项目解决方案，并将会议确认的结果形成书面记录。此会议可以与项目目标与范围的内部确认会议一并召开。 5.5.3 输出 - 项目解决方案（确认） 5.5.4 相关模板 - 项目章程 5.5.5 注意事项 - 暂无 5.6 确认完工标准 确认项目完工标准是项目在启动阶段，对交付成果进行验收标准定义的活动。 完工标准是针对每一个交付成果定义的。完工标准是项目范围的重要组成部分，是管理项目干系人期望的基准，在公司级项目的管理中尤为重要，需要在项目启动时与关键干系人进行沟通并达成共识，成为项目章程的重要组成部分。项目经理要与核心团队一起，就规定的完工标准是否符合项目目标与范围、项目解决方案进行确认。 在涉及外部咨询方时，这部分内容往往会以合同的形式明确规定。 所属流程：项目启动流程 5.6.1 输入 - 项目目标与项目范围（确认）（见5.1 定义项目目标与范围） - 项目解决方案（确认）（见5.2 选择项目解决方案） 5.6.2 工具与技术 - 内部会议：由项目经理召集项目核心团队及关键干系人确认项目完工标准，将会议确认的结果形成书面记录，并记入项目章程。 5.6.3 输出 - 项目完工标准：项目章程必须包括项目完工标准。 5.6.4 相关模板 - 项目章程 5.6.5 注意事项 - 项目完工标准：除了包括最后交付外，各里程碑的阶段交付也属于完工标准。 - 在确认完工标准时要涵盖的内容包括：项目范围规定的事项是否已经完成、已经完成的事项是否满足发起人的要求、完工标准确认的方式和形式。 5.7 创建工作分解结构（WBS） 创建工作分解结构（WBS）是把项目交付成果和项目工作分解成更小的、更易于管理的组成部分的活动。 工作分解结构以项目交付成果为导向，进行工作层级的逐层分解，其分解的对象是项目团队为实现项目目标而实施的工作，包括项目管理所需的工作。工作分解结构是对项目范围基准的细化。工作分解结构每下降一个层级就意味着对项目工作更详尽的定义。不同的交付成果可以分解到不同的层次，某些交付成果只需分解一层，而另一些则需分解更多层。工作分解得越细致，对工作的计划和管理就越有力，但要注意过细的分解会造成管理工作的浪费和效率低下。在创建工作分解结构时，一定要注意分解细致程度的把握。 一般在项目计划之初进行的工作结构分解相对高阶，随着对项目情况的深入掌握和具体实施工作的推进，需要对工作分解结构进行相应的细化、调整和完善。工作分解结构一般采用列表或组织结构图的方式呈现。 所属流程：项目计划流程。 5.7.1 输入 - 项目目标与项目范围（确认）（见5.1 定义项目目标与范围） - 项目解决方案（确认）（见5.2 选择项目解决方案） - 项目管理知识库：参考类似项目的工作分解结构的分解方法和层级定义。 5.7.2 工具与技术 - 分解：分解就是把项目交付成果划分为更小的、更便于管理的组成部分，直到工作和交付成果被定义到工作包的层次。工作包是工作分解结构的底层，是能够相对准确地估算和管理工作所需时间和资源的单位。工作包的详细程度因项目大小与复杂程度而异。要把整个项目工作分解成工作包，一般需开展下列活动：
- 滚动式计划：在项目计划的初期可能无法分解要在远期才交付的工作，对于项目管理团队，通常要等到这些交付成果的信息足够明确和充分后，才能进行进一步的拆解，这种将计划逐步明细的做法就是滚动式计划。 5.7.3 输出 - 工作分解结构：以项目交付成果为导向的工作层级分解，包括工作层级编号、工作名称、负责的人员或组织、里程碑、所需的资源等。 5.7.4 相关模板 - 工作分解结构 5.7.5 注意事项 - 工作分解结构所分解出的工作包应涵盖所有内容，但每个工作包又彼此独立。 5.8 核实范围 核实范围是确认项目已完成的交付成果符合项目范围的活动。 范围核实与质量控制的不同之处在于，范围核实主要关注对交付成果范围的确认，而质量控制则主要关注交付成果是否正确以及是否满足质量要求。质量控制通常先于范围核实进行，但二者也可同时进行。核实范围是每一个项目交付成果完成后必须进行的确认过程，核实范围不仅限于项目组内部，也要通过与关键干系人的沟通进行范围的核实。 所属流程：项目执行与监控流程。 5.8.1 输入 - 项目管理计划（见4.3 制定项目整合管理计划） - 完工标准（见5.6 确认完工标准） - 交付成果（见4.4 管理与监控项目工作） 5.8.2 工具与技术 - 检查：开展测量、审查与核实等活动，来判断交付成果是否符合项目管理计划和完工标准中规定的要求。 5.8.3 输出 - 确认的交付成果（范围） - 变更请求：如在检查过程中发现项目交付成果与计划和完工标准有偏差，需要以变更请求的形式提出。 5.8.4 相关模板 - 变更请求 5.8.5 注意事项 - 范围核实侧重于结果，范围控制侧重于过程，因此，变更申请在范围控制环节提出优于在范围核实环节提出。 5.9 控制范围 控制范围是监督项目范围状态、管理范围基准变更的活动。 对项目范围进行控制旨在确保所有提出的变更、建议的纠正措施和预防措施都经过项目整体变更控制流程的处理。在项目实施过程中，变更不可避免，因此必须高度关注项目范围控制，控制范围一般都要与其他控制过程整合，一起发挥作用。 所属流程：项目执行与监控流程。 5.9.1 输入 - 项目管理计划（见4.3 制定项目整合管理计划）：参照项目范围基准。 - 工作分解结构（见5.7 创建工作分解结构） - 工作绩效信息：关于项目交付成果当前进展状态的信息。 5.9.2 工具与技术 - 偏差分析：以项目范围基准为依据，评估实施过程中项目范围与基准的偏差，分析偏差产生的原因，并决定是否需要采取纠正措施或预防措施。 - 项目例会：以定期的项目内部会议形式，向项目干系人和项目团队汇报项目绩效报告，讨论项目范围出现的偏差、分析原因、提出应对措施。 5.9.3 输出 - 工作绩效结果：对项目交付成果的当前状态与范围基准进行比较的结果，这些信息需要记录下来并传递给项目干系人。 - 变更请求：通过范围偏差分析，可能会提出对范围基准或其他项目管理计划的变更请求，变更请求应包括变更的内容及相应的预防措施和纠正措施，变更请求需要经过实施整体变更控制流程处理。 - 项目管理计划（更新）：
5.9.4 相关模板 - 项目绩效报告 5.9.5 注意事项 - 项目例会的最小频率为一周一次，应视项目的周期、项目解决方案的复杂程度、干系人的支持度等具体情况而定。
|
|
|
来自： 蓝海思享汇 > 《项目管理手册（特刊）》
