里程碑
1994年，美国Standish Group对于IT行业8400个项目（投资250亿美元）的研究结果表明：项目总平均预算超出量为90％，进度超出量为120％，项目总数的33％既超出预算，又推迟进度，在大公司，有9％的项目按预算、按进度完成。1999年系统分析员考试下午I试题的第一题也是类似的话题。
造成项目周期拖延或费用超过预算的原因很多，但没有好的阶段和里程碑划分无疑是其中最重要的原因。下面的图可以形象地说明这一点：
图中，项目的成功需要走很长的路程，从开始到成果完成之间并没有现成的路可走（项目的一次性），如果项目经理追求一步到位而不做阶段划分，因为距离目标太远，难免走不少的弯路还不容易觉察（不好比对），当感觉到偏离目标的时候再进行校正便走了很多的弯路，校正后可能又偏离到另外一个方向，同样不易觉察，如此反复，便形成图中这条蓝色的轨迹。如果把项目的实施过程分为若干个阶段，每个阶段都有标志性里程碑，那么，每个阶段都有明确的目标，虽然每个阶段仍免不了走弯路，但由于目标相对较近，不至于绕很大的弯子，这样便形成图中红色的轨迹。显然，这两条轨迹的长度是不相同的，蓝线比红线要长出很多。这意味着什么？意味着前者比后者要多花很多费用和时间！意味着项目费用超出预算和进度大大拖延！ 做项目的人很容易成为温水里的青蛙，在不知不觉中被置于死地，要时刻警惕近期目标不明的风险。
◆ 过程评审
项目的过程评审是质量保证的重要环节，一个很简单的道理--质量是做出来的而不是查出来的。以软件项目为例，软件的可靠性取决每个模块的可靠性，模块的可靠性在模块的的概要设计、详细设计、编码、测试等环节铸成。我认为软件项目需要项目组成员有最求完美的精神和闻过则喜的境界，因为软件是人做的，人总有疏忽的时候，在开发过程中，即使追求完美做出的软件还不可避免的存在缺陷，才勉强达到可以使用的水平；不用最求的精神开发的软件，很可能就不能使用。
下面是一个软件的缺陷产生阶段、缺陷修改阶段以及修改成本间的关系图，图中表明，缺陷被发现并修改越晚，修改的代价越高。需求分析阶段造成的缺陷在产品发布后修改所要付出的代价是该问题在需求分析阶段就能及时修改所付出代价的50－200倍！这仅仅是一个统计结果，实际上，有些损失再发布了以后是无法挽回的，Windows2000的冲击波漏洞所造成的损失就是如此。
过程评审的意义就在于及时发现问题，及时纠正，阶段评审不仅是为了保证质量，还可以达到控制项目成本的作用。CMM二级就有一个关键过程域叫SPTO（Software Project Tracking and Oversight），强调过程的跟踪与监控，遗憾的是，不少开发人员认为阶段评审浪费时间，草草了事，却愿意花很多的时间修改BUG！华为公司规定在过程评审和代码监视中没有评审发现的评审是无效评审，评审要重新进行。
随着市场的规范和业主的成熟，建筑项目的监理制度也逐渐被IT项目所采纳，这是社会的进步，项目管理中称为第三方项目管理。
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
