(1) 概念模型；
(2) 逻辑模型；
(3) 物理模型。(1) 数据需求分析；
(2) 概念模型设计；
(3) 逻辑模型设计；
(4) 物理模型设计。(1) 数据建模；
(2) 数据标准化；
(3) 数据运维；
(4) 数据开发利用；
(5) 数据安全。(1) 元数据标准化；
(2) 数据元标准化；
(3) 数据模式标准化；
(4) 数据分类与编码标准化；
(5) 数据标准化管理。数据元是数据库、文件和数据交换的基本数据单元。(1) 描述；
(2) 界定业务范围；
(3) 开展业务流程分析与信息建模；
(4) 借助于信息模型，提取数据元，并按照一定的规则规范其属性；
(5) 对于代码型的数据元，编制其值域，即代码表；
(6) 与现有的国家标准或行业标准进行协调。(1) 基础设施实体安全；
(2) 平台安全；
(3) 数据安全；
(4) 通信安全；
(5) 应用安全；
(6) 运行安全；
(7) 管理安全；
(8) 授权和审计安全；
(9) 安全防范体系。(1) 对等实体认证服务；
(2) 数据保密服务；
(3) 数据完整性服务；
(4) 数据源点认证服务
(5) 禁止否认服务；
(6) 犯罪证据提供服务。(1) 加密；
(2) 数字签名技术；
(3) 防控控制；
(4) 数据完整性；
(5) 认证；
(6) 数据挖掘。(1) 勤勉、尊重和关心他人；
(2) 营造协作的项目团队环境；
(3) 促进干系人有效参与；
(4) 聚焦于价值；
(5) 识别、评估和响应系统交互；
(6) 展现领导力行为；
(7) 根据环境进行裁剪；
(8) 将质量融入到过程和成果中；
(9) 驾驭复杂性；
(10) 优化风险应对；
(11) 拥抱适应性和韧性；
(12) 为实现目标而驱动变革。(1) 项目的必要性；
(2) 项目的市场预测；
(3) 项目预期成果（如产品方案或服务）的市场预测；
(4) 项目建设必需的条件。(1) 技术可行性分析；
(2) 经济可行性分析；
(3) 社会效益可行性分析；
(4) 运行环境可行性分析；
(5) 其他方面的可行性分析；(1) 进行项目开发的风险；
(2) 人力资源的有效性；
(3) 技术能力的可能性；
(4) 物资（产品）的可用性。(1) 支出分析：一次性支出、非一次性支出；
(2) 收益分析：直接收益、间接收益、其他收益；
(3) 收益投资比、投资回收期分析；
(4) 敏感性分析。(1) 对组织内部：品牌效益、竞争力效益、技术创新效益、人员提升收益、管理提升效益；
(2) 对社会发展：公共效益、文化效益、环境效益、社会责任感效益、其他收益。(1) 需求与市场预测；
(2) 设备与资源投入分析；
(3) 空间布局；
(4) 项目设计；
(5) 项目进度安排；
(6) 项目投资与成本估算。(1) 市场需求预测；
(2) 部件和投入的选择供应；
(3) 信息系统架构及技术方案的确定；
(4) 技术与设备选择；
(5) 网络物理布局设计；
(6) 投资、成本估算与资金筹措（投资费用、资金筹措、项目成本、财务报表）；
(7) 经济评价及综合分析。(1) 项目建设书及其批准文件；
(2) 项目可行性研究报告；
(3) 报送组织的申请报告及主管部门的初审意见；
(4) 项目关键建设条件和工程等的协议文件；
(5) 必需的其他文件和资料等。项目整合管理的定义：识别、定义、组合、统一和协调项目管理过程的各个过程和项目管理活动(1) 资源分配；
(2) 平衡竞争性需求；
(3) 研究各种备选方法；
(4) 裁剪过程以实现项目目标；
(5) 管理各个项目管理知识领域之间的依赖关系。项目的复杂性来源于组织的系统行为、人类行为以及组织或环境中的不确定性。复杂性的含义：
(1) 包含多个部分；
(2) 不同部分之间存在一系列关联；
(3) 不同部分之间的动态交互作用；
(4) 这些交互作用所产生的行为远远大于各部分简单的相加（例如突发性行为）。项目章程记录了关于项目和项目预期交付的产品、服务或成果的高层级信息：
(1) 项目目的；
(2) 可测量的项目目标和相关的成功标准；
(3) 高层级需求、高层级项目描述、边界定义以及主要可交付成果；
(4) 整体项目风险；
(5) 总体里程碑进度计划；
(6) 预先批准的财务资源；
(7) 关键干系人名单；
(8) 项目审批要求（例如，评价项目成功的标准，由谁对项目成功下结论，由谁签署项目结束）；
(9) 项目退出标准（例如，在何种条件下才能关闭或取消项目或阶段）；
(10) 委派的项目经理及其职责和职权；
(11) 发起人或其他批准项目章程的人员的姓名和职权等。问题日志是一种记录和跟进所有问题的项目文件，所需记录和跟进的内容主要包括：
(1) 问题类型；
(2) 问题提出者和提出时间；
(3) 问题描述；
(4) 问题优先级；
(5) 解决问题负责人；
(6) 目标解决日期；
(7) 问题状态；
(8) 最终解决情况等。(1) 纠正措施：为使项目工作绩效重新与项目管理计划一致，而进行的有目的的活动；
(2) 预防措施：为确保项目工作未来绩效符合项目管理计划，而进行的有目的的活动；
(3) 缺陷补救：为了修正不一致产品或产品组件，而进行的有目的的活动；
(4) 更新：对正式受控的项目文件或计划进行变更，以反映修改、增加的意见或内容。(1) 把项目的实际绩效与项目管理计划进行比较；
(2) 定期评估项目绩效，决定是否需要采取纠正或预防措施，并推荐必要的措施；
(3) 检查单个项目风险的状态；
(4) 在整个项目期间，维护一个准确且及时更新的信息库，以反映产品及文件的情况；
(5) 为状态报告、进展测量和预测提供信息；
(6) 做出预测，以更新当前的成本与进度信息；
(7) 监督已批准变更的实施情况；
(8) 如果项目是项目集的一部分，还应向项目集管理层报告项目进展和状态；
(9) 确保项目与商业需求保持一致。(1) 项目或阶段的概念；
(2) 范围目标、范围的评估标准，证明达到完工标准的证据；
(3) 质量目标、项目和产品质量的评估标准、相关核实信息和实际里程碑交付日期以及偏差原因；
(4) 成本目标，包括可接受的成本区间、实际成本，产生任何偏差的原因等；
(5) 最终产品、服务或成果的确认信息的总结；
(6) 进度计划目标，包括成果是否实现项目预期效益：如果在项目结束时未能实现效益，则指出效益实现程度并预计未来实现情况；
(7) 关于最终产品、服务或成果如何满足业务需求的概述：如果项目结束时未能满足业务需求，则指出需求满足程度并预计业务需求何时能得到满足；
(8) 关于项目过程中发生的风险或问题及其解决情况的概述。(1) 制定项目范围说明书；
(2) 根据详细项目范围说明书创建 WBS；
(3) 确定如何审批和维护范围基准；
(4) 正式验收已完成的项目可交付成果。(1) 如何规划、跟踪和报告各种需求活动；
(2) 配置管理活动；
(3) 需求优先级排序过程；
(4) 测量指标及使用这些指标的理由；
(5) 反映哪些需求属性将被列入跟踪矩阵。(1) 业务需要、机会、目的和目标；
(2) 项目目标；
(3) 项目范围和 WBS 可交付成果；
(4) 产品设计；
(5) 产品开发；
(6) 测试策略和测试场景；
(7) 高层级需求到详细需求。(1) 业务需求：整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因；
(2) 干系人需求：干系人的需要；
(3) 解决方案需求：为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求：
①功能需求：描述产品应具备的功能，例如，产品应该执行的行动、流程、数据和交互；
②非功能需求：是对功能需求的补充，是产品正常运行所需的环境条件或质量要求，例如，可靠性、保密性、性能、安全性、服务水平、可支持性、保留或清除等。
(4) 过渡和就绪需求：如数据转换和培训需求。这些需求描述了从“当前状态”过渡到“将来状态’所需的临时能力；
(5) 项目需求：项目需要满足的行动、过程或其他条件，例如里程碑日期、合同责任、制约因素等；
(6) 质量需求：用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准，例如，测试、认证、确认等。(1) 产品范围描述：逐步细化在项目章程和需求文件中所述的产品、服务或成果特征；
(2) 可交付成果：为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力，可交付成果也包括各种辅助成果，如项目管理报告和文件。对可交付成果的描述略可详；
(3) 验收标准：可交付成果通过验收前必须满足的一系列条件；
(4) 项目的除外责任：识别排除在项目之外的内容。明确说明哪些内容不属于项目范围，有助于管理干系人的期望及减少范围蔓延。(1) 识别和分析可交付成果及相关工作；
(2) 确定WBS的结构和编排方法；
(3) 自上而下逐层细化分解；
(4) 为WBS组成部分制定和分配标识编码；
(5) 核实可交付成果分解的程度是否恰当。(1) WBS必须是面向可交付成果的；
(2) WBS必须符合项目的范围；
100%原则（包含原则）认为，在WBS中，所有下一级的元素之和必须100%代表上一级的元素。
(3) WBS的底层应该支持计划和控制；
(4) WBS中的元素必须有人负责，而且只有一个人负责；
(5) WBS应控制在4~6层；一个工作单元只能从属于某个上层单元，避免交叉从属。
(6) WBS应包括项目管理工作（因为管理是项目具体工作的一部分），主要包括分包出去的工作；
(7) WBS的编制需要所有（主要）项目干系人的参与；
(8) WBS并非是一成不变的。(1) 确定需要进行范围确认的时间；
(2) 识别范围确认需要哪些投入；
(3) 确定范围正式被接受的标准和要素；
(4) 确定范围确认会议的组织步骤；
(5) 组织范围确认会议。(1) 可交付成果是否是确定的、可确认的；
(2) 每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件，例如，客户的书面认可等；
(3) 是否有明确的质量标准；
(4) 审核和承诺是否有清晰的表达；
(5) 项目范围是否覆盖了需要完成的产品或服务的所有活动，有没有遗漏或错误；
(6) 项目范围的风险是否太高；管理层是否能够降低风险发生时对项目的影响。(1) 网络图中每一活动和每一事件都必须有唯一的一个代号，即网络图中不会有相同的代号；
(2) 任何项活动的紧前事件和紧后事件代号至少有一个不相同，节点代号沿箭线方向越来越大；
(3) 流入（流出）同一节点的活动，均有共同的紧后活动（或紧前活动）。资源优化用于调整活动的开始和完成日期，以调整计划使用的资源，使其等于或少于可用的资源，包括：
(1) 资源平衡。资源平衡是为了在资源需求与资源供给之间取得平衡，根据资源制约因素对开始日期和完成日期进行调整的一种技术。资源平衡往往导致关键路径改变。资源平衡往往导致关键路径改变，而且通常是延长了关键路径。
(2) 资源平滑。对进度模型中的活动进行调整，从而使项目资源需求不超过预定的资源限制的一种技术。相对于资源平衡而言，资源平滑不会改变项目的关键路径，完工日期也不会延迟。(1) 对工程项目认识不足；
(2) 组织制度不健全；
(3) 方法问题；
(4) 技术的制约；
(5) 需求管理不当。(1) 对造成成本基准变更的因素施加影响；
(2) 确保所有变更请求都得到及时处理；
(3) 当变更实际发生时，管理这些变更；
(4) 确保成本支出不超过批准的资金限额，既不超出按时段、WBS组件和活动分配的限额，也不超出项目总限额；
(5) 监督成本绩效，找出并分析与成本基准间的偏差；
(6) 对照资金支出，监督工作绩效；
(7) 防止在成本或资源使用报告中出现未经批准的变更；
(8) 向干系人报告所有经批准的变更及其相关成本；
(9) 设法把预期的成本超支控制在可接受的范围内等。(1) 关于估算依据的文件（如估算是如何编制的）；
(2) 关于全部假设条件的文件；
(3) 关于各种已知制约因素的文件；
(4) 有关已识别的、在估算成本时应考虑的风险的文件；
(5) 对估算区间的说明（如‘10000元±10%’就说明了预期成本的所在区间）；
(6) 对最终估算的置信水平的说明。定义：是指确定质量方针、目标和职责，并通过质量体系中的质量规划、质量保证、质量控制以及质量改进来使其实现所有管理职能的全部活动。作用：为了实现质量目标。(1) 客户满意：了解、评估、定义和管理要求，以便满足客户的期望，这就需要把“符合要求”（确保项目产出预定的成果）和“适合使用”（产品或服务必须满足实际需求）结合起来；
(2) 持续改进：你将提出并经过明确完善的“计划—实施—检查—行动（PDCA）”循环是质量改进的基础，另外，全面质量管理（TQM）、六西格玛和精益六西格玛等质量改进举措也可提高项目管理的质量以及最终产品、服务或成果的质量；
(3) 管理层的责任：项目的成功需要项目团队全体成员的参与；
(4) 与供应商的互利合作关系：组织与其供应商相互依赖。定义：控制质量是为了评估绩效，确保项目输出完整、正确且满足客户期望，而监督和记录质量管理活动执行结果的过程。作用：定义：为了降低项目成本，而对项目所需的人力、材料、机械、技术、资金等资源所进行的计划、组织、指挥、协调和控制等的活动。(1) 职位权力（Legitimate Power）。来源于管理者在组织中的职位和职权。在高级管理层对项目经理正式授权的基础上，项目经理让员工进行工作的权力。
(2) 惩罚权力（Coercive Power）。使用降职、扣薪、惩罚、批评、威胁等负面手段的能力。滥用惩罚权力会导致项目失败，应谨慎使用。
(3) 奖励权力（Reward Power）。给予下属奖励的能力。奖励包括加薪、升职、福利、休假、礼物、口头表扬、认可度、特殊的任务以及其他的奖励员工满意行为的手段。
(4) 专家权力（Expert Power）。来源于个人的专业技能。如果项目经理让员工感到他是某些领域的专业权威，那么员工就会在这些领域内遵从项目经理的意见。
(5) 参照权力（Referent Power）。由于成为别人学习和参照榜样所拥有的力量。(1) 形成阶段（Forming）。团队成员倾向于相互独立，不怎么开诚布公。
(2) 震荡阶段（Storming）。个体之间开始争执，互相指责，并且怀疑项目经理的能力。
(3) 规范阶段（Norming）。团队成员开始相互信任，项目经理能得到团队的认可。
(4) 发挥阶段（Performing）。团队成员之间相互依靠，平稳高效地解决问题。这时团队成员的集体荣誉会非常强。
(5) 解散阶段（Adjourning）。所有工作完成后，项目结束，团队解散。(1) 识别资源：用于识别和量化项目所需的团队和实物资源的方法。
(2) 获取资源：关于如何获取项目所需的团队和实物资源的指南。
(3) 角色与职责：①角色是指在项目中某人承担的职务或分配给某人的职务；②职权是指使用项目资源、做出决策、签字批准、验收可交付成果并影响他人开展项目工作的权力；③职责是指为完成项目活动，项目团队成员必须履行的职责和工作；④能力是指为完成项目活动，项目团队成员须具备的技能和才干。
(4) 项目组织图：以图形方式展示项目团队成员及其报告关系。
(5) 项目团队资源管理：关于如何定义、配备、管理和最终遣散项目团队资源的指南。
(6) 培训：针对项目成员的培训策略。
(7) 团队建设：建设项目团队的方法。
(8) 资源控制：依据需要确保实物资源充足可用，并为项目需求优化实物资源采购而采用的方法。
(9) 认可计划：将给予团队成员哪些认可和奖励，以及何时给予。(1) 监督资源支出；
(2) 及时识别和处理资源缺乏/剩余情况；
(3) 确保根据计划和项目需求使用并释放资源；
(4) 出现资源相关问题时通知相应干系人；
(5) 影响可以导致资源使用变更的因素；
(6) 在变更实际发生时对其进行管理等。(1) 冲突的重要性与激烈程度；
(2) 解决冲突的紧迫性；
(3) 涉及冲突的人员的相对权力；
(4) 维持良好关系的重要性；
(5) 永久或暂时解决冲突的动机等。(1) 撤退/回避：从实际或者在冲突中退出，将问题推迟到准备充分的时候，或者将问题推给其他人员解决。
(2) 缓和/包容：强调一致而非差异；为维持和谐与关系而退让一步，考虑其他方的需要。
(3) 妥协/调解：为了暂时或部分解决冲突，寻找能让各方都在一定程度上满意的方案，但这种方法有时会导致“双输”局面。
(4) 强迫/命令：以牺牲其他方为代价，推行某一方的观点；只提供赢-输方案。通常是利用权力来强行解决紧急问题，这种方法通常会导致“赢-输”局面。
(5) 合作/解决问题：综合考虑不同的观点和意见，采用合作的态度和开放式对话引导各方达成共识和承诺，这种方法可以带来双重局面。定义：是确保及时、正确地产生、收集、分发、存储和最终处理项目信息所需的过程。(1) 已发送：信息已发送；
(2) 已收到：对方信息已收到；
(3) 已理解：正确地消化和理解信息中的内容是简单接收信息的关键的一环；
(4) 已认可：理解了传达的信息并不代表对方已同意这个观点；
(5) 已转化为积极的行动：正确地理解和达成一致的认可比较难，但更加困难的是让对方转化为实际的、积极的行动，而且是方向正确无误的行动。(1) 正确的语法和拼写（Correctness）：语法不当或拼写错误会分散注意力，甚至可能扭曲信息含义，降低可信度。
(2) 简洁的表述（Concise）：简洁且精心组织的信息能降低误解信息意图的可能性。
(3) 清晰的目的和表述（Clarity）：确保在信息中包含能满足受众需求与激发其兴趣的内容。
(4) 连贯的思维逻辑（Coherent）：写作思路连贯，在整个书面文件中使用诸如“引言”和“小结”的小标题。
(5) 善用控制语句和承接（Controlling）：可能需要使用图表或小结来控制语句和思路的承接。(1) 及时向干系人提供相关信息；
(2) 引导干系人有效参与项目；
(3) 编制书面沟通计划。(1) 互动沟通。在两方或多方之间进行的实时多向信息交换。
(2) 推式沟通。向需要接收信息的特定接收方发送或发布信息。
(3) 拉式沟通。适用于大量复杂信息或大量信息受众的情况。(1) 干系人的沟通需求；
(2) 需沟通的信息，包括语言、形式、内容和详细程度；
(3) 上报步骤；
(4) 发布信息的原因；
(5) 发布所需信息、确认已收到或作出回应（若适用）的时限和频率；
(6) 负责沟通相关信息的人员；
(7) 负责授权保密信息发布的人员；
(8) 接收信息的人员或群体，包括他们的需要、需求和期望；
(9) 用于传递信息的方法或技术，如备忘录、电子邮件、新闻稿、或社交媒体；
(10) 为沟通活动分配的资源，包括时间和预算；
(11) 随着项目进展（如项目不同阶段干系人社区的变化）而更新与优化沟通管理计划的方法；
(12) 通用术语表；
(13) 项目信息流向图、工作流程（可能包含审批程序）、报告清单和会议计划等；
(14) 来自法律法规、技术、组织政策等的制约因素等。权力利益方格、权力影响方格，或作用影响方格：基于干系人的职权级别（权力）、对项目成果的关心程度（利益）、对项目成果的影响能力（影响），或改变项目计划或执行的能力，每一种方格都可用于对干系人进行分类。干系人立方体：上述方格模型的改良形式。立方体把上述方格中的要素组合成三维模型，项目经理和团队可据此分析干系人并引导干系人参与项目。凸显模型：通过评估干系人的权力（职权级别或对项目成果的影响能力）、紧迫性（因时间约束或干系人对项目成果有重大利益诉求而导致需立即加以关注）和合法性（参与的适当性），对干系人进行分类。影响方向：可以根据干系人对项目工作或项目团队本身的影响方向，对干系人进行分类。可以把干系人分类为：①向上。执行组织或客户组织、发起人和指导委员会的高级管理层。②向下。临时贡献知识或技能的团队或专家。③向外。项目团队外的干系人群体及其代表，如供应商、政府机构、公众、最终用户和监管部门。④横向。项目经理的同级人员，如其他项目经理或中层管理人员，他们与项目经理竞争稀缺项目资源或者合作共享资源或信息。优先级排序：如果项目有大量干系人、干系人群体的成员频繁变化、干系人和项目团队之间或干系人群内部的关系复杂，则有必要对干系人进行优先级排序。(1) 不了解型：不知道项目及其潜在影响。
(2) 抵制型：知道项目及其潜在影响，但抵制项目工作或成果可能引发的任何变更。此类干系人不会支持项目工作或项目成果。
(3) 中立型：了解项目，但既不支持，也不反对。
(4) 支持型：了解项目及其潜在影响，并且会支持项目工作及其成果。
(5) 领导型：了解项目及其潜在影响，而且积极参与以确保项目取得成功。(1) 在适当的项目阶段引导干系人参与，以便获取、确认或维持他们对项目成功的持续承诺；
(2) 通过谈判和沟通的方式管理干系人期望；
(3) 处理与干系人管理有关的任何风险或潜在关注点，预测干系人可能在未来引发的问题；
(4) 澄清和解决已识别的问题。(1) 已识别风险的清单：每个项目风险都被赋予一个独特的标识号。
(2) 潜在风险责任人：如果已在识别风险过程中识别出潜在的风险责任人，就要把该责任人记录到风险登记册中。
(3) 潜在风险应对措施清单：如果已在识别风险过程中识别出某种潜在的风险应对措施，就要把它记录到风险登记册中。(1) 按风险后果划分:纯粹风险、投机风险；
(2) 按风险来源划分：自然风险、人为风险；
(3) 按风险是否可管理划分；
(4) 按风险影响范围划分；
(5) 按风险后果的承担者划分；
(6) 按风险的可预测性划分：已知风险、可预测风险、不可预测风险；(1) 上报。如果项目团队或项目发起人认为某威胁不在项目范围内，或提议的应对措施超出了项目经理的权限，就应该采用上报策略。
(2) 规避。风险规避是指项目团队采取行动来消除威胁，或保护项目免受威胁的影响。
(3) 转移。转移涉及将应对威胁的责任转移给第三方，让第三方管理风险并承担威胁发生的影响。
(4) 减轻。风险减轻是指采取措施来降低威胁发生的概率和影响。
(5) 接受。风险接受是指承认威胁的存在。此策略可用于低优先级威胁，也可用于无法以任何其他方式经济有效地应对的威胁。(1) 上报。如果项目团队或项目发起人认为某机会不在项目范围内，或提议的应对措施超出了项目经理的权限，就应该采取上报策略。
(2) 开拓。如果组织想确保把握住高优先级的机会，就可以选择开拓策略。此策略将特定机会的出现概率提高到100%，确保其肯定出现，从而获得与其相关的收益。
(3) 分享。分享涉及将应对机会的责任转移给第三方，使其享有机会所带来的部分收益。
(4) 提高。提高策略用于提高机会出现的概率和影响。提前采取提高措施通常比机会出现后尝试改善收益更加有效。
(5) 接受。接受机会是指承认机会的存在。此策略可用于低优先级机会，也可用于无法以任何其他方式经济有效地应对的机会。(1) 风险数据质量评估。
(2) 风险概率和影响评估。
(3) 其他风险参数评估。(1) 模拟（蒙特卡洛分析）；
(2) 敏感性分析；
(3) 决策树分析。(1) 准备采购工作说明书（SOW）或工作大纲（TOR）；
(2) 准备高层的成本估算，制定预算；
(3) 发布招标广告；
(4) 确定合格卖方的名单；
(5) 准备并发布招标文件；
(6) 由卖方准备并提交建议书；
(7) 对建议书开展技术（包括质量）评估；
(8) 对建议书开展成本评估；
(9) 准备最终的综合评估报告（包括质量及成本），选出中标建议书；
(10) 结束谈判，买方和卖方签署合同。| 采购管理计划 | 采购策略 | 工作说明书 | 招标文件 |
|---|---|---|---|
| 采购工作将与其他项目工作协调和整合，特别是资源、进度计划和预算工作 | 采购交付方法 | 采购项目描述 | 信息邀请(RFI) 报价邀请(RFQ) 建议邀请(RFP) |
| 关键采购活动的时间表 | 协议类型 | 规格、质量要求和绩效指标 | |
| 用于管理合同的采购指标 | 采购阶段 | 所需附加服务描述 | |
| 所有干系人的职责 | 验收方法和验收标准 | ||
| 采购假设和制约因素 | 绩效数据和其他所需报告 质量 | ||
| 法律管辖和支付货币 | 履约时间和地点 | ||
| 独立估算信息 | 货币；支付进度计划 | ||
| 风险管理事项 | 担保 |
(1) 承包商需要执行的任务，以及所需的协调工作；
(2) 承包商必须达到的适用标准；
(3) 需要提交批准的数据；
(4) 由买方提供给承包商的，适用时，将用于合同履行的全部数据和服务的详细清单；
(5) 关于初始成果提交和审查（或审批）的进度计划。(1) 项目名称。
(2) 标的内容和范围。
(3) 项目的质量要求。
(4) 项目的计划、进度、地点、地域和方式。
(5) 项目建设过程中的各种期限。
(6) 技术情报和资料的保密。
(7) 风险责任的承担。
(8) 技术成果的归属。
(9) 验收的标准和方法。
(10) 价款、报酬（或使用费）及其支付方式
(11) 违约金或者损失赔偿的计算方法。
(12) 解决争议的方法。
(13) 名词术语解释。(1) 按项目范围划分以项目的范围为标准划分，可以将合同分为项目总承包合同、项目单项承包合同和项目分包合同 3 类：①项目总承包合同。买方将项目的全过程作为一个整体发包给同一个卖方的合同。
②项目单项承包合同。一个卖方只承包项目中的某一项或某几项内容，买方分别与不同的卖方订立项目单项承包合同。
③项目分包合同。经合同约定和买方认可，卖方将其承包项目的某一部分或某几部分（非项目的主体结构）再发包给具有相应资质条件的分包方，与分包方订立的合同称为项目分包合同。(2) 按项目付款方式划分
以项目付款方式为标准进行划分，通常可将合同分为两大类，即总价类和成本补偿类。还有第三种常用合同类型，即混合型的工料合同。
①总价合同。总价合同为既定产品或服务的采购设定一个总价。总价合同也可以为达到或超过项目目标（例如，进度交付日期、成本和技术绩效，或其他可量化、可测量的目标）而规定财务奖励条款。从付款的类型上来说，总价合同又可以分为：固定总价合同、总价加激励费用合同、总价加经济价格调整合同、订购单。
②成本补偿合同。成本补偿合同向卖方支付为完成工作而发生的全部合法实际成本（可报销成本），外加一笔费用作为卖方的利润。成本补偿合同可分为：成本加固定费用合同、成本加激励费用合同、成本加奖励费用合同。
③工料合同。工料合同是指按项目工作所花费的实际工时数和材料数，按事先确定的单位工时费用标准和单位材料费用标准进行付款。(1) 经过买方认可；
(2) 分包的部分必须是项目非主体工作；
(3) 只能分包部分项目，而不能转包整个项目；
(4) 分包方必须具备相应的资质条件；
(5) 分包方不能再欠分包。在项目工作中，要根据项目的实际情况和外界条件的约束来选择合同类型：
(1) 如果工作范围很明确，且项目的设计已具备详细的细节，则使用总价合同；
(2) 如果工作性质清楚，但范围不是很清楚，而且工作不复杂，又需要快速签订合同，则使用工料合同；
(3) 如果工作范围尚不清楚，则使用成本补偿合同；
(4)
①如果双方分担风险，则使用工料合同；
②如果买方承担成本风险，则使用成本补偿合同；
③如果卖方承担成本风险，则使用总价合同；
(5) 如果是购买标准产品，且数量不大，则使用单位合同等。合同的签订管理、合同的履行管理、合同的变更管理、合同的档案管理和合同违约索赔管理。(1) 提出索赔要求。当出现索赔事项时，索赔方以书面的索赔通知书形式，在索赔事项发生后的28天以内，向监理工程师正式提出索赔意向通知。
(2) 报送索赔资料。在索赔通知书发出后的28天内，向监理工程师提出延长工期和（或）补偿经济损失的索赔报告及有关资料。
(3) 监理工程师答复。监理工程师在收到送交的索赔报告有关资料后，于28天内给予答复，或要求索赔方进一步补充索赔理由和证据。
(4) 监理工程师逾期答复后果。监理工程师在收到承包人送交的索赔报告的有关资料后28天未予答复或未对承包人作进一步要求，视为该项索赔已经认可。
(5) 持续索赔。当索赔事件持续进行时，索赔方应当阶段性向监理工程师发出索赔意向，在索赔事件终了后28天内，向监理工程师送交索赔的有关资料和最终索赔报告，监理工程师应在28天内给予答复或要求索赔方进一步补充索赔理由和证据。逾期未答复，视为该项索赔成立。
(6) 仲裁与诉讼。监理工程师对索赔的答复，索赔方或发包人不能接受，即进入仲裁或诉讼程序。(1) 最低成本：适用于标准化或常规采购。此类采购有成熟的实践与标准，有具体明确的预期成果，可以用不同的成本来取得。
(2) 仅凭资质：适用于采购价值相对较小，不值得花时间和成本开展完整选择过程的情况。买方会确定短名单，然后根据可信度、相关资质、经验、专业知识、专长领域和参考资料选择最佳的投标人。
(3) 基于质量或技术方案得分：采用此方法，会先对技术建议书进行评估，考察技术方案的质量。如果经过谈判，证明它们的财务建议书是可接受的，那么就会选择技术建议书得分最高的卖方。
(4) 基于质量和成本：成本也是用于选择卖方的一个考虑因素。一般而言，如果项目的风险和（或）不确定性较高，相对于成本而言，质量就应这是一个关键因素。
(5) 唯一来源：买方要求特定卖方准备技术和财务建议书，然后针对建议书开展谈判。由于没有竞争，因此仅在适当理由时才采用此方法，而且应将其视为特殊情况。
(6) 固定预算：在建议邀请书中受邀的卖方披露可用预算，然后在此预算内选择技术建议书得分最高的卖方。此方法仅适用于工作说明书定义精确、预期不会发生变更，而且预算固定且不得超出的情况。干系人绩效域涉及与干系人相关的活动和职能。| 绩效要点 | 预期目标 | 对应指标及检查方法 |
|---|---|---|
| 促进干系人参与 识别、理解和分析、优先级排序、参与、监督 | ①与干系人建立高效的工作关系 | 干系人参与的连续性：通过观察、记录方式，对干系人参与的连续性进行衡量 |
| ^ | ②干系人认同项目目标 | 变更的频率：对项目范围、产品需求的大量变更或修改可能表明干系人没有参与进来或与项目目标不一致 |
| ^ | ③支持项目的干系人提高了满意度，并从中收益 | •干系人行为：干系人的行为可表明项目受益人是否对项目感到满意和表示支持，或者他们是否反对项目 •干系人满意度：可通过调研、访谈和焦点小组方式，确定干系人满意度，判断干系人是否感到满意和表示支持，或者他们对项目及其交付物是否表示反对 •干系人相关问题和风险：对项目问题日志和风险登记册的审查可以识别与单个干系人有关的问题和风险 |
| ^ | ④反对项目的干系人没有对项目产生负面影响 | ^ |
团队绩效域涉及项目团队人员有关的活动和职能。| 绩效要点 | 预期目标 | 对应指标及检查方法 |
|---|---|---|
| ①项目团队文化 ②高绩效项目团队 ③领导力技能 •建立和维护愿景 •批判性思维 •激励 | ①共享责任 | 目标和责任心：所有项目团队成员都了解愿景和目标。项目团队对项目的交付物和项目成果承担责任 |
| ^ | ②建立高绩效团队 | •信任与协作程度：项目团队彼此信任，相互协作 •适应变化的能力：项目团队适应不断变化的情况，并在面对挑战时有韧性 •彼此赋能：项目团队感到被赋能，同时项目团队对其成员赋能并认可 |
| ^ | ③所有团队成员都展现出相应的领导力和人际关系技能 | 管理和领导力风格适宜性：项目团队成员运用批判性思维和人际关系技能；项目团队成员的管理和领导力风格适合项目的背景和环境 |
开发方法和生命周期绩效域涉及与项目的开发方法、节奏和生命周期相关的活动和职能。| 绩效要点 | 预期目标 | 对应指标及检查方法 |
|---|---|---|
| ①交付节奏 - 一次性交付 - 多次交付 - 定期交付 - 持续交付 ②开发方法 - 预测型方法 - 混合型方法 - 适应型方法 ③开发方法的选择 - 产品、服务或成果 - 项目 - 组织 ④协调交付节奏和开发方法 | ①开发方法与项目可交付物相符合 | 产品质量和变更成本：采用适宜的开发方法（预测型、混合型或适应型），可交付物的产品变量比较高，变更成本相对较小 |
| ^ | ②项目交付与干系人价值紧密关联 | 价值导向型项目阶段：按照价值导向将项目工作从启动到收尾划分为多个项目阶段，项目阶段中包括适当的退出标准 |
| ^ | ③项目生命周期由促进交付节奏的项目阶段和产生项目交付物所需的开发方法组成 | 适宜的交付节奏和开发方法：如果项目具有多个可交付物，且交付节奏和开发方法不同，可将生命周期阶段进行重叠或重复 |
规划绩效域涉及整个项目期间组织与协调相关的活动与职能。| 绩效要点 | 预期目标 | 对应指标及检查方法 |
|---|---|---|
| ①规划的影响因素 •开发方法 •项目可交付物 •组织需求 •市场条件 •法律或法规限制 ②项目估算 •区间 •准确度 •精确度 •信心 ③项目团队组成和结构规划 ④沟通规划 ⑤物资源规划 ⑥采购规划 ⑦实变更规划 ⑧度量指标和一致性 •度量指标 •一致性 | ①项目以有条理、协调一致的方式推进 | 绩效偏差：对照项目基准和其他度量指标对项目结果进行绩效审查表明项目正在按计划进行，绩效偏差处于临界值范围内 |
| ^ | ②应用系统的方法交付项目成果 | 规划的整体性：交付进度、资金提供、资源可用性、采购等表明项目是以整体方式进行规划的，没有差距或不一致之处 |
| ^ | ③对演变情况进行详细说明 | 规划的详尽程度：与当前信息相比，可交付物和需求的初步信息是适当的、详尽的；与可行性研究与评估相比，当前信息表明项目可以生成预期的可交付物和成果 |
| ^ | ④规划投入的时间成本是适当的 | 规划适宜性：项目计划和文件表明规划水平适合于项目 |
| ^ | ⑤规划的内容对管理干系人的需求而言是充分的 | 规划的充分性：沟通管理计划和干系人信息表明沟通足以满足干系人的期望 |
| ^ | ⑥可以根据新出现的和不断变化的需求进行调整 | 可适应变化：采用待办事项列表的项目，在整个项目期间会对各个计划做出调整。采用变更控制过程的项目具有变更控制委员会，会议的变更日志和文档表明变更控制过程正在得到应用 |
项目工作绩效域涉及项目工作相关的活动和职能。| 绩效要点 | 预期目标 | 对应指标及检查方法 |
|---|---|---|
| ①项目过程 | ①高效且有效的项目绩效 | 状态报告：通过状态报告可以表明项目工作有效率且有效果 |
| ②项目制约因素 | ②适合项目和环境的项目过程 | *过程的适宜性：证据表明，项目过程是为满足项目和环境的需要而裁剪的* |
| ③专注于工作过程和能力 | *过程相关性和有效性：过程审计和质量保证活动表明，过程具有相关性且正得到有效使用* | |
| ④管理沟通和参与 | ③干系人适当的沟通和参与 | 沟通有效性：项目沟通管理计划和沟通文件表明，所计划的信息与干系人进行了沟通，如有新的信息沟通需求或误解，可能表明干系人的沟通和参与活动缺乏成效 |
| ⑤管理实施资源 | ⑥对实施资源进行了有效管理 | 资源利用率：所用材料的数量、抛弃的废料和返工量表明，资源正得到高效利用 |
| ⑥处理采购事宜 | ⑦对采购进行有效管理 | 采购过程适宜：采购审计表明，所采用的适当流程足以开展采购工作，而且承包商正在按计划开展工作 |
| ⑦监督新工作和变更 | *变更处理情况：使用预测型方法的项目已建立变更日志，该日志表明，正在对变更做出全面评估，同时考虑了范围、进度、预算、资源、干系人和风险的影响；采用适应型方法的项目已建立待办事项列表，该列表显示完成范围的比率和增加新范围的比率* | |
| ⑧学习与持续改进 | ||
| ⑨有效处理了变更 | ||
| ⑩通过持续学习和过程改进提高了团队能力 | 团队绩效：团队状态报告表明，错误和返工减少，而效率提高 |
需求启发
不断演变和发现的需求
管理需求
定义范围和管理变更③质量①项目有助于实现业务目标和战略目标一致性：组织的战略计划、可行性研究报告以及项目授权文件表明，项目可交付物和业务目标保持一致②项目实现了预期成果项目完成度：项目基础数据表明，项目仍处于正轨，可实现预期成果③在预定时间内实现了项目收益项目收益：进度表明财务指标和所规划的交付正在按计划实现④团队对需求有清晰的理解需求稳定性：在预测型项目中，初始需求的变更很少，表明对需求的真正理解度较高。在需求不断演变的适应型项目中，项目进展中阶段性需求确认反映了干系人对需求的理解⑤干系人接受项目可交付物和成果，并对其满意
干系人满意度：访谈、观察和最终用户反馈可表明干系人对可交付物的满意度
质量问题：投诉或退货等质量相关问题的数量也可用于表示满意度| 度量绩效域涉及评估项目绩效和采取应对措施相关的活动和职能。 | ||
|---|---|---|
| 绩效要点 | 预期目标 | 对应指标及检查方法 |
| ①制定有效的度量指标 | ①对项目状况充分理解 | 度量结果和报告：通过审计度量结果和报告，可表明数据是否可靠 |
| *关键绩效指标* | ||
| *有效度量指标* | ②数据充分，可支持决策 | 度量结果：度量结果可表明项目是否按预期进行，或者是否存在偏差 |
| ③度量内容及相应指标 | ||
| *可交付物的度量指标* | ③及时采取行动，确保项目最佳绩效 | 度量结果：度量结果提供了提前指标以及当前状态，可导致及时的决策和行动 |
| *交付的度量指标* | ||
| *基准绩效的度量指标* | ||
| *资源的度量指标* | ||
| *价值的度量指标* | ||
| *干系人的度量指标* | ||
| *预测型度量指标* | ||
| ④展示度量信息和结果 | ⑤能够基于预测和评估作出决策，实现目标并产生价值 | 工作绩效数据：回顾过去的预测和当前的工作绩效数据可发现，以前的预测是否准确地反映了目前的情况。将实际绩效与计划绩效进行比较，并评估业务文档，可表明项目实现预期价值的可能性 |
| *仪表盘* | ||
| *大型可见图表* | ||
| *任务板* | ||
| *燃烧图* | ||
| ④度量陷阱 | ||
| ⑤基于度量进行诊断 | ||
| ⑥持续改进 |
| 不确定性绩效域涉及与不确定性相关的活动和职能。 | ||
|---|---|---|
| 绩效要点 | 预期目标 | 对应指标及检查方法 |
| ①风险 | ①了解项目的运行环境，包括技术、社会、政治市场和经济环境等 | 环境因素：团队在评估不确定性、风险和应对措施时考虑了环境因素 |
| ②模糊性 | ②识别、分析和应对不确定性 | 风险应对措施：与项目制约因素（例如，预算、进度和绩效）的优先级排序保持一致 |
| ③复杂性 | ③了解项目中多个因素之间的相互依赖关系 | 应对措施适宜性：应对风险、复杂性和模糊性的措施适合于项目 |
| •基于系统的复杂性 | ④能够对威胁和社会进行预测，了解问题的后果 | 风险管理机制或系统：用于识别、分析和应对风险的系统非常强大 |
| •重新构建的复杂性 | ⑤最小化不确定性对项目交付的负面影响 | 项目绩效处于临界值内：满足计划的交付日期，预算执行情况处于偏差临界值内 |
| •基于过程的复杂性 | ⑥能够利用机会改进项目的绩效和成果 | 利用机会的机制：团队使用既定机制来识别和利用机会 |
| ④不确定性的应对方法 | ⑦有效利用成本和进度储备，与项目目标保持一致 | 储备使用：团队采取步骤主动预防威胁，有效使用成本或进度储备 |
(1) 收集信息。可以对信息收集和分析工作进行规划，以便发现更多信息（如进行研究、争取专家参与或进行市场分析）来减少不确定性。(2) 为多种结果做好准备。制定可用的解决方案，包括备份或应急计划，为每一个不确定性做好准备。如果存在大量潜在不确定性，项目团队需要对潜在原因进行分类和评估，估算其发生的可能性。(3) 集合设计。探索各种选项，来权衡包括时间与成本、质量与成本、风险与进度、进度与质量等多种因素，在整个过程中，舍弃无效或次优的替代方案，以便项目团队能够从各种备选方案中选择最佳方案。(4) 增加韧性。韧性是对意外变化快速适应和应对的能力，韧性既适用于项目团队成员，也适用于组织过程。如果对产品设计的初始方法或原型无效，则项目团队和组织需要能够快速学习、适应和应对变化。(1) 制订配置管理计划
(2) 配置项识别
(3) 配置项控制
(4) 配置状态报告
(5) 配置审计
(6) 配置管理回顾与改进配置项控制即对配置项和基线的变更控制，包括：标识和记录变更申请、分析和评价变更、批准或否决申请、实现、验证和发布已修改的配置项等任务。(1) 变更申请。变更申请主要就是陈述要做什么变更，为什么要变更，以及打算怎样变更。相关人员（如项目经理）填写变更申请表，说明要变更的内容、变更原因、受变更影响的关联配置项和有关基线、变更实施方案、工作量和变更实施人等，提交给CCB。
(2) 变更评估。CCB负责组织对变更申请进行评估并确定：①变更对项目的影响；②变更的内容是否必要；③变更的范围是否考虑周全；④变更的实施方案是否可行；⑤变更工作量估计是否合理。CCB决定是否接受变更，并将决定通知相关人员。
(3) 通信评估结果。CCB把关于每个变更申请的批准、否决或推迟的决定通知受此处置意见影响的每个干系人。
(4) 变更实施。项目经理组织修改相关的配置项，并在相应的文档、程序代码或配置管理数据中记录变更信息。
(5) 变更验证与确认。项目经理指定人员对变更后的配置项进行测试或验证。项目经理应将变更与验证的结果提交给CCB，由其确认变更是否已经按要求完成。
(6) 变更的发布。配置管理员将变更后的配置项纳入基线。配置管理员将变更内容和结果通知相关人员，并做好记录。
(7) 基于配置库的变更控制。在信息系统开发项目中，一处出现了变更，经常会连锁引起多处变更，会涉及到参与开发工作的许多人。(1) 产品范围（成果）定义的过失或者疏忽；
(2) 项目范围（工作）定义的过失或者疏忽；
(3) 增值变更；
(4) 应对风险的紧急计划或回避计划；
(5) 项目执行过程与基准要求不一致带来的被动调整；
(6) 外部事件。(1) 基准管理：基准是变更的依据；
(2) 变更控制流程化：建立或选用符合项目需要的变更管理流程，所有变更都必须遵循这个控制流程；
(3) 明确组织分工：至少应明确变更相关工作的评估、评审、执行的职能；
(4) 评估变更的可能影响：变更的来源是多样的，既需要完成对客户可视的成果、交付期等变更操作，还需要完成对客户不可视的项目内部工作的变更，如实施方的人员分工、管理工作和资源配置等；
(5) 妥善保存变更产生的相关文档：确保其完整、及时、准确和清晰，适当时可以引入配置管理工具。(1) 变更申请
(2) 对变更的初审
(3) 变更方案论证
(4) 变更审查
(5) 发出通知并实施
(6) 实施监控
(7) 效果评估
(8) 变更收尾(1) 通知相关用户系统开始回退；
(2) 通知各关联系统进行版本回退；
(3) 回退存储过程等数据对象；
(4) 配置数据回退；
(5) 应用程序、接口程序、工作流等版本回退；
(6) 回退完成通知各周边关联系统；
(7) 回退后进行相关测试，保证回退系统能够正常运行；
(8) 通知用户回退完成等。(1) 项目集战略一致性
(2) 项目集效益管理
(3) 项目集干系人参与
(4) 项目集治理
(5) 项目集生命周期管理项目集效益管理是定义、创建、最大化和交付项目集所提供效益的绩效域。主要活动包括：- (1) 效益识别
- (2) 效益分析和规划
- (3) 效益交付
- (4) 效益移交
- (5) 效益维持- (1) 项目组合生命周期
- (2) 项目组合战略管理
- (3) 项目组合治理
- (4) 项目组合产能与能力管理
- (5) 项目组合干系人参与
- (6) 项目组合价值管理
- (7) 项目组合风险管理- (1) 启动阶段。
- (2) 规划阶段。其主要活动包括：
项目组合组件范围和管理；
执行组件所需的预算；
项目组合及组件间的依赖关系识别；
风险和问题的识别与应对计划；
资源需求；
项目组合组件的优先排列顺序；
治理机构、发起人和干系人责任的确认；
用来衡量成功的项目组合标准；
产品或服务的需求与规范。
- (3) 执行阶段。其主要活动包括：
项目组合内所有组件的交付；
管理和解决项目组合及其组件之间的风险与问题；
引导项目组合和组件的沟通汇报；
根据需要重新排序和变更子项目组合；
以组件交付为基础监督收益实现的潜能；
管理给项目组合的有限资产和资源。
- (4) 优化阶段。通过最大化可用的条件、制约因素和资源，使项目组合尽可能高效的过程。(1) OPM 治理；
(2) OPM 方法论；
(3) 知识管理；
(4) 人才管理。