突破项目管理的瓶颈(借鉴材料)

《突破项目管理的瓶颈——关键链》系统整理一、问题：虽然在项目中加入了大量的安全时间，但项目还是会延期。

1）先来观察一下我们身边的项目，一般来说，都存在以下问题：（1）成本超出预算（2）时间超出期限（3）项目的规模或设计内容被牺牲。

2）在项目失败时，正式的解释都说是其他人的错，比如天气，供应商，环境等（事业环境因素）。

但是项目经理给出的原因往往是：（1）公司高层制定不切实际的日程（2）公司因成本而选择不可靠的供应商（3）组建项目团队太晚项目经理下属提出的原因：（1）过分依赖进展报告，事后才发现所报材料不正确。

（2）监管不足（3）项目成员频繁的被调派去处理各种突破事故。

（4）太多无谓的“协调会议”阻碍项目的进展。

所有问题都有一个共同点，就是它们都是其他人的错，我们听见的都是相互攻击。

员工的地位越低，矛头越是指向公司内部，而不是外部。

有一点可以肯定，就是我们不应该忽视底层经理的申诉。

如果他们说的是对的，那就是说，大部分错误就出自公司内部。

换言之，公司内部应该可以把项目管理的更加妥善。

当然我们也不能忽视公司高层的意见。

他们提出的问题都是一些不确定问题，一些在项目开始时难以预料的东西。

不确定因素是所有项目的典型特征。

结论：在所有项目中，不确定因素就是大部分问题的主要根源，所以人们为此增加了很多安全时间作为保障。

二、问题：项目的安全时间是怎么进入估算中的呢？1、预估时间是根据以往的惨痛经历来制定的。

每个领班都会说如果万事俱备，那么准时完成它负责的部分并不困难，虽然他们不会用概率表达，但大概也有8，9成以上的机会完成。

但是同时他们都会强调：他们的答案是基于两个假设：1）他们不被其他人连累而导致延误。

2）同一时间没有太多工作要他们分心。

2、涉及管理层越多，完工时间预估会越长，因为每层都会加紧各自的安全因素。

每当任务有多个步骤组成，而步骤由不同的人负责时，项目负责人便会要求每人做出各自完工时间预估，加起来以后，他也会加上自己的安全时间。

即：如果一个人预估自己的任务为5天，下一任务也需5天，项目负责人会说项目总需13天。

即：5+5=13。

3、预料到高层会削减整体完工时间，各自预先加大安全事件。

如果公司高层一半都会在要求削减项目所需时间，比如两成，那么大家就会一开始便把预估时间加大两成半。

三、将以上的安全时间通通加起来，安全时间必然占项目预估完成时间的绝大部分。

但为什么项目还是不能如期完成呢？1、那是因为同样有三个因素到安全时间被毫无意义的消耗掉。

假设有两个连续的步骤，预估时间都是10天。

如果第一个步骤实际用了12天，那么第二个步骤就会推迟2天开始。

但如果第一个步骤提前2天完成的话，第二个步骤不会提前两天开工。

原因大致有如下几个：（1）提前完工不但不会带来奖赏，而且可能导致老板削减预估时间。

（2）为下一个步骤分配的资源无法到位。

（3）下一步骤的人清楚地知道时间是足够的。

一个步骤的延误会全部转嫁到下一个步骤中，而提前完工赚得的时间通常会被浪费掉。

同样，当有多个步骤并行的时候，当中最大的延误会转嫁到下一个步骤，但当中任何提前完工（节约的安全时间）却完全起不了作用。

这个问题有一个深层次的原因：学生综合症。

2、问题：如果项目中出现了下面的情况，多半就是安全时间被浪费了。

（1）担当者有时忙有时闲。

（2）很多步骤就正好在预估时间完成，分毫不差。

还有一个就是多任务，这大概是安全时间的最大杀手。

同时开会让每个项目吃尽苦头！结论：以下三个原因会令早完工的所赚的安全时间付诸流水。

（1）学生综合症（2）多任务（3）各步骤之间的依存关系令延误累积四、关键路径和非关路径例：很明显，【兴建建筑物->发挥各种功能->在建筑物内安装各种机器】是关键路径，共需150天。

由于关键路径决定了整个项目的完工期，关键路径上的任何延误都会延误整个项目，所以项目经理一定要特别留意它。

这是常识。

这里的问题是另一条路径挑选供应商，应该在什么时候开始呢？方案1：晚开始这种方法可以推迟投资（实际上包括钱，物，人等各个方面）。

方案2：早开始这种方法可以规避风险，避免由于非关键路径上的延迟引起关键路径的延迟。

当然实际的项目通常有很多路径，远比这例子复杂。

如果所有路径都在最早的起步日期开工，项目经理会疲于本命。

这一点考虑应该远比押后投资更重要。

当然如果一条路径采取迟的起步日期，它就完全没有空当时间，也就是说这条路径上的任何延误也会导致项目延误。

也就是说：如果项目经理采取早的起步日期，他们就无法专注，如果采取迟的起步日期，专注也根本不可能。

必须有方法解决这个问题。

换一种思路，这里需要一个合适的控制机制来让项目经理保持专注。

其实项目都有控制机制用来衡量项目的进展，但问题是，等到进展报告显示有麻烦时，通常已经太迟了。

在几乎所有的项目中（即使是有里程碑的项目），使用的衡量方法都没有把关键路径和非关键路径区分开来。

这种方法会鼓励尽早启动每条路径，从而导致项目经理从醒目的最开始就不能专注了。

因为根据这种衡量方法，一条路径取得的进展，会补偿另一条路径的延误，这实际上就是鼓励一条路径快速进展，虽然另一条路径正被延误。

因为这些路径最终会合拢，导致其他路径上赚取的进展，最终都要等待那条延误的路径。

五、为了解决上述问题，本书中引入TOC五步法步骤一：识别制约因素通常在一个项目中，制约因素就是关键链。

步骤二：决定怎样挖尽制约因素的潜能不浪费关键路径上的时间，因为关键路径上的任何延误都会拖累项目。

对策是把每个步奏的预估时间削减，这样就可以释放出足够的时间来建立一个项目缓冲。

比如说把每个步骤的时间减少一半，然后将减少的时间的一半作为项目缓冲。

步骤三：其他一切都迁就制约因素这有这样才能真正挖尽制约因素的潜能。

不懂得迁就，其他路径遇到的麻烦便会直接连累制约因素，令他损失时间，换言之，没有好好保护制约因素。

迁就制约因素的方法就是在每条接驳路径与关键路径回合的地方插入时间缓冲，即接驳缓冲。

方法就是在每条接驳路径上，将各步骤原来的预估时间减少一半。

然后将减少的时间总和的一半作为该路径的接驳缓冲。

另外，在某些时候，关键路线上的步骤准备就绪，唯独欠缺相关资源，因为他正忙着其他事情。

为了避免这类冲突，可以使用资源缓冲。

步骤四：将制约因素松绑通过增加金钱或者资源等，使第一步找到的制约因素不再是制约因素。

步骤五：回到步骤一关于资源缓冲，虽然不能为了保护关键路径而让资源在工作开始前一周（比如说）就待命，但是可以在关键路径的工作开始之前发出警号，提醒人们将要到关键路径上工作。

最重要的一点是让人们知道，他们必须放下手头所有工作，转而执行关键路线上的工作。

在使用这种方法以后，对项目的监控就以以下方式进行：1）对于关键路径就监控项目缓冲，对于非关键路径就监控接驳缓冲。

2）是用百分比方式还是绝对时间作为衡量标准都是可以的。

3）监控对象不包括尚未开工的步骤，也不包括已经完工的步骤。

TOC方法的要点：1）说服各部门消减他们的预估完成时间。

2）消除所有的里程碑，换言之，个别步骤不再有目标完工日期。

3)适时报告完工预估时间。

同时，项目延期对于公司的影响绝不是增加在项目团队上的开发经费，而是公司因为产品推迟上市而少获得的利润以及失去的市场份额。

六、关键链当项目按照前面的方法进行监控时，会碰到一个问题：假设其中一条非关键路径(比如3号)进展的实在太慢了，会令整个接驳缓冲耗尽，并已经开始影响了项目缓冲，但（原先的）关键路径却很正常。

如果按照一般的管理方式来讲的话，关键路径发生了转移。

由于在非关键路径进入关键路径的位置放置了接驳缓冲，改变关键路径，就意味着改变很多接驳缓冲的位置。

项目会搞的天翻地覆。

但是如果不这样做，在每次关键路径出现严重延误时，就要重整整个项目。

在有些情况下，关键路径是到处跳的。

每隔一段时间就会遇到这个问题。

在非关键路径上，本来一切好端端的，接驳缓冲丝毫未动，突然间问题来了。

在想要开始某个非关键路径上的某个步骤，但它需要的资源却不在了。

这个资源在另一条也在延迟的非关键路径上工作。

例如下图中的情况。

下图中有X的步骤是需要专家X执行的步骤。

X是多个步骤争夺的资源（resource contention），以致它负荷过重，照成延误。

而延误有一条非关键路径传给下一条，连各接驳缓冲也消化不了，所以关键路径会到处跳。

在软件开发中，环境准备，成果物评审环节和这个非常类似。

为了解决这个问题，让我们首先回到关键路径的定义：需时最长的一串依存的步骤。

但是也不要忽视X产能的短缺，不要忽视因公用一个资源而导致两个步奏互相依存的情况。

产能极为有限，不可能同时进行两个步骤，只能先后进行，这就是依存关系。

这样一来，步骤间的依存关系可以由步骤所在的路径造成，也可以由步骤所共用的资源造成，根据这两类依存关系去找那串需时最长的步骤。

一般说来，最长的一串依存的步骤，由不同的部分组成，一部分由于路径本。