PMP裁剪

PMP裁剪是【第七版-PMBOK项目管理知识体系指南】中的一部分，分别从为什么要裁剪，裁剪的内容，裁剪过程，对绩效域进行裁剪，诊断，总结，几个方面描述PMP裁剪包括的过程以及如何裁剪，对准备考PMP或者从事项目管理工作的同学非常实用

PMP裁剪

• 概述
  • 裁剪是对有关项目管理方法、治理和过程深思熟虑后作出的调整，使之更适合特定环境和当前工作
  • 裁剪会考虑开发方法、过程、项目生命周期、可交付物以及其共同参与工作人员的选择
  • 使用裁剪需要谨慎选择和调整多个项目因素，无论是否使用“裁剪”标签皆是如此
  • 进行裁剪需要注意如下几个方面
    • 尽快交付
    • 最小化项目成本
    • 优化所交付的价值
    • 创建高质量的可交付物和成果
    • 遵守监管标准
    • 满足不同干系人的期望
    • 适应变化
• 为什么要裁剪
  • 裁剪旨在更好地满足组织、运行环境和项目的需要
  • 裁剪带来的直接和间接收益
    • 帮助对方法进行裁剪的项目团队成员，可以做出更多承诺
    • 以客户为本（因为客户需要时组织发展的重要影响因素）
    • 更有效地利用项目资源
• 裁剪的内容
  • 生命周期和开发方法的选择
    • 一些大型项目可能同时使用各种开发和交付方法的组合，例如同时使用预测型方法和迭代型方法，则从项目层面来看，这种组合代表混合型方法，可根据项目情况可能只使用预测型或迭代型开发方法
  • 过程
    • 增加
      • 以实现所需的严格性、覆盖范围，或应对独特的产品或运营环境的状况等（例如，对安全性要求比较高的项目要增加独立检查这一环节）
    • 修改
      • 以更好地满足项目或项目团队的需求（例如，修改项目文档的格式，以照顾视力较差的项目团队成员）
    • 混合
      • 通过混合或合并各种要素带来额外的收益或价值
    • 取消
      • 以减少成本或人力投入，因为相对于它所增加的价值，这些成本或投入没有必要或不经济（例如，对一个集中办公、具有良好沟通的小型项目团队，可以取消会议记录）
    • 调整
      • 以协调各种要素，从而形成一致的定义、理解和应用（例如，在涉及多个学科的项目团队中，不同学科可能存在特定要素）
  • 参与
    • 对项目所涉及人员参与裁剪
      • 人员
        • 需要评估项目领导层和项目团队的技能和能力，然后根据项目类型和运作情况选择应参与的人员以及应具备的能力
      • 赋能
        • 赋能涉及选择应将哪些职责和现场决策形式下放给项目团队
        • 某些环境和团队成员能力支持进行高层级赋能
        • 在其他情况下，减少赋能、增加监督和指导也许更为可取
      • 整合
        • 除了发起组织的内部员工之外，项目团队还可以包括来自具有合同关系的实体、渠道合作伙伴和其他外部实体的贡献者
  • 工具
    • 选择项目团队将用于项目的工具（例如软件）是裁剪的一种形式
  • 方法和工件
    • 对将用于项目的文档、模板和其他工件进行裁剪有助于确保工件适合项目和组织
    • 对将用于实现项目成果的方法进行裁剪，以便这些方法适合项目所处的环境和文化
• 裁剪过程
  • 裁剪过程中各步骤的详细信息
  • 选择初始开发方法
    • 此步骤将确定用于项目的开发方法
    • 项目团队运用他们的产品知识、交付节奏和对可用选项的认识，选择最适合情况的开发方法
  • 对组织进行裁剪
    • 为组织进行裁剪的额外制约因素包括对安全性要求比较高的大型项目和根据合同执行的项目
    • 对安全性要求比较高的大型项目的裁剪建议可能需要额外的监督和批准，以帮助防范错误、损失或后续问题
    • 对组织的方法裁剪包括增加、取消和重新配置该方法的要素，以使该方法更适合组织
    • 设有项目管理办公室PMO或价值交付办公室VDO的组织，在对裁剪的交付方法进行审查和批准方面可以扮演一定的角色
    • 与外部团队有影响的裁剪（例如，其他部门的参与方式和时间等）相比，只对项目团队有影响的裁剪所需的监督较少
    • 内部项目裁剪可能只需项目经理批准即可，外部团队有影响的裁剪变更可能需经PMO或VDO批准
    • 裁剪时对组织和项目因素进行评估
  • 对项目进行裁剪
    • 产品/可交付物
      • 与产品或可交付物相关的属性
        • 合规性/关键性
          • 什么程度的过程严格性和质量保证是合适的？
        • 产品/可交付物的类型
          • 产品是否为人所知且有形之物
        • 行业市场
          • 项目产品或可交付物服务于哪个市场？该市场是否受到严格监管，发展迅速或者缓慢？竞争对手和所在企业的情况如何？
        • 技术
          • 技术是稳定且成熟，或是发展迅速且存在过时的风险？
        • 时间框架
          • 项目时间框架很短（数周或数月）还是很长时间（数年）？
        • 需求的稳定性
          • 核心需求出现变更的可能性有多大？
        • 安全性
          • 产品业务的要素是否属于保密或机密信息？
        • 增量交付
          • 这是项目团队用增量方式开发并获得干系人反馈的东西，还是在接近完成之前难以评估的？
    • 项目团队
      • 考虑的事项
        • 项目团队的规模
          • 将有多少全职和兼职人员参与项目？
        • 项目团队所在地理位置
          • 团队成员主要位于何处？部分或全部团队是远程工作还是集中办公？
        • 组织分布情况
          • 团队的支持小组和其他干系人位于何处？
        • 项目团队的经验
          • 项目团队成员在行业、组织或彼此合作方面是否有任何经验？他们是否具备所考虑项目要求的技能、工具和技术？
        • 联系客户
          • 经常及时获得客户或客户代表的反馈是否切实可行？
    • 文化
      • 考虑的因素
        • 认同
        • 信任
        • 赋能
        • 组织文化
    • 实施持续改进
      • 让项目团队参与过程改进可以培养主人翁意识，并表现出对实施持续改进和质量的承诺
      • 让项目团队参与寻找和实施改进措施也表明了对他们自己的技能和建议以及赋能的信任
      • 项目团队参与裁剪展示了创新和改进而不是安于现状的思维模式
      • 裁剪的要素包括：选择初始方法、对组织进行裁剪、对项目进行裁剪以及实施持续改进
      • 裁剪过程
• 对绩效域进行裁剪
  • 为适合项目背景而进行裁剪
  • 干系人
    • 是否有与干系人及供应商的协作环境
    • 干系人是属于组织内部或外部，或二者都是
    • 针对干系人沟通，哪些技术最合适且经济有效？可以使用的沟通技术有哪些？
    • 干系人是否使用同一种语言？是否已有所考虑，以适应来自不同语言团队的干系人
    • 现有多少干系人？干系人社区中的文化多样性如何
    • 干系人社区内存在什么样的关系？干系人或干系人群体加入的网络越多，干系人收到的信息即错误信息网络就越复杂
  • 项目团队
    • 项目团队成员的物理地点位于何处？项目团队是否集中办公？项目团队是否位于同样一地理区域？项目团队是否分布于多个时区
    • 项目团队是否反映了不同的观点和文化视角
    • 如何为项目确定团队成员？项目团队成员是全职还是兼职参与项目？是否有具备工作执行能力的承包商可供选择？
    • 项目团队是否形成已有的文化？裁剪将如何受到现有文化的影响，以及现有文化将如何受到裁剪的影响？
    • 如何为项目而管理项目团队发展？组织是否有关联项目团队发展的工具，或者是否需要建立新工具
    • 是否具备特殊需要的项目团队成员？项目团队是否需要有管多样性管理的特殊培训
  • 开发方法和生命周期
    • 对产品、服务或结果而言，合适的开发方法时哪种？如果是适应型生命周期，应采取增量型还是迭代型方法来开发项目？混合型方法是否为最佳选择
    • 对特定项目，合适的生命周期是怎样的？项目生命周期应包括哪些阶段？
    • 组织是否拥有正式或非正式的审计和治理政策、程序和指南？
  • 规划
    • 内部和外部环境因素如何影响项目及其可交付物
    • 影响持续时间的因素是什么（例如可用资源与其生产率之间的相关性）？
    • 组织是否有与成本估算和预算有关的正式或非正式政策、程序和指南？
    • 组织如何估算使用适应型方法的成本？
    • 是否只有一次主要的采购，还是需要在不同时间向不同卖方进行多次采购，而这会增加采购过程的复杂性？
    • 组织的采购政策是否参考当地相关的采购活动法律和法规？这会对合同审计需求如何影响？
  • 项目工作
    • 考虑到组织文化、复杂性以及其他项目因素，哪些管理过程有效？
    • 如何管理项目中的知识才能营造协作的工作环境
    • 在整
    • 个项目期间及项目结束时，应收集哪些信息？如何收集和管理信息？哪项技术可用于开发、记录、传输、检索、追踪和存储信息和工件
    • 未来的项目能否获得历史信息和经验教训
    • 组织是否拥有正式的知识管理数据库，项目团队需要使用而且可以随时访问该数据库？
  • 交付
    • 组织是否拥有正式或非正式的需求管理系统？
    • 组织是否拥有正式或非正式的确认和控制相关政策、程序和指南？
    • 组织有哪些质量政策和程序？组织使用哪些质量工具、技术和模板？
    • 是否存在必须遵守的行业质量标准？需要考虑哪些政府、法律或法规方面的制约因素？
    • 项目中是否存在需求不稳定的领域？如果是，应对需求不稳定的最佳方法是什么？
    • 如何在项目管理或产品开发的要素中对可持续性因素加以考虑？
  • 不确定性
    • 针对这项工作的风险偏好和风险承受能力如何？
    • 在选定的开发方法中如何最有效地识别和应对威胁和机会
    • 项目的复杂性、技术部确定性、产品新颖性、节奏或进展跟踪，这项情况的出现将如何影响项目
    • 就项目的预算、持续时间、范围或团队规模而言，是否需要采取更详细的风险管理方式？或者项目规模较小，足以证明简化的风险管理过程是否具有合理性？
    • 高水平创新、新技术、商业安排、接口或其他外部依赖关系是否需要稳健的风险管理方法？或者项目足够简单，采用简化的风险管理过程是否足够
    • 项目的战略重要性如何？因为项目旨在创造突破性机会、克服组织绩效障碍，或涉及重要的产品创新，是否导致此项目的风险级别升高
  • 测量
    • 如何测量价值
    • 是否有财务价值和非财务价值的测量
    • 在项目期间和项目完成后项目将如何进行与收益实现有关的数据采集和报告
    • 项目状态报告的要求是什么
• 诊断
  • 常见情况和裁剪建议
• 总结
  • 裁剪过程包括4个步骤
    • 选择初始方法
    • 对组织进行裁剪
    • 对项目进行裁剪
    • 实施持续改进