项目中的里程碑

里程碑（Milestones）里程碑是项目中有特殊重要性或者会触发某些事先定义功能的一类事件。

一般来说它们显示了项目各阶段或各部门间的衔接点。

在ERP中里程碑可以分配给活动（Activity）和WBS元素。

里程碑可以实现四种任务：<1>里程碑趋势分析（Milestone Trend Analysis /MTA）。

是一种控制项目进度的简单而有效的工具。

在不同报表日期，里程碑日期被用于比较分析，图形化的MTA使我们可以立刻发现项目趋势和任何的延误。

<2>使用里程碑技术的实现价值分析（Earned Value Analysis）。

里程碑技术是众多计算实现价值技术中的一种。

每一个里程碑代表了活动或WBS元素所完成的这部分工作。

<3>决定开票计划的日期。

将里程碑和开票计划的日期相连。

当项目进度到达某个里程碑时，里程碑的实际日期将被自动复制到开票计划中。

<4>触发预定义的里程碑功能。

我们可以利用里程碑触发一系列事件来处理某些特定的业务流程。

在ERP项目结构的建立中有两种可以增强工作效率的功能：<1>标准项目结构和复制功能。

<2>图形功能。

项目里程碑制定常见步骤项目管理在生活和工作过程中越来越受到重视，我们现在强调科学的管理一个项目，系统地思考问题。

一个好的组织要有战略管理和项目管理来相互支持，战略管理强调做正确的事情，项目管理强调把事情做正确，那么在项目管理过程中我们就要按照好的思路来进行。

里程碑是项目管理不可忽视的一部分，里程碑是项目中的重大事件，在项目过程中不占资源，是一个时间点，通常指一个可支付成果的完成。

编制里程碑计划对项目的目标和范围的管理很重要，协助范围的审核，给项目执行提供指导，好的里程碑计划就像一张地图指导您该怎么走。

编制里程碑计划最好是由项目的关键管理者和关键项目干系人召开项目启动专题会议共同讨论和制定，并不是由一个或者少数几个人拍脑袋来确定，里程碑目标一定要明确。

通过这种集体参与的方式比项目经理独自制定里程碑计划并强行要求项目组执行要好得多，它可以使里程碑计划获得更大范围的支持。

一般启动专题会议参会人数不应超过6人，人太多了不利于意见的统一。

编制里程碑计划的具体步骤一般如下：①认可最终的里程碑：要求参会人员一致认可最终的里程碑，并取得共识。

这项工作在准备项目定义报告时就应完成。

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

③审核备选里程碑：得到的所有备选里程碑，它们中有的是另一个里程碑的一部分；有的则是活动，不能算是里程碑，但这些活动可以帮助我们明确认识一些里程碑。

当整理这些里程碑之间的关系时，应该记录下您的判断，尤其是判定那些具有包含关系的里程碑时。

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

⑤用连线表示里程碑之间的逻辑关系：用连线表示里程碑之间的逻辑关系是从项目最终产品开始，用倒推法画出它们的逻辑关系。

这个步骤有可能会促使您重新考虑里程碑的定义，也有可能是添加新的里程碑、合并里程碑，甚至会改变结果路径的定义。

⑥确定最终的里程碑计划，提供给项目重要干系人审核和批准。

然后把确定的里程碑用图表的方式张贴在项目管理办公室，以便大家时时能把握。

经过以上的6个步骤，您可以确定最终的里程碑了。

将它挑选出来并纳入计划，您的里程碑计划编制工作就完成了。

以上是编制里程碑计划常用的步骤，但是由于项目的唯一性和独特性特点，我们在实践中不要拘泥于形式，灵活运用即可。

在项目管理中，里程碑管理是一个具有特定重要性的事件，通常代表项目工作中一个重要阶段的完成。

在里程碑处，通常要计划进行检查。

里程碑管理实际上很象是项目管理中的节点管理，如果将胎儿怀孕过程看作一个项目，那么里程碑管理就像定期做超声波检查，在什么月份，婴儿应该发育了哪些器官，揭示出胎儿发育项目的状况，因而制定采取可能的应对措施。

1.特性A.横向性里程碑管理是和项目管理中的九大管理模块不同的是，它是一种重要的项目管理方法，它具有横向性，不同的项目领域有不同的里程碑管理，但不论是哪个领域的里程碑管理都无例外的具有横向性。

B.相对宽泛的时效性是根据不同的项目特点确定里程碑管理的时效性，但是每个里程碑都有相对的时间点，但却不向项目中每个任务有严格的时间点或间隔，在实际项目管理的里程碑管理的实际操作中往往都有相对较宽松的时间要求，一般在电子产品的项目中至少有一个星期的可灵活掌握里程碑的审核会议的召开时间。

项目管理培训C.非强迫性项目管理论坛不是所有的里程碑的流程都规定，如果里程碑管理审核中错在重要的风险，项目必须暂停或终止，有的里程碑管理的审核一般是由项目经理发起的，但不是所有的项目经理都有权叫停项目，所以有些项目不管里程碑审核出风险有多大，对项目的进程甚至无关痛痒。

2.心得和实际应对几乎所有的项目管理流程都设置了里程碑管理的节点和检查表，但很多在实际工作中项目中里程碑管理都或多或少的被忽视了。

原因主要有以下几点a.流程不清，并不是所有的项目管理都清晰定义了什么条件下用开里程碑管理会议，有时设置了几个条件，但可能其中的一个或几个条件因某个项目的特殊性可能一段时间内或整个项目周期内都无法满足，因而对里程碑审核的延误或者取消。

b.不被重视；几乎所有的里程碑管理的设置时都将所有利益相关人设置为会议参加人员，但在实际会议中召开时，经常出现关键人员到不齐，项目经理不得不将里程碑会议根据一拖再拖，甚至最后不了了之，这种现象在组织项目管理的弱矩阵中出现的更加频繁，当然也和项目经理在会前的沟通也有一定的关系。

c.项目的风险意识不足文章项目利益干系人对里程碑管理的认识不足，对里程碑管理是项目管理的风险管理的意识不足。

以下对实践中的这几点原因作一些浅析的实际的应对的方法分析1.对于流程分析，在有些项目管理流程中，里程碑管理的往往定义在某个时间之后，如在拿到客户的订单后项目经理召开里程碑1的会议，但往往对之后多长时间没有完全的定义，对里程碑的会议清晰的定义为某一个事件前的一星期之内必须有项目经理召开，如手机配件项目的硬模前，注意，最好将里程碑的管理会议定在某个时间之前，而非之后，有可能的话作为下个时间的输入条件。

2.对项目干系人对风险的重视和里程碑管理的重要性，不是所有的干系人都能意识到它的重要性和对项目风险的控制，甚至有的项目经理也认为里程碑管理可有可无，甚至有意无意的忽略的过程。

这和项目经理职业精神和及其干系人对项目风险的识别的态度和里程碑管理的人相关制度也有一定的关系；当然和项目经理的沟通技巧尤其和项目干系人的沟通技巧也有一定的关系，保持正式的和非正式的和项目的发起人和客户沟通是非常必要的。

3.这里再次浅析里程碑管理在项目管理中的风险预防的作用项目管理培训在一些项目中，会经常看到项目经理忙于救火，尤其在一些量产的项目中接近量产爬坡的阶段，来自客户和内部各部门的压力均会增大，项目经理抱着电话，总会被优先级更高的急事打断，当然其中有项目经理的管理方法和经验有关，但和项目的风险管理有很大的关联。

里程碑管理实际上是将项目风险分段检测的方法，是用来降低项目整体风险，精项目风险提前检测和提前释放的项目风险管理方法。

里程碑管理很象是一把手术刀适时地切开项目的横截面来对项目进行的剖析，以对症下药的手段。

里程碑的管理会议其实应该是专家诊断会。

总之，不是说所有的项目风险都会被里程碑管理所识别，但它至少可以减少项目的大部分的风险，降项目的可能的损失减少到最小，项目经理在项目的管理过程中可以通过里程碑管理降低项目风险，优化项目资源输出的途径，减少项目成本。

建立项目里程碑偶尔跟一些业内人士交流，发觉部分人士对『里程碑』的作用与如何建立里程方面有很大的意见差异，难怪一些技术人员对工作分解架构（WBS）感觉困扰。

当我们在路上行走的时候，会在沿途观看路标，当到达某一个心目中的路标时，我们便知道还有多少路或多少时间才能够到达终点。

这些路标是我们在旅程中的里程碑，让我们可以清楚地知道目前所在，离开目的地有多远，让我们能估算何时才能够到达目的地。

让我们利用硬件供应商或渠道商的供应里程碑来作一个简单的说明，硬件装钳完成后或收到厂家运到的产品时便是一个里程，把商品送到客户办公室让客户签收后便是另一个里程，安装测试后让客户验收便成为最后一个里程。

完成这三个里程后便知道项目已经完结。

软件开发的里程碑当进行软件开发的时候，我们也需要建立开发项目的里程碑，才能够知道本身的进度，但最重要的是里程碑可以用来建立收费的关口。

为什么有这个说法呢？软件开发服务的企业，往往在签订协议时收取一笔定金，然后需要支付数月所需的开发组员薪资，而且软件开发服务商往往未能在指定时间内完成开发的项目，各种原因导致项目延误，那么便需要企业应用本身的流动资金来应付。

为什么客户往往在签订协议后，付了首期定金，然后到项目差不多完结的时候才再支付一部分，但还是扣起部分款项到维护期后才把余款付给服务商。

这可能需要好长的一段时间才能够把余款收回。

其中一个主要原因是因为客户在开发过程中看不到里程碑，对能否达到预期的目标没有信心。

哪里才算里程碑？如何才算是一个里程碑呢？简单的说是到达一个阶段可以让客户看到部分结果的地方。

就以软件开发为例（如左图），要开发一套软件，我们需要经过一定的流程或阶段。

分别为信息搜集、需求分析、系统设计、系统开发、系统测试。

但只有四个阶段产生交付物，分别在信息搜集阶段后将产生一份《需求说明书》、在需求分析后产生一份《功能说明书》、在系统设计阶段后产生《系统逻辑说明》及《DFD（Data Flow Diagram）图》、和在系统测试阶段后产生《测试报告》。

每一份交付物的完结说明我们已经完成了一个阶段的工作，在客户确认这一份工作成果后我们才进入下一个阶段的工作。

每一份交付物将是整个系统开发过程中的『里程碑』。

所以里程碑的建立必需连带交付物，而这交付物必需让客户确认。

当客户确认我们的交付物后，也是客户确认我们已经在系统开发的过程中到达某一个指定的阶段，完成某一部分的工作。

确认里程碑的交付物当我最初执行项目管理的时候，往往把交付物送交客户确认后，两三各星期下来都没有回应，不断跟进也没有多大的进展，相信很多从业人员往往会说『客户需要太长的时间来进行确认，将影响项目的进度』。

又或者会说『客户不会确认过程中的任何交付物，因为。

（很多理由和原因）。

』！这便是一个项目经理的经验问题，而不是客户会不会、或者愿意不愿意确认的问题。

当我们进行项目启动集会的时候，项目经理便应该跟项目赞助人很明确地说明“确认”项目过程中所产生的交付物的重要性，同时更应该清楚地说明交付物在没有确认前将不能够开展下一阶段的工作，在没有得到客户确认一个阶段的交付物时，继续开展下一阶段的工作对项目会带来莫大的风险，因为任何的工作都可能被客户推翻，可能变成废物，或需要不断进行修改。