项目管理的目标
项目管理的目标是：在项目需求和约束（Constraints）的上下文中，识别、确立和控制项目产出产品所必要的资源和活动。
基础实践
BP1: 定义工作范围
识别项目目标、动因和项目边界。
说明
- 通过识别项目边界和项目约束来定义项目范围
BP2: 定义项目生命周期
定义符合项目范围、环境、量级和复杂度的生命周期。
NOTE 1: 这通常意味着项目生命周期和客户的开发过程互相保持一致。
说明
- 要根据项目环境、复杂度、量级等因素定义合理的项目生命周期。例如，项目复杂度和量级比较大，可能会划分更多的阶段。
- 项目声明周期模型与开发过程保持一致
BP3: 评估项目可行性
根据在时间、项目估算和可用资源等约束下的技术可行性评估达成项目目标的可行性。
说明
- 项目可行性不单单是技术层面的可行性，还需要综合考虑项目时间、成本、资源等因素。
BP4: 定义、监控和调整项目活动
依据已定义的项目生命周期和项目估算，定义、监控和调整项目活动和活动间的依赖关系。调整项目活动以及他们的依赖关系是必需的。
NOTE 2: 结构化并且可管理粒度的活动及相关工作包有助于支持充分的进度监控
NOTE 3: 项目活动通常会覆盖工程管理和支持过程
说明
需要明确活动间的依赖关系，例如A和B两个活动，典型的依赖关系如:
- FS：A的开始依赖于B的完成
- FF：A的完成依赖于B的完成
- SS：A的开始依赖于B的开始
- SF：A的完成依赖于B的开始
活动和活动间的依赖是基于监控结果不断进行调整的过程，持续的项目监控和变更会导致项目活动及其依赖关系的调整。活动最小粒度定义建议不要低于一天，一般从1天到两周以内。活动粒度太大、周期太长会导致风险增加。活动粒度太小，活动数量过多会导致管理的复杂度上升。
BP5: 定义、监控和调整项目估算和资源
基于项目目标、项目风险、动因与项目边界，定义、监控和调整项目工作量估算和资源。
NOTE 4: 应当使用合理的估算方法
NOTE 5: 必要的资源例如人、基础设施（例如工具、测试设备、沟通机制等）和硬件、原材料等。
NOTE 6: 需要考虑项目风险 (使用MAN.5) 和质量标准 (使用SUP.1)
NOTE 7: 估算和资源通常包括工程、管理和支持过程。
说明
- 工作量估算和资源一般是在WBS层级开始，然后下降到分解的活动层级。
- 资源包括项目预算、人力资源和基础设施，需要注意的是人也是一种项目资源，而敏捷中更看重个体因素。
BP6: 确保必需的技术、知识和经验
识别符合项目估算所须的技术、知识和经验，并确保所选择的个体和团队已经具备或能够及时获取这些技能、知识和经验。
NOTE 8: 鉴于所需的技术和知识的偏差，通常要提供培训
说明
- 明确要完成项目所需的技术、知识和经验，并构建具备这些能力的团队。即使团队当前不具备，至少要保证团队能够及时获取这些技术、知识和经验。
- 团队获取技能、知识和经验的方式很多，例如外部培训、企业内部的项目团队交流、成功的类似项目的经验教训汲取、团队内部调研学习等等。但是不论是哪种方式，要在可控的时间内获取所需的技能。
BP7: 识别、监控和调整项目接口以及达成一致的承诺
识别项目与其他项目、子项目、组织单元以及其他受影响的干系人之间的接口并达成一致，并监控达成一致的承诺。
NOTE 9: 项目接口涉及工程、管理和支持过程
说明
- 识别、监控和调整构成一个闭环，是一个持续的、动态的过程
- 达成一致的承诺需要被记录，例如邮件或系统工具等。
BP8: 定义、监控和调整项目排期
为项目活动分配资源，并对整个项目的所有活动进行排期，排期在整个项目生命周期中保持持续更新。
NOTE 10: 这涉及工程、管理和支持过程。
BP9: 确保一致性
确保项目的估算、技能、活动、排期、计划、接口和承诺在相关方之间保持一致。
BP10: 评审和报告项目进度
定期评审，并给所有相关方报告项目状态和项目活动基于预估工作量和时长完成情况。防止已识别的问题重复出现。
NOTE 11: 管理人员周期性的进行项目评审。 在项目结束时， 项目评审有助于识别比如最佳实践和可汲取的经验教训。
工作产品
- 项目计划
- 沟通记录
- 变更请求
- 评审记录
- 纠正行动记录表
- Schedule
- WBS
- 干系人列表
- 项目状态报告
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。