转载地址:http://blog.csdn.net/craftsman1970/article/details/8795007
在原文基础上有一些小修改。
本文中的绝大部分都来自原著。想知道更详细的信息，强烈推荐大家读原著。
第一个问题：虽然在项目中加入了大量的安全时间，但项目还是会延期
项目一般都存在以下的问题。
- 1）成本超出预算
- 2）时间超出期限
- 3）项目的规模或设计内容被牺牲。
在项目失败时，正式的解释都说是其他人的错，，如天气，供应商，环境等等（事业环境因素）。
但是项目经理给出的原因往往是
-
1)公司高层制定不切实际的日程
-
2）公司因为成本而选择不可靠的供应商。
-
3）组件项目团队太晚。
项目经理的下属提出的原因：
-
1)过分依赖进展报告，事后才发现所报资料不正确。
-
2）监管不足。
-
3）项目组成员频繁的被调派去处理各种突发事故。
-
4）太多无谓的’协调会议‘阻碍项目的进展。
所有问题都有一个共同点，就是它们都是其他人的错，我们听见的都是互相攻击。员工的地位越低，矛头越是指向公司内部，而不是外部。
有一点可以肯定，就是我们不应该忽视低层经理的申诉。如果他们说的是对的，那就是说，大部分错误就出自公司内部。换言之，公式内部应该是可以把项目管理得更妥善的。
当然我们我不能忽视公司高层的的意见。他们提出的问题都是一些不确定因素，一些在项目开始时难以预料的东西。
不确定因素是所有项目的典型特征。是这头野兽的本性。如果回头再分析一下项目经理提出的投诉会发现，它们也都是围绕着一些不确定因素。
这些因素直接影响项目估算的方式和结果。
如果我们画一条估算时间和完成概率之间关系的曲线，基本上会像下图一样。之所以后面的部分比较长是因为上面提到的不确定因素。不确定因素越高，分布图的尾巴就会越长。
概率中间值的位置表示项目只有50%的机会在预定时间之前完工。
提前完工不会获得奖赏，但延误却需要层层解释。为了避免风险,大多数项目估算时会画马可画的那条线(马可是书中人物),也就是说，为了8成，9成的成功机会，加进了几乎200%的安全时间。
结论：项目中，不确定因素是大部分问题的主要根源，所以人们为此增加了很多安全时间作为保障。这个问题值得深入讨论。
项目的安全时间是怎么进入估算中的呢？
一：预估时间是根据以往惨痛经历来制定的，即分布曲线的·最末端。
每个领班都会说“如果”万事具备，那么准时完成它负责的部分并不困难，虽然他们不会用概率表达，但大概也有8，9成以上机会。但是同时都会强调：他们的答案是基于两个假设：
1）他们不被其他人连累而导致延误
2）同一时间没有太多工作要他们分心。
二：涉及管理层越多，完工时间预估会越长，因为每层都会加进各自的安全因素。
每当任务由多个步骤组成，而步骤由不同的人负责时，项目负责人变回要求每人做出各自的完工时间预估，加起来以后他会在加紧自己的安全时间.如果一个人预估他的任务需时5天，下一个任务也需时5天，项目负责人会说总共需时13天。
三：预料到高层会削减整体完工时间，各人预先加大安全时间
如果公司高层一半都会在要求削减项目所需时间，比如削减两成，那么大家就会在一开始便把预估加大两成半。
将以上的安全时间通通加起来，安全时间必然占项目预估完工时间的绝大部分。但为什么项目还是不能如期完成呢？
那是因为同样有三个因素到时安全时间被毫无意义的消耗掉。
假设有两个连续的步骤，预估时间都是10天。如果第一个步骤实际上用了12天，那么第二个步骤就会推迟2天开始。但如果第一个步骤提前2天完成的话，第二个步骤并不会提前两天开工。原因大致有如下几个：
1）提前完工不但不会带来奖赏，而且可能导致老板削减预估时间。
2）为下一个步骤分配的资源无法到位。
3）下一步骤的人清楚的知道时间是足够的，不会急于开工。
一个步骤的延误会全部转嫁到下一个步奏，而提前完工赚得的时间通常会被浪费掉。
同样，当有多个步骤并行的时候，当中最大的延误会被转嫁至下一个步奏，但当中任何提前完工（节约的安全时间）却完全起不了作用。
没有可以保护每个步骤的安全时间。
这个问题有一个深层次的原因：学生症候群。(十万个为什么：帕金森定律有是一个意思)
十万个为什么：如果项目中出现了下面的情况，多半就是安全时间被浪费掉了。
1）担当者有时忙有时闲
2）很多步奏就正好在预估的时间完成，分毫不差。
还有一个就是多任务，这大概是安工时间的最大杀手。让每个项目都吃尽了苦头，称它为开会，紧急事故或其他任务，影响仍是一样。都会导致完工时间大大膨胀。
所以结论是以下三种原因会令早完工所赚得的时间付诸流水。
一：学生症候群-不用急，到最后一刻才动工
二：多任务
三：各步奏之间的依存关系令延误累积
另外一个问题：关键路径于非关键路径
考虑下面的例子。
很明显，【兴建建筑物->发挥各种功能->在建筑物内安装各种机器】是关键路径，共需150天。由于关键路径决定了整个项目的完工期，关键路径上的任何延误都会延误整个项目，所以项目经理一定要特别留意它。
这里的问题是另一条路径挑选供应商，应该在什么时候开始呢？
方案1：晚开始
优点:可以推迟投资（实际上包括钱，物，人等各个方面）。
缺点:一旦延误,影响整体进度
方案2：早开始
优点:规避风险，避免由于非关键路径上的延迟引起关键路径的延迟。
缺点:项目经理同时应付多个初期任务,疲于奔命。这一点考虑应该远比押后投资更重要。
如果项目经理采取早的起步日期，他们就无法专注，如果采取迟的起步日期，专注也根本不可能。必须有方法解决这个问题。问题似乎钻进了死胡同。
我们需要一个控制机制来让项目经理保持专注。其实项目都有控制机制用来衡量项目的进展，但问题是，等到进展报告显示有麻烦时，通常已经太迟了。比如说：进展报告会说：花了一年时间，项目的90%都完成了，而剩下的10%有需要整整一年。
在几乎所有的项目中（即使是有里程碑的项目），使用的衡量方法都没有把关键路径和非关键路径区分开来。这种方法会鼓励尽早启动每条路径，从而导致项目经理从醒目的最开始就不能专注了。因为根据这种衡量方法，一条路径取得的进展，会补偿另一条路径的延误，这实际上就是鼓励一条路径快速进展，虽然另一条路径正被延误。因为这些路径最终会合拢，导致其他路径上赚取的进展，最终都要等待那条延误的路径。
这就是为什么无数的项目需要那么长的时间才能完成最后的10%。
原因就是我们在衡量项目进展时，忽视的关键路线的重要性！
为了解决上述问题，本书中引入TOC五步法。
步骤一：识别制约因素
在一个项目中，制约因素就是关键路径
步骤二：决定怎样挖尽制约因素的潜能
不浪费关键路径上的时间，因为关键路径上的任何延误都会拖累项目。
对策是把每个步奏的预估时间削减，这样就可以释放出足够的时间来建立一个项目缓冲。比如说把每个步骤的时间减少一半，然后将减少的时间的一半作为项目缓冲
步骤三：其他一切都迁就制约因素
只有这样才能真正挖尽制约因素的潜能。不懂得迁就，其他路径遇到的麻烦便会直接连累制约因素，令他损失时间，换言之，没有好好保护制约因素。
迁就制约因素的方法就是在每条接驳路径与关键路径回合的地方插入时间缓冲，即接驳缓冲。方法就是在每条接驳路径上，将各步骤原来的预估时间减少一半。然后将减少的时间总和的一半作为该路径的接驳缓冲。
另外，在某些时候，关键路线上的步骤准备就绪，唯独欠缺相关资源，因为他正忙着其他事情。为了避免这类冲突，可以使用资源缓冲。
步奏四：将制约因素松绑
步骤五：回到步骤一
怎样衡量缓冲
使用新的计划方法以后，取得了以下的效果：
1）不会只是因为下属没有工作做就催逼他人。
2）不在需要里程碑。
3）不在有拖延。要么不启动一个步骤，要么在可以动工的时候以最高速度执行步骤。学生症候群消失了。
4）由于有相当大的机会不能完工，所以当项目经理关注某个步奏时，更容易被理解。
5）免除警钟误鸣即缩短每个步骤的时间对减少多任务也有好处。
关于资源缓冲，虽然不能为了保护关键路径而让资源在工作开始前一周（比如说）就待命，但是可以在关键路径的工作开始之前发出警号。提醒人们将要到关键路径上工作。最重要的一点是让人们知道，他们必须放下手头所有工作，转而执行关键路线上的工作。
在使用这种方法以后，对项目的监控就以以下方式进行：
1）对于关键路径就监控项目缓冲，对于非关键路径就监控接驳缓冲。
2）是用百分比方式还是绝对时间作为衡量标准并不重要。（因为需要监控的清单应该非常短）
3）监控对象不包括尚未开工的步骤，也不包括已经完工的步骤。
新方法的要点：
1）说服各部门消减他们的预估完成时间。
2）消除所有的里程碑，换言之，个别步骤不再有目标完工日期（duedates)
3)适时报告完工预估时间
项目延期对于公司的影响绝不是增加在项目团队上的开发经费，而是公司因为产品推迟上市而少获得的利润以及失去的市场份额。
关键链诞生了
当项目按照前面的方法进行监控时，会碰到一个问题。
假设其中一条非关键路径(比如3号)进展的实在太慢了，会令整个接驳缓冲耗尽，并已经开始影响了项目缓冲，但（原先的）关键路径却很正常。
如果按照一般的管理方式来讲的话，关键路径发生了转移。
由于在非关键路径进入关键路径的位置放置了接驳缓冲，改变关键路径，就意味着改变很多接驳缓冲的位置。项目会搞的天翻地覆。但是如果不这样做，在每次关键路径出现严重延误时，就要重整整个项目。
在有些情况下，关键路径是到处跳的。每隔一段时间就会遇到这个问题。在非关键路径上，本来一切好端端的，接驳缓冲丝毫未动，突然间问题来了。在想要开始某个非关键路径上的某个步骤，但它需要的资源却不在了。这个资源在另一条也在延迟的非关键路径上工作。
X是多个步骤争夺的资源（resource contention），以致它负荷过重，照成延误。而延误有一条非关键路径传给下一条，连各接驳缓冲也消化不了，所以关键路径会到处跳。
十万个为什么：在软件开发中，环境准备，成果物评审环节和这个非常类似。
为了解决这个问题，让我们首先回到关键路径的定义：需时最长的一串依存的步骤。但是也不要忽视X产能的短缺，不要忽视因公用一个资源而导致两个步奏互相依存的情况。产能极为有限，不可能同时进行两个步骤，只能先后进行，这就是依存关系。
这样一来，步骤间的依存关系可以由步骤所在的路径造成，也可以由步骤所共用的资源造成，根据这两类依存关系去找那串需时最长的步骤。
一般说来，最长的一串依存的步骤，由不同的部分组成，一部分由于路径本身，另一部分由于资源分配。为了加以区分我们应该先调整一下用词，关键路径仍然称关键路径，即最长的一条路径，但是我们知道最关键的是制约因素，即最长的一串有依存关系的步奏，由于我们必须承认，依存关系也可以是资源引起的，我们就用一个新名词来代表这一串制约因素所在的步骤：
关键链
在上面的例子中由于关键链已经成成了制约因素，就必须更改接驳缓冲的位置。下图是调整后的结果。
十万个为什么：这样还不够直观，特补充下图以方便理解。内容完全一致，只是表现形式不同。
关于6，13,11,4,2各个步骤的顺序问题，就算用不同的次序编排X的运作，其实区别并不大。即使有区别也不会超过项目的的不确定因素。完全可以靠项目缓冲来吸收。
十万个为什么：尽可以放宽心。
十万个为什么：最后还是想说，要想真正了解作者的思想，请阅读原著。