源贴地址：http://tech.ddvip.com/2008/11/122707900293572.html
偶尔跟一些业内人士交流，发觉部分人士对『里程碑』的作用与如何建立里程方面有很大的意见差异，难怪一些技术人员对工作分解架构（ WBS ）感觉困扰。
当我们在路上行走的时候，会在沿途观看路标，当到达某一个心目中的路标时，我们便知道还有多少路或多少时间才能够到达终点。这些路标是我们在旅程中的里程碑，让我们可以清楚地知道目前所在，离开目的地有多远，让我们能估算何时才能够到达目的地。
让我们利用硬件供应商或渠道商的供应里程碑来作一个简单的说明，硬件装钳完成后或收到厂家运到的产品时便是一个里程，把商品送到客户办公室让客户签收后便是另一个里程，安装测试后让客户验收便成为最后一个里程。完成这三个里程后便知道项目已经完结。
软件开发的里程碑
当进行软件开发的时候，我们也需要建立开发项目的里程碑，才能够知道本身的进度，但最重要的是里程碑可以用来建立收费的关口。为什么有这个说法呢？
软件开发服务的企业，往往在签订协议时收取一笔定金，然后需要支付数月所需的开发组员薪资，而且软件开发服务商往往未能在指定时间内完成开发的项目，各种原因导致项目延误，那么便需要企业应用本身的流动资金来应付。
为什么客户往往在签订协议后，付了首期定金，然后到项目差不多完结的时候才再支付一部分，但还是扣起部分款项到维护期后才把余款付给服务商。这可能需要好长的一段时间才能够把余款收回。其中一个主要原因是因为客户在开发过程中看不到里程碑，对能否达到预期的目标没有信心。
哪里才算里程碑？
如何才算是一个里程碑呢？简单的说是到达一个阶段可以让客户看到部分结果的地方。就以软件开发为例（如左图），要开发一套软件，我们需要经过一定的流程或阶段。分别为信息搜集、需求分析、系统设计、系统开发、系统测试。但只有四个阶段产生交付物，分别在信息搜集阶段后将产生一份《需求说明书》、在需求分析后产生一份《功能说明书》、在系统设计阶段后产生《系统逻辑说明》及《 DFD （ Data Flow Diagram ）图》、和在系统测试阶段后产生《测试报告》。每一份交付物的完结说明我们已经完成了一个阶段的工作，在客户确认这一份工作成果后我们才进入下一个阶段的工作。
每一份交付物将是整个系统开发过程中的『里程碑』。所以里程碑的建立必需连带交付物，而这交付物必需让客户确认。当客户确认我们的交付物后，也是客户确认我们已经在系统开发的过程中到达某一个指定的阶段，完成某一部分的工作。
确认里程碑的交付物
当我最初执行项目管理的时候，往往把交付物送交客户确认后，两三各星期下来都没有回应，不断跟进也没有多大的进展，相信很多从业人员往往会说『客户需要太长的时间来进行确认，将影响项目的进度』。又或者会说『客户不会确认过程中的任何交付物，因为。。。。（很多理由和原因）。。。』！这便是一个项目经理的经验问题，而不是客户会不会、或者愿意不愿意确认的问题。
当我们进行项目启动集会的时候，项目经理便应该跟项目赞助人很明确地说明“确认”项目过程中所产生的交付物的重要性，同时更应该清楚地说明交付物在没有确认前将不能够开展下一阶段的工作，在没有得到客户确认一个阶段的交付物时，继续开展下一阶段的工作对项目会带来莫大的风险，因为任何的工作都可能被客户推翻，可能变成废物，或需要不断进行修改。这不但浪费组员的时间及士气，更严重地延误项目的进度，延误项目的最终交付，导致项目的超时、超支。
明确的沟通
在启动集会中我们更应该透明化。应该很详细地让项目赞助人及其他参与集会的项目涉及人清楚地理解项目的整个流程和进度时间计划。让他们对项目的运作有初步的认识和了解，好能跟项目小组互相配合。同时更需要采用各种不同的软技巧（参阅“项目管理技巧新探”）来让客户依时确认交付物，让我们能够进入下一阶段。
当客户确认我们所提交的交付物后，便是客户同意我们已经完成了某一个阶段的工作，如果我们在合约谈判的时候把服务收费时间按项目交付物来让客户支付，那么我们不但能够有助企业的资金流动，更不用为收费的事情因项目的延误跟客户发生争执。故此在项目建立的初步阶段，我们便应该建立有关项目的里程碑和工作架构分解。让我们能更有效的管理项目的进度。