规划项目里程碑-说明介绍

追踪项目最重要的里程碑，并通过邮

件提醒使您更好的追踪项目进程。

项目里程碑(milestone)并没有形成统一的定义，但是各个定义的核心基本上都是围绕事件(event)、项目活动(activity)、检查点(checkpoint)或决策点，以及可交付成果(deliverable)这些概念来展开的。

里程碑是项目中的重大事件，在项目过程中不占资源，是一个时间点，通常指一个可支付成果的完成。编制里程碑计划对项目的目标和范围的管理很重要，协助范围的审核，给项目执行提供指导，好的里程碑计划就像一张地图指导您该怎么走。

里程碑目标一定要明确。通过这种集体参与的方式比项目经理独自制定里程碑计划并强行要求项目组执行要好得多，它可以使里程碑计划获得更大范围的支持。完成阶段性工作的标志，不同类型的项目里程碑不同。里程碑在项目管理中具有重要意义。

项目里程碑

1、认可最终的里程碑：要求参会人员一致认可最终的里程碑，并取得共识。这项工作在准备项目定义报告时就应完成。

2、集体讨论所有可能的里程碑：集体讨论所有可能的里程碑，与会成员通过头脑风暴法，把这些观点一一记录在活动挂图上，以便选择最终的里程碑。

3、审核备选里程碑：得到的所有备选里程碑，它们中有的是另一个里程碑的一部分；有的则是活动，不能算是里程碑，但这些活动可以帮助我们明确认识一些里程碑。当整理这些里程碑之间的关系时，应该记录下您的判断，尤其是判定那些具有包含关系的里程碑时。

4、对各结果路径进行实验：把结果路径写在白板上，把每个里程碑各写在一片“便事贴”上，按照它们的发生顺序进行适当的调整和改变。项目管理培训

5、用连线表示里程碑之间的逻辑关系：用连线表示里程碑之间的逻辑关系是从项目最终产品开始，用倒推法画出它们的逻辑关系。这个步骤有可能会促使您重新考虑里程碑的定义，也有可能是添加新的里程碑、合并里程碑，甚至会改变结果路径的定义。

6、确定最终的里程碑计划，提供给项目重要干系人审核和批准。然后把确定的里程碑用图表的方式张贴在项目管理办公室，以便大家时时能把握。

经过以上的6个步骤，您可以确定最终的里程碑了。将它挑选出来并纳入计划，您的里程碑计划编制工作就完成了。以上是编制里程碑计划常用的步骤，但是由于项目的唯一性和独特性特点，我们在实践中不要拘泥于形式，灵活运用即可。[1]

项目里程碑管理：管理项目里程碑信息，这些信息以短信或页面提醒的方式通知项目组成员，确保不遗漏重大事项。

第一，里程碑管理框架通过关键的里程碑决策点，将企业的市场产品线规划MPP和新产品开发SPD两个核心业务过程划分为商业计划开发、投资计划、项目定义、项目实现和项目交付收口五个阶段进行管理。

第二，里程碑管理框架持续跟踪分析客户需求和市场情况，采用市场驱动、工程实现的项目运作机制，着重加强市场产品线规划过程与产品开发过程的信息沟通，使开发的目标系统和产品更符合市场需求。

第三，里程碑管理框架整合了企业的市场、工程、项目管理和制造等一系列业务活动过程，建立了一套规范一致的软件项目过程管理体系，它具有前瞻性的过程管理机制，能够帮助识别并选择最好的解决方案。

第四，里程碑管理框架在设计上符合CMM的要求，是一个可以不断进化和持续改进的管理体系。作为一种具体的软件项目过程管理方法，里程碑管理框架填补了CM M在这方面研究的空白。同时，将里程碑管理框架与CMM结合在一起实施，能有效地提高企业的软件过程能力和成熟度等级，能够帮助软件企业通过CMM等级评估认证。

应用里程碑管理框架，能对国内软件企业原有的项目管理过程模式进行改造，能够有效克服旧的管理方式在商业计划、投资计划、需求基准、工作量预估、项目计划、成本控制和质量保证等方面存在的缺点。在应用里程碑管理框架对软件项目管理过程进行改造时，可能会遇到阻力或进入误区，因此本文又针对这些问题，对过程改造的原则、策略、准备工作、保障措施、实施计划、日程安排和实施步骤进行了探讨，为企业实施软件项目管理过程改造提供了一个参考方案。

一、可重现性：可重现性指的是有能力准确回到一个先前的软件版本。回到先前的版本有助于重现历史版本中的BUG 以协助排错，并在历史版本的基础上开发对应的补丁；在最新版本中发现问题时，回到历史版本可以帮助判断新发现的问题到底是在历史版本中业已存在（只是当时未发现）还是仅仅在新版本中引入；同时维护多个版本、针对不同版本进行本地化、扩展的也要求准确回到历史版本。

二、可追踪性：可追踪性保持项目需求、项目计划、测试用例等与源代码之间的一致性，为实现可追踪性，要求不仅对源代码进行配置管理，对项目需求、项目计划、测试用例等也要进行配置管理，并对所有工件统一进行基线管理。

三、配置状态报告：有了适时创建的基线，就可以查询、报告、比较基线的内容，尤其是基线的比较能力对于排错、为新的发布生成准确的发布说明文档（Release N otes）等非常有帮助。除了在项目里程碑（如使用迭代化开发模式，则在每次迭代结束前）创建基线外，实际上基线的创建要频繁得多。在典型的情况下，在每次迭代的后期或软件发布的前期，甚至每天都会创建新的基线。

项目里程碑

（1）项目工期情况

关键路径是否按计划完成了？

如果没有按计划完成：

提前或拖期的原因是什么？

在后续阶段如何采取改进措施？

对后续阶段的工期有什么影响？

（2）任务进展情况

计划完成的任务情况：

计划完成的任务有哪些？

提前完成的有哪些？提前完成的任务工作量有多少？

未完成的任务有哪些？未完成的任务工作量有多少？

（3）工作量投入

计划投入工作量、实际投入工作量、挣值、计划与实际工作量的偏差分析、后续的投入工作量预测

（4）质量

在本阶段通过测试与同行评审发现的缺陷个数、缺陷密度、缺陷的趋势分析、缺陷的分类、缺陷的关闭情况等等。通过上述的质量分析，判断本阶段的工作产品的质量情况，以决定是否要采取相应的质量措施加强质量管理。

（5）需求变更

需求变更了几次？

需求变更带来的工期与工作量变化是多少？

需求变更的工作量/项目的估计总工作量。

（6）规范符合性

对哪些过程执行了审计？

对哪些工作产品执行了审计？

审计出了多少问题？这些问题是否都关闭了？

问题的统计分析及原因分析？

拟采取的改进措施有哪些？

（7）配置项的变化情况

建立了哪些基线？

基线中包含了哪些配置项？

基线变更过几次？

基线审计出的问题是否关闭了？

（8）风险评估

识别了并已发生的风险有哪些？